No use of manual disc label for T2w in process_data.sh

[sandrinebedard]

In process_data.sh, the manual C2-C3 disc label is only used in the function label_if_does_not_exist called for T1w disc labeling : https://github.com/sandrinebedard/Projet3/blob/5bf91fb4531cc7e4543e281b53825333e5b8d8ee/process_data.sh#L32-L41

But if the subject moved between T1w et T2w as discussed in issue #13 , we will add manual identification of the disc for T2w. The problem is that file manual_label for T2w will never be used in process_data.sh as it is right now, the function label_if_does_not_exist is not used here:

https://github.com/sandrinebedard/Projet3/blob/5bf91fb4531cc7e4543e281b53825333e5b8d8ee/process_data.sh#L145-L151

It will only use labeling from T1w label_T1w/template/PAM50_levels.nii.gz even if T2w manual disc label exists.

[jcohenadad]

A suggestion to bypass the manual identification of C2/C3 disc on the T2-FLAIR image is to:

• perform an image-based registration T1 --> T2-FLAIR (rigid)
• apply the estimated transformation to the T1-based vertebral levels
• Problem: the registration algorithm takes too much into account the defacing edge, so we need to create a mask to ignore those voxels.

Here are example syntax (room for optimization):

# Dilate segmentation to use as mask for the registration
sct_maths -i T2_FLAIR_orig_defaced_seg.nii.gz -dilate 15 -shape ball -o T2_FLAIR_orig_defaced_seg_dil.nii.gz
# Registration
isct_antsRegistration -d 3 -m CC[ T2_FLAIR_orig_defaced.nii.gz , /Users/julien/data/ukbank/1000252/T1/T1_orig_defaced.nii.gz , 1, 4] -t Rigid[0.5] -c 50x10x5 -f 8x4x2 -s 0x0x0 -o [_rigid, T1_orig_defaced_reg-mask.nii.gz] -v 1 -x /Users/julien/data/ukbank/1000252/T2_FLAIR/T2_FLAIR_orig_defaced_seg_dil.nii.gz
# Apply transformation to vertebral level
 isct_antsApplyTransforms -i /Users/julien/data/ukbank/1000252/T1/T1_orig_defaced.nii.gz -r T2_FLAIR_orig_defaced.nii.gz -t _rigid0GenericAffine.mat -o T1_orig_defaced_reg-julien.nii.gz

Comments:

• Dilation of 15 is probably too small (bigger --> more robust)-- maybe try 25
• sct_maths is slow for dilations with big kernels, I recommend trying ImageMath from ANTs.

[sandrinebedard]

I tested the two first steps on sub-1000710 with a dilation of 15, 25 and 35 to compare. The registration with the mask with 15 and 35 of dilation give good results. For a reason I don't understand, with a mask of 25 of dilation, the registration is not good. I tested on another subject with 25 (sub-1000252) and it works well. I don't understand why specifically with this subject the registration gives bad results with this specific mask.

Here are the results: sub-1000710 - Registration with mask of 15 dilation

sub-1000710 - Registration with mask of 25 dilation

sub-1000710 - Registration with mask of 35 dilation

sub-1000252 - Registration with mask of 25 dilation

I tested applying the transformation to the vertebral level of T1w for sub-1000252 with the mask of a dilation of 25, here is the results, it looks fine!

I made a folder with the data used for this test : duke/temp/sebeda/test-registration/

For sub-1000710 and a dilation of 25, I used these following lines:

ImageMath 3 sub-1000710_T2w_RPI_r_gradcorr_seg_dil_25.nii.gz MD sub-1000710_T2w_RPI_r_gradcorr_seg.nii.gz 25

isct_antsRegistration -d 3 -m CC[ sub-1000710_T2w_RPI_r_gradcorr.nii.gz , sub-1000710_T1w_RPI_r_gradcorr.nii.gz , 1, 4] -t Rigid[0.5] -c 50x10x5 -f 8x4x2 -s 0x0x0 -o [_rigid, sub-1000710_T1w_RPI_r_gradcorr_reg_mask_25.nii.gz] -v 1 -x sub-1000710_T2w_RPI_r_gradcorr_seg_dil_25.nii.gz

[jcohenadad]

Nice investigation @sandrinebedard !

The issue with dil=25 for one subject is not surprising-- it is possible that with that mask, convergence of the registration algo reached a local minima due to the voxels included in that mask. The rule of thumb is that the more voxel you include in your mask, the more robust the registration will be. So I would be inclined to go with dil=35 (or possibly higher based on your results in a larger population).

Also, I would recommend increasing the number of steps for the 2 last rounds: -c 50x20x10

Also, for QCing the registration, it would be nice to include the QC directly in SCT's HTML QC report. We might need to tweak some code to be able to display sagittal images, but the syntax would be something like:

sct_qc -i IM1 -s IM1_seg -d IM2 -p sct_register_multimodal -qc PATH_QC -qc-subject SUBJECT

[sandrinebedard]

So I would be inclined to go with dil=35 (or possibly higher based on your results in a larger population).

Good, I'll leave it at 35 to test on more subjects and try higher to see!

Also, I would recommend increasing the number of steps for the 2 last rounds: -c 50x20x10

Good, I'll modify it

Also, for QCing the registration, it would be nice to include the QC directly in SCT's HTML QC report.

I'll try this out!

Thanks!

[sandrinebedard]

Qc report with:

sct_qc -i sub-1000252_T1w_RPI_r_gradcorr_reg_mask_25.nii.gz -s PAM50_levels_reg_T2w.nii.gz -d sub-1000252_T2w_RPI_r_gradcorr.nii.gz -p sct_register_multimodal -qc-subject sub-1000252

Yes, we don't have the saggital view, it would be easier to assess the quality of the registration with it. What would we have to change to get it?

I also looked at the vetebral labeling qc with :

sct_qc -i sub-1000252_T2w_RPI_r_gradcorr.nii.gz -s PAM50_levels_reg_T2w.nii.gz -p sct_label_vertebrae -qc-subject sub-1000252

The labeling (numbers) are repeted, I don't know if it will be a problem but sct_process_segmentation worked fine with this labeling so maybe it is ok.

[sandrinebedard]

@jcohenadad , I tested the method on 30 subjects and the same thing happens to t2 labeling as in the comment above, it seems like the labels are mixed up/leaking during the transformation as shown in the image below (this is the worse case observed). But the C2-C3 disc is still well identified, here is the label with previous method for the same subject:

For all 30 subjects, the registration seems ok, but the same problem occurs with the mixed labels.

[jcohenadad]

it seems like the labels are mixed up/leaking during the transformation as shown in the image below (this is the worse case observed).

Yup, this is just a visual bug in the QC-- nothing to worry about-- I'll open an issue on the spinalcordtoolbox GH.

But the C2-C3 disc is still well identified, here is the label with previous method for the same subject:

indeed, the registration seems much better, which is what matters.

[sandrinebedard]

Yup, this is just a visual bug in the QC-- nothing to worry about-- I'll open an issue on the spinalcordtoolbox GH.

Hummm, I looked on FSLeyes at the results and same thing appeared! But I found the problem, it was the interpolation causing this while applying the transformation to the labeling. Adding -n NearestNeighbor to isct_antsApplyTransforms did the trick to keep the labeling! All good now, not a visual bug in the QC!