nm_mrac2mu --head resampling

[szho42]

As the metioned in the documentation, the output resampled images will be in size 344x344x127, if the --head flag is enabled.

However, in our case, the output attenuation map is in 244x244x108?

Of course, we can do resampling the attenuation map in the SIRF recon pipeline, to match the output size(344x344x127). But just a bit confused about whether the resampling was designing to be done in pet-rd-tool or in SIRF?

WIthout the resampling, this will cause the error when estimating the scatters, in SIRF. (see error message below):

/opt/SIRF-SuperBuild/INSTALL/python/sirf/STIR.py in process(self) 2745 self.output = AcquisitionData() 2746 self.output.handle = pystir.cSTIR_runScatterEstimator(self.handle) -> 2747 check_status(self.output.handle) 2748 print('ScatterEstimator:: estimation finished.') 2749

/opt/SIRF-SuperBuild/INSTALL/python/sirf/Utilities.py in check_status(handle, stack) 408 repr(line) + ' of ' + file + '; ' + \ 409 'the reconstruction engine output may provide more information' --> 410 raise error(errorMsg) 411 412

error: ??? "'\nERROR: ScatterSimulation: limitation in #planes and voxel-size for the attenuation image.\nThis would cause a shift of -19.2969mm w.r.t. the activity image.\n(see https://github.com/UCL/STIR/issues/495.\\n' exception caught at line 439 of /opt/SIRF-SuperBuild/sources/SIRF/src/xSTIR/cSTIR/cstir.cpp; the reconstruction engine output may provide more information"

any hints would be helpful. thanks

[KrisThielemans]

This seems a duplicate of #14, although I thought that was fixed by @ashgillman. In any case, there's also #46, so I'm a bit wary of this utility.

I recommend solving this by using SIRF to do the necessary manipulations:

1. do NAC recon for a few subiters
2. read the DICOM MRAC data (pass filename of any of the slice)
3. register MRAC to NAC
4. divide by 10000

I don't have the relevant SIRF lines at the moment for this. sorry. Maybe you can send email to the synerbi list if you need help.

[szho42]

Yeah, I also checked out the #46, and we also used RAS in our case ( Siemens listmode data).

Just to make sure my understanding is right regarding the registration-based solution. After steps 1-4, we can have the MRAC (aligned with the PET output space), then we re-do the reconstruction from an new initilaized image, right?

In this case, any residuals from the registration of the MRAC image to the NAC, could cause false contrasts in the output PET image?

Yeah, I will send to the synerbi mailing list to see whether there are altervative solutions.

thanks

[KrisThielemans]

After steps 1-4, we can have the MRAC (aligned with the PET output space), then we re-do the reconstruction from an new initilaized image, right?

correct

any residuals from the registration of the MRAC image to the NAC, could cause false contrasts in the output PET image?

yes of course. However, in practice it is a step that most people would recommend anyway, due to movement between the PET and MRAC.

[szho42]

In a PET/MR scanner system, the movement between PET and MRAC should be minimal. In this case, a resamplig of the MRAC to match the PET image would be an acceptable option? thanks

[szho42]

by the way, what is reason behind the operaiton, 'divide by 10000' after registration? or it is differnt data precisions? thanks

[ashgillman]

In a PET/MR scanner system, the movement between PET and MRAC should be minimal. In this case, a resamplig of the MRAC to match the PET image would be an acceptable option? thanks

Assuming that the coordinate systems are aligned. However, this isn't the case, due to a difference in convention with STIR. This will be easier one day (https://github.com/UCL/STIR/projects/1#card-61085594), but not quite yet.

by the way, what is reason behind the operaiton, 'divide by 10000' after registration? or it is differnt data precisions? thanks

This is just a change of units, I believe Siemens uses um^-1 and STIR uses cm^-1.