better indices for projection data

[KrisThielemans]

We need a more future-proof way to specify indices in projection data, e.g.

ProjData::get_viewgram(const ViewgramIndices&)

as opposed to what we have now

ProjData::get_viewgram(const int view_num, const int segment_num,
                               const bool make_num_tangential_poss_odd=false
#ifdef STIR_TOF
                               , const int timing_pos=0
#endif
                               )

(the make_num_tangential_poss_odd is long obsolete, but was unfortunately preserved on the TOF PR #304 so it's harder to remove now).

Having this will mean less code changes in the future once we add energy indices, layers etc.

NikEfth#17 started this on the TOF branch, but was somewhat ambitious and got overtaken by other things.

One possible way to do this would be

class SegmentIndices
{ time, TOF, energy, whatever};
class ViewgramIndices: public SegmentIndices // replacing ViewsegmentNumbers
{ view_num};
class SinogramIndices: public SegmentIndices
{ axial_pos_num};
class Bin: public ViewgramIndices
{ tangential_pos_num};

Sadly, C++ has no "named parameters", so we shift some of the burden to constructing the relevant object, and having constructor arguments in the correct order. However, it would at least prevent loops being specific.

As noted in NikEfth#17, loops could then be simplified by having something like this

 for (auto vg_idx: proj_data_info.get_all_viewgram_indices())
   ...

Anyone any suggestions for improvements?

[robbietuk]

I like this idea. The looping fixes a lot of issues that will come with added projection data dimensionality.

Question: do this before or after #304 is merged?

[KrisThielemans]

Question: do this before or after #304 is merged?

the billion dollar question... I'd like to do it before, but I don't really want to delay #304 either.

If we do it before the merge on master, then we'll have a ton of merge conflicts on the TOF branch. But, after resolving those, the TOF PR will be a lot smaller, which would make it easier to spot any remaining issues.

Possibly a half-way house could work ok: do an (nearly) automatic "search and replace loop" on both branches, then merge. Not sure...

[robbietuk]

My perferance would be merge the TOF branch and improve indexing after. Better indexing isn't just a TOF problem.