New cst format ? struct instead of cell array

[Haydnspass]

When I did the DVH / QI changes I thought of indrucing 'dictionaries' at the end of cell arrays, since they are kind of hard to understand sometimes (as compared to structs). This could be done as in CERR. E.g. when one calls cst{end} one gets a struct with the a short description of the content of the columns and the corresponding column number.

Something like

>> cst{1,end}

ans = 

  struct with fields:

              dvh: 8
               qi: 9
    structureName: 2
    structureType: 3

That would also improve code since one does not need to remember and hard code column numbers.

[becker89]

Today @Haydnspass and @wahln had the idea to change the cst variable from an cell array to an struct (similar to the stf variable). Columns 5 (structure meta parameters) and 6 (objective functions) of the current cst format can then be translated to substructres (e.g. cst(5).obj.dose). With that, it would be easier to add new fields/properties to the cst. Code readability would also increase. Only 'experienced' matRad users know that cst{i,4}{1} outputs the index list. In contrast the new alternative might be easier to read cst(i).ix{1}. Lets discuss this on Thursday

[wahln]

if we implement such a radical change we could also think of renaming cst to something more people can directly relate to, like vois or rois or something like that

[markbangert]

I agree that there is a lot that can be improved in the current organization of the cst but we have to be aware that this implies that we will not have downwards compatibility with the code. Or at least we will have issues to organize this. I figure we need to collect all suggestions and wait until we release matRad 3.0...

[Haydnspass]

if we want to ensure downward compatability we could write something like a cstToVoi function which just transforms the old to the new structure

[wahln]

we could also go completely fancy and start using classes (i.e. having an array of VOI objects)