Poor data quality: MT

[valosekj]

sub-fslAchieva03_acq-T1w_MTS.nii.gz

sub-fslAchieva04_acq-T1w_MTS.nii.gz

sub-fslAchieva05_acq-T1w_MTS.nii.gz

sub-fslAchieva06_acq-T1w_MTS.nii.gz

sub-beijingPrisma01_acq-T1w_MTS.nii.gz

fslAchieva: Wrong placement (should be centered at C3-C4): --> should remove site from statistics

sub-balgrist02 Wrong placement

sub-nottwil03_acq-MToff_MTS.nii.gz

sub-nottwil04_acq-MToff_MTS.nii.gz

sub-pavia05_acq-MToff_MTS.nii.gz

[jcohenadad]

@valosekj these issues are only about data quality (not about issues with segmentations, which should be dealt with in release-specific issues, like #35), which hamper the relevance/quality of the output qMRI metrics. E.g., strong motion, aliasing, etc.

[valosekj]

@valosekj these issues are only about data quality (not about issues with segmentations, which should be dealt with in release-specific issues, like #35), which hamper the relevance/quality of the output qMRI metrics. E.g., strong motion, aliasing, etc.

Oh, sure, I didn't realize it. I updated comment.

[jcohenadad]

I would remove (for MTsat and T1):

• sub-fslAchieva04_acq-T1w_MTS.nii.gz
• sub-beijingPrisma01_acq-T1w_MTS.nii.gz

The other scans seem acceptable.

[valosekj]

I would remove (for MTsat and T1):

• sub-fslAchieva04_acq-T1w_MTS.nii.gz
• sub-beijingPrisma01_acq-T1w_MTS.nii.gz

The other scans seem acceptable.

Okay, I'll open PR with updated exclude.yml file.

Other scans which look acceptable (sub-fslAchieva03_acq-T1w_MTS.nii.gz, sub-fslAchieva05_acq-T1w_MTS.nii.gz, sub-fslAchieva06_acq-T1w_MTS.nii.gz) are already listed in exclude.yml under t1 key:

https://github.com/spine-generic/data-multi-subject/blob/91bb13eb2ca179a61da539c59f5951e8cc6019f9/exclude.yml#L17-L26

They are listed there probably because they are outliers (based on T1.csv file):

But, fix of SC segmentations (https://github.com/spine-generic/data-multi-subject/issues/35#issue-689371016) can fix these outlier values.

[jcohenadad]

But, fix of SC segmentations (#35 (comment)) can fix these outlier values.

the segmentations did not seem crazy to me, but we'll see. @alexfoias did them, so i'll upload them asap and we can re-run the processing and re-assess. Other things to check:

• are the acquisition parameters OK? (Look the BIDS-checker in Travis)
• Do you see anything wrong with the other contrasts (MT0 and MT1)?

[valosekj]

I have found difference in RepetitionTime in *_acq-T1w_MTS files between fslAchieva subjects:

Subjects with standard value of T1 metric have repetition time = 0.015. Outlier subjects have = 0.103.

for NUM in $(seq 1 6);do echo fslAchieva0${NUM}; cat sub-fslAchieva0${NUM}/anat/sub-fslAchieva0${NUM}_acq-T1w_MTS.json | grep RepetitionTime; done
fslAchieva01
    "RepetitionTime": 0.015,
fslAchieva02
    "RepetitionTime": 0.015,
fslAchieva03
    "RepetitionTime": 0.103,
fslAchieva04
    "RepetitionTime": 0.103,
fslAchieva05
    "RepetitionTime": 0.103,
fslAchieva06
    "RepetitionTime": 0.103, 

[jcohenadad]

wow! great catch @valosekj 👍

[jcohenadad]

fslAchieva-01 and 02 are _also_outliers, with MTsat values around 7.

json file for MTon/off:

    "RepetitionTime": 0.057,  --> under specs

Ah! the problem might be related to the signal quantization which might differ between the MTon/off and the T1w scan:

MT on/off:

    "PhilipsRWVSlope": 1.69499, 
    "PhilipsRWVIntercept": 0, 
    "PhilipsRescaleSlope": 1.69499, 

T1w:

    "PhilipsRWVSlope": 1.85592, 
    "PhilipsRWVIntercept": 0, 
    "PhilipsRescaleSlope": 1.85592, 

Whereas for vuissAchieva, which yields MTsat values of ~5.5 (like the other Philips sites), the field PhilipsScaleSlope is the same between the MT on/off and T1w:

MT on/off (vuissAchieva):

	"PhilipsRescaleSlope": 1.81343,
	"PhilipsRescaleIntercept": 0,
	"PhilipsScaleSlope": 0.00067717,

T1w (vuissAchieva):

	"PhilipsRescaleSlope": 2.0696,
	"PhilipsRescaleIntercept": 0,
	"PhilipsScaleSlope": 0.00067717,

Idem for tokyoIngenia01:

	"PhilipsScaleSlope": 0.000702185,  --> MT on/off
	"PhilipsScaleSlope": 0.000702185,  --> T1w

We need to confirm with Philips that PhilipsScaleSlope is indeed related to the quantization of the reconstructed magnitude image, and that a different parameter between MTon/off and T1w would produce corrupted MTsat values if this effect is not compensated for.

Once this is confirm, the next question is: how to correct for this effect. Based on the name "Slope", it could be a simple linear effect, and eg multiplying (or dividing?) each magnitude image by its PhilipsScaleSlope would bring the signal to comparable values.