Dear developers of CASToR,
I started reading the source codes of CASToR very recently and I am really impressed by how structured the codes have been developed into. Based on my limited understanding, the current version of CASToR is flexible in terms of implementing different optimizers, projectors and etc. However, the structure of function runCPU
in the virtual class vAlgorithm
has make it challenging to implement algorithms such as MLAA.
Specifically, runCPU
defines the update order in each iterations and the real update process is defined in function: StepInnerLoopInsideSubsetLoop
. This is proper for algorithms that only aims to reconstruct one sets of variables, while for MLAA, which aims to reconstruct two sets of variables, it is not the best scheme. For this reason, I believe the most proper way to implement MLAA is to define another function (e.g. runCPUforMLAA
) in vAlgorithm
, with the following scheme (subsets/number of beds and pre(post)-processing ignored for simplicity):
For i in outerIteration:
# Update activity
For j in innerActIteration:
UpdateActivityFunction()
# Update attenuation
For j in innerAttIteration:
UpdateAttenuationFunction()
However, such strategy will lead to numerous changes to CASToR (e.g. two optimizerMangers, different subsets/iterations for each image) and as an amateur of CASToR, I am not sure if this is feasible for me to handle. Is there a way to implement MLAA without modifying such high level (abstract) classes in CASToR?
Thanks for your attention and I am looking forward to hear back from you.
Kind regards,
Bo