we do not understand from the doc that the 2nd argument has to be a previously constructed mSTIR.AcquisitionSensitivityModel
This needs to be in a demo as well. I would put it in the reconstruction_from_listmode demo. It's the natural place. @rijobro is going to suggest some changes on that one.
Can you also add in the doc that the attenuation image needs to be in units cm^-1?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.![]()
In addition to the above, I think most users (including me) will get confused by
unnormalise Multiplies the argument (AcquisitionData) by (1/n).
forward Returns the argument multiplied by (1/n).
These 2 functions currently do the same (they're aliases effectively). that should be clear from the doc. I'd say
forward Identical to unnormalise
added 'existing' and attenuation units
examples of constructors are in using_acquisition_model demos
'Identical to unnormalise': wrong: unnormalise changes (multiplies by 1/n) the argument, forward does not (returns new AcquisitionData object)
agreed for the "not identical.". sorry. what about saying
forward Returns a new AcquisitionData equal the input argument multiplied by (1/n).
done
Closed #95.
Reopened #95.
using_acquisition_model demo seems to have only
asm = AcquisitionSensitivityModel(bin_eff)
which is fine for me. I would there just refer to other demos on AcquisitionSensitivityModel.
we cannot find a demo that uses both atn and norm. Needs to be somewhere. The recon demo I would definitely include both as that's what people will want to do.
I was referring to using_acquisition_model.m, the python demo is asm_sinograms.py
ok, using_acquisition_model.py doesn't do the chaining. I now see there's an example of the chaining in asm_sinograms.py indeed. It's fine then as it is, but it still needs to be in the recon
Closed #95.