ProjDataInfoGeneric et al need TOF changes

[KrisThielemans]

ProjDataInfoGenericNoArcCorr currently contains a lot of copies of the ProjDataInfocylindricalNoArcCorr functions. this means the TOF changes need to be ported to the generic version. We also have to check the Block functions.

Ideally we do this by cleaning up the hierarchy, as opposed to creating even more duplication.

[KrisThielemans]

Historical note: this was done by @pkhateri and @roemicha (on my recommendation) to be able to make the changes necessary for the blocks/generic implementation without disturbing the rest of STIR.

[KrisThielemans]

The practical issue is that ProjDataInfoGeneric is currently derived from ProjDataInfoCylindrical, and therefore ProjDataInfoGenericNoArcCorr cannot inherit from ProjDataInfoCylindricalNoArcCorr, unless we'd use virtual class derivation (leading to "diamond" class hierarchies), which would likely create a lot of trouble.

The more conceptual difficulty is that ProjDataInfoCylindricalNoArcCorr really handles 2 types of data:

• data with certain views and sin(s/R) type of sampling
• interleaved data as corresponding to a scanner with discrete detectors (see doc here).

The "logical" thing to do seems to be to remove the "interleaved" functionality from ProjDataInfoCylindricalNoArcCorr (as that can be represented geometrically by blocks-on-cylindrical with a single crystal per block).

This is however hard, as currently the "generic"/"blocks" types are only handling span=1 and no mashing. Indeed, when there are (sizeable) axial gaps between blocks, strictly speaking "span" probably doesn't make a lot of sense, but in practice, many scanners use it anyway (as either the gaps are small, or they are "filled" with virtual crystals).

Other notes:

• current ProjDataInfoGenericis almost empty (mainly justdeletes members in ProjDataInfoCylindrical). It should be merged with ProjDataInfoGenericNoArcCorr. A more appropriate name would be ProjDataInfoDiscretisedScanner` or something.
• ProjDataInfoBlocksOnCylindricalNoArcCorr is derived from ProjDataInfoGenericNoArcCorr, but really only adds 2 obsolete functions (remove obsolete functions in ProjDataInfoCylindrical and ProjDataInfoCylindricalNoArcCorr #105) which are never used (except in the tests). So this class is effectively only used to be able to test if the scanner is blocks-on-cylindrical or generic (which can be done via ProjDataInfo::get_scanner_ptr()->get_scanner_geometry()). This seems to imply we can remove the class.

Surprisingly, this seems to imply that a first line of attack could be to

1. merge ProjDataInfoGeneric and ProjDataInfoGenericNoArcCorr
2. derive ProjDataInfoGenericNoArcCorr from ProjDataInfoGenericNoArcCorr

This is ugly as the logic is still wrong, but it would resolve a lot of code issues with fairly small changes (and without breaking backwards compatibility).

The next small step could then be
3. remove ProjDataInfoBlocksOnCylindricalNoArcCorr

@markus-jehl @danieldeidda @NikEfth what do you think?

[markus-jehl]

I'm definitely in favour of simplifying the class hierarchy and culling the ones that add very little! Currently I don't see how the proposed first line of attack reduces the code duplication for BlocksOnCylindrical, though. In "2." you may have a typo, which may be why I don't understand it :-)

[KrisThielemans]

:-)!

should have been

Derive ProjDataInfoGenericNoArcCorr from ProjDataInfoCylindricalNoArcCorr

[markus-jehl]

In this case I think your proposed change makes a lot of sense! It's still the wrong architecture, but for now it should do the trick for most functions.