Siemens mMR_ACR updates

[KrisThielemans]

This PR provides updates using @pjmark's files

[KrisThielemans]

Initial BSMR result for 200s of data (with initial step-size 0.5 after 4310 updates):

@pjmark, this looks oversmoothed, correct? We can change the penalty strength.

Also, could you provide some detail on the VOI masks you give? for instance, for the "all I get 4 clusters (or arguably a few more) of indices.

Some info on what these are would be great.

[KrisThielemans]

@pjmark, the registered mu-map that you created does not contain the bed. Is that correct? (Looks like we have some bias due to that).

[pjmark]

@pjmark, the registered mu-map that you created does not contain the bed. Is that correct? (Looks like we have some bias due to that).

Yes, you need the hardware mu-map in addition, which you can generate from the raw data/e7tools.

Not sure how STIR geometry relates to the scanner, but perhaps you could just resample the SIemens hardware to your NIfTI space?

[pjmark]

From the images, I can defo say the hardware mu-map is needed. And yes a bit too smooth.

For the sampling masks, they are many concentric rings, going from the centre to the outside of any insert. This can be simplified for your case, i.e., using only the masks which cover just the insert without concentric sampling

[pjmark]

on second thought, the images look the 'other way' round without the attenuation of the bed... something is not right. But still the bed is needed.

[KrisThielemans]

@pjmark, the registered mu-map that you created does not contain the bed. Is that correct? (Looks like we have some bias due to that).

Yes, you need the hardware mu-map in addition, which you can generate from the raw data/e7tools.

Not sure how STIR geometry relates to the scanner, but perhaps you could just resample the SIemens hardware to your NIfTI space?

Sadly, this is one of many things that we have neglected. Obviously, the exact location of the hardware mumap is important (including z-shifts). @NicoleJurjew started looking at this recently but is on holiday.

[pjmark]

Sadly, this is one of many things that we have neglected. Obviously, the exact location of the hardware mumap is important (including z-shifts). @NicoleJurjew started looking at this recently but is on holiday.

I could generate it and then remap it to the space of your NIfTI. Do you think you may have some extra shifts?

[KrisThielemans]

could generate it and then remap it to the space of your NIfTI. Do you think you may have some extra shifts?

that'd be amazing. As long as your "complete" mu-map is self-consistent, I guess the remapping has to work.

[pjmark]

that'd be amazing. As long as your "complete" mu-map is self-consistent, I guess the remapping has to work.

I did it! I'm pretty sure it's correct. I will send you an email with the NIfTI hardware mu-map. You just need to add the object and hardware together and it should work. I would start with the old trusted EMML/OSEM perhaps to see if we are artefact free.

[KrisThielemans]

Thanks a lot @pjmark . OSEM full count with some smoothing looks good now!

[KrisThielemans]

This should be ready now. I'm constructing the reference image.

@casperdcl maybe you do the lint etc? I've removed some redundancy in finding file locations, but there's plenty still in other places.

[KrisThielemans]

Top-left: OSEM 1800s, Top-right: OSEM 200s, Bottom-left: BSREM with RDP 200s

[KrisThielemans]

Plots obtained with plot_BSREM_metrics.py using a reference image obtained with run_BSREM after 21920 updates:

objective function

metrics

Images