KrisThielemans
commented
4 years ago interesting, and good point! Once you take that view, there seems to be nothing really related to gating in that class...
There's one thing that makes PoissonLogLikelihoodWithLinearModelForMeanAndGatedProjDataWithMotion special, i.e. that it goes from multiple projdata to a single image. (This is similar to the kinetic case of course (multiple time frames->parametric image), hence the similarities in the classes.). I'm saying that because conceivably someone might want to use PoissonLogLikelihoodWithLinearModelForMeanAndGatedProjData with TargetT a GateDiscretisedDensity or so (i.e. reconstruct one image for each gate). This could (later on) be made more sophisticated by using "temporal" filtering or penalties.
I suppose we could have PoissonLogLikelihoodWithLinearModelForMeanAndMultiProjData, this would need a set of DataProcessors that convert TargetT to "normal images" (one for each "multi"), and does the loops. In the future, that'd then need an extension of DataProcessor to have in and OutTargetT to cope with the kinetic case, but we wouldn't need that now.
Might be best to template it in the MultiProjData type. I could even see this being templated in the `PoissonLogLikelihoodWithLinearModelForMeanAndProjData template, but clearly that's for the future.
To avoid having the user to specify motion twice, we could make a new LinearDataProcessor class (derived from DataProcessor), which has an adjoint. That would need some thought on how that would look like.
rijobro
We now have our projectors set up such that they can use a data processor pair prior to forward projection, and following back projection. This therefore makes classes, such as
PoissonLogLikelihoodWithLinearModelForMeanAndGatedProjDataWithMotionredundant.PoissonLogLikelihoodWithLinearModelForMeanAndGatedProjDatawould be good, which can optionally have motion added in via the data processors.This would clear up confusion regarding the experimental and non-experimental implementations.