Register NIST phantom data to ROI for subsequent quantification

[jcohenadad]

Extending on #6, the purpose of this PR is to set up a pipeline to register the NIST phantom data to the ROI for subsequent mask-based quantification.

The following has been done:

• [x] Download ROIs when running register_t1maps_nist.py
• [x] Create initial labels for registering the ROI to all NIST phantom data
• [x] Update the registration parameters to work with synthetic phantom instead of with an arbitrary reference site (previously: gilbert)
• [x] Apply the inverse transformation of each site to the curated ROI (labeled, eroded).

Additional improvements:

• Removed FSL dependency (now using nibabel)

Fixes #1

[jcohenadad]

Preliminary results (with ab22c7a) of registration directly to the NIST phantom roi:

TODO:

• Mis-registrations to figure out

[jcohenadad]

Mis-registrations to figure out

This is caused by some sites acquiring data with the phantom flipped along its axis, causing the labels to go from the trigonometric rotation to anti-trigo, causing the label-based registration to fail (because it is a 2d transfo-- so this is an ill-posed registration problem).

a solution would be to detect those cases, and flip the data (along with the labels)

[mathieuboudreau]

@jcohenadad Do you want me to figure out manually/visually which datasets have that property? (i.e. clockwise decreasing T1 values vs counter-clockwise, if I understand correctly?)

[jcohenadad]

Mis-registrations to figure out

This is caused by some sites acquiring data with the phantom flipped along its axis, causing the labels to go from the trigonometric rotation to anti-trigo, causing the label-based registration to fail (because it is a 2d transfo-- so this is an ill-posed registration problem).

a solution would be to detect those cases, and flip the data (along with the labels)

ha! my bad-- given that i have replaced fslsplit with nibabel, output names are different, so the final gif generation included the 'bad' registration. Things might workout well at the end-- let me re-run with a fresh re-install of the data

[jcohenadad]

yay! 🎉

next steps:

• cleanup (create API for header modif via nibabel)
• bring labels to native T1 space
• Update doc

[jcohenadad]

@mathieuboudreau i have a prototype that seems to be working (deb7ba1). Example for one site below (cannot easily aggregate all sites into a single gif, because native spaces have different matrix sizes):

The output masks are generated as: 3T_NIST_T1maps_pooled/*_mask.nii.gz

[mathieuboudreau]

@mathieuboudreau i have a prototype that seems to be working (deb7ba1). Example for one site below (cannot easily aggregate all sites into a single gif, because native spaces have different matrix sizes):

The output masks are generated as: 3T_NIST_T1maps_pooled/*_mask.nii.gz

Huh, somehow I missed this comment! Must have gotten lost in my email due to the alerts I got from your git commits just after - sorry for the slow response. I'm going to test it now!

[mathieuboudreau]

@jcohenadad I just ran the script, and it didn't error. However, I encountered two issues so far when looking at the outputs:

1- The ROI mask NIFTIs and T1 maps seem to be in different spaces, or have different orientations, see FSLeyes screenshots:

2 - Several ROI files are missing in the pooled folder, and I have no idea why. e.g. for the "20200305_ngmaforo_ucla" dataset, the mask files were generated for the two Skyra measurements (Skyra_FS and Skyra_noFS) however the two Prisma measurements don't have accompanying ROI masks in that folder (for Prisma_FS and Prisma_noFS). Masks for other datasets are missing too, such as for the "20201802_jalnefjord" dataset. Searching through the log output from the scripts, these don't appear anywhere in it. They are also missing from both your gif in this current thread (https://github.com/rrsg2020/analysis/pull/10#issuecomment-665202078), and the previous PR (https://github.com/rrsg2020/analysis/pull/6#issuecomment-653287339)... They also all are present in the config files, so maybe this is a NIFTI format issue?

Any clue what might be causing both issues, and if there might be quick fixes for them?

[jcohenadad]

@mathieuboudreau looking into it now

[mathieuboudreau]

Thanks @jcohenadad !

I browsed through the outputs, and these are the ones that appear to have missing output masks/ROIS:

20201802_jalnefjord_sahlgrenska_NIST_Complex_T1map.nii.gz 20200305_ngmaforo_ucla_Prisma_noFS_NIST_Magnitude_T1map.nii.gz 20200305_ngmaforo_ucla_Prisma_FS_NIST_Magnitude_T1map.nii.gz 20200302_wang_MDAnderson_day2_NIST_Complex_T1map.nii.gz 20200302_wang_MDAnderson_day1_NIST_Complex_T1map.nii.gz 20200225_CStehningPhilipsClinicalScienceGermany_Hamburg_MR1_NIST_Complex_T1map.nii.gz 20200225_CStehningPhilipsClinicalScienceGermany_Cologne_MR4_NIST_Complex_T1map.nii.gz 20200225_CStehningPhilipsClinicalScienceGermany_Cologne_MR3_NIST_Complex_T1map.nii.gz 20200225_CStehningPhilipsClinicalScienceGermany_Cologne_MR1_NIST_Complex_T1map.nii.gz 20200225_CStehningPhilipsClinicalScienceGermany_Bonn_MR1_NIST_Complex_T1map.nii.gz 20200225_CStehningPhilipsClinicalScienceGermany_Berlin_MR1_NIST_Complex_T1map.nii.gz 20200225_CStehningPhilipsClinicalScienceGermany_Aachen_MR1_NIST_Complex_T1map.nii.gz 20200210_guillaumegilbert_muhc_NIST_Complex_T1map.nii.gz 20200121_matthewgrechsollars_ICL_NIST_Complex_T1map.nii.gz

[jcohenadad]

1- The ROI mask NIFTIs and T1 maps seem to be in different spaces, or have different orientations, see FSLeyes screenshots:

i can reproduce it. I'm working on it-- shouldn't be too long (just a matter of copying the qform from the T1map).

2 - Several ROI files are missing in the pooled folder, and I have no idea why. e.g. for the "20200305_ngmaforo_ucla" dataset, the mask files were generated for the two Skyra measurements (Skyra_FS and Skyra_noFS) however the two Prisma measurements don't have accompanying ROI masks in that folder (for Prisma_FS and Prisma_noFS). Masks for other datasets are missing too, such as for the "20201802_jalnefjord" dataset. Searching through the log output from the scripts, these don't appear anywhere in it. They are also missing from both your gif in this current thread (#10 (comment)), and the previous PR (#6 (comment))... They also all are present in the config files, so maybe this is a NIFTI format issue?

Oopsi, I think there was a misunderstanding originating from this comment https://github.com/rrsg2020/analysis/pull/6#issuecomment-651251198. I wrongly thought that i should only deal with dataType=magnitude data. Sorry about that.

I'll first deal with the first comment, and hopefully the fix for the second comment will be easy (i could see how it can go wrong, so fingers crossed...)

[mathieuboudreau]

2 - Several ROI files are missing in the pooled folder, and I have no idea why. e.g. for the "20200305_ngmaforo_ucla" dataset, the mask files were generated for the two Skyra measurements (Skyra_FS and Skyra_noFS) however the two Prisma measurements don't have accompanying ROI masks in that folder (for Prisma_FS and Prisma_noFS). Masks for other datasets are missing too, such as for the "20201802_jalnefjord" dataset. Searching through the log output from the scripts, these don't appear anywhere in it. They are also missing from both your gif in this current thread (#10 (comment)), and the previous PR (#6 (comment))... They also all are present in the config files, so maybe this is a NIFTI format issue?

Oopsi, I think there was a misunderstanding originating from this comment #6 (comment). I wrongly thought that i should only deal with dataType=magnitude data. Sorry about that.

I'll first deal with the first comment, and hopefully the fix for the second comment will be easy (i could see how it can go wrong, so fingers crossed...)

Ahh kk, well you know, the second problem, it's not the end of the world, because I think all of them are the same "space" as the magnitude data, so I could just deal with replacing "Complex" to "Magnitude" for the rois in my post processing. If anything, it kinda makes more sense to only register the magnitude data, and not do it twice for those datasets.

However, that wouldn't explain why two of the datasets is missing, 20200305_ngmaforo_ucla_Prisma_noFS_NIST_Magnitude_T1map.nii.gz and 20200305_ngmaforo_ucla_Prisma_FS_NIST_Magnitude_T1map.nii.gz, as these are magnitude data.

[jcohenadad]

@mathieuboudreau can you check if f28fa73 fixes the different output space problem (first issue listed)?

important note: the outputs to consider now have the suffix: _T1map_modifheader_mask.nii.gz and _T1map_modifheader.nii.gz

[jcohenadad]

However, that wouldn't explain why two of the datasets is missing, 20200305_ngmaforo_ucla_Prisma_noFS_NIST_Magnitude_T1map.nii.gz and 20200305_ngmaforo_ucla_Prisma_FS_NIST_Magnitude_T1map.nii.gz, as these are magnitude data.

looking into this now

[mathieuboudreau]

However, that wouldn't explain why two of the datasets is missing, 20200305_ngmaforo_ucla_Prisma_noFS_NIST_Magnitude_T1map.nii.gz and 20200305_ngmaforo_ucla_Prisma_FS_NIST_Magnitude_T1map.nii.gz, as these are magnitude data.

Actually there is at least one more dataset missing, "20201802_jalnefjord_sahlgrenska_NIST_Complex_T1map.nii.gz", as that one doesn't have a magnitude mask.

[jcohenadad]

However, that wouldn't explain why two of the datasets is missing, 20200305_ngmaforo_ucla_Prisma_noFS_NIST_Magnitude_T1map.nii.gz and 20200305_ngmaforo_ucla_Prisma_FS_NIST_Magnitude_T1map.nii.gz, as these are magnitude data.

ah! easy fix: these are not listed in the json file 😉

[jcohenadad]

and this one does not appear because of the datatype issue:

                "dataType": "Complex",
                "real":{
                    "imagePath": "20201802_jalnefjord_sahlgrenska_NIST/20201802_jalnefjord_sahlgrenska_NIST_Real.nii.gz"
                },
                "imaginary":{
                    "imagePath": "20201802_jalnefjord_sahlgrenska_NIST/20201802_jalnefjord_sahlgrenska_NIST_Imaginary.nii.gz"
                }

[jcohenadad]

https://github.com/rrsg2020/analysis/pull/10#issuecomment-667766744 @mathieuboudreau i let you update the json file as you have all the info (you can push directly on my branch)

[mathieuboudreau]

@mathieuboudreau can you check if f28fa73 fixes the different output space problem (first issue listed)?

important note: the outputs to consider now have the suffix: _T1map_modifheader_mask.nii.gz and _T1map_modifheader.nii.gz

Yup, those two files now share the same space, that resolves issue number 1, thanks!

[mathieuboudreau]

And issue number 2 is mostly resolved, the only dataset that doesn't have an ROI is 20201802_jalnefjord_sahlgrenska_NIST_Complex_T1map.nii.gz as no magnitude dataset exists for this one. But I can make a note of it and we can look into this later on.

[mathieuboudreau]

@jcohenadad I noticed a third (minor?) issue. It seems like at least one step of the resampling or registration of the masks is not doing nearest neighbour interpolation, such that we have the "fifty shades of grey" issue at the ROI borders. Is this something that could be fixed easily? If not, no worries, thresholding the ROIs as-is could be sufficient for now, and we could fix this later.

[jcohenadad]

you can just add -n NearestNeighbor for the last antsApplyTransforms command (or i can do it tmr morning)

[mathieuboudreau]

you can just add -n NearestNeighbor for the last antsApplyTransforms command (or i can do it tmr morning)

Done, thanks!

[mathieuboudreau]

Just a brief update for record keeping purposes.

Plotted the means and std's for all datasets & rois in the mb/plots branch. Here are the results:

Linear T1 plot:

Log-Log T1 plot:

Error (%) plot:

In the linear plot, a few ROI's have huge standard deviations. This is due to to misregistration, where a few voxels from the background phantom are contaminating the ROI with voxels of very high T1s. E.g.,

For that dataset in particular, there's severe warping or slice mispositionning in the original images for some of the spheres (i.e. some spheres are about half the radius as others), so I'm not surprised that a few of them didn't work out perfectly during the registration. This should either manually corrected and noted in the records, or we could attempt to improve the registration if it's feasible. But either of these options should only be done after the meeting.

[jcohenadad]

In the linear plot, a few ROI's have huge standard deviations. This is due to to misregistration, where a few voxels from the background phantom are contaminating the ROI with voxels of very high T1s. E.g.,

in the image you show, given that the majority of the pixels is overlapping with the sphere, how about using another metric less sensitive to outliers, like the median? Of course, the STD will still be affected, but at least the T1 estimate (which is what we mostly care about, right?) will be more accurately represented.

[mathieuboudreau]

In the linear plot, a few ROI's have huge standard deviations. This is due to to misregistration, where a few voxels from the background phantom are contaminating the ROI with voxels of very high T1s. E.g.,

in the image you show, given that the majority of the pixels is overlapping with the sphere, how about using another metric less sensitive to outliers, like the median? Of course, the STD will still be affected, but at least the T1 estimate (which is what we mostly care about, right?) will be more accurately represented.

Good point - yes, absolutely!