Open valosekj opened 4 years ago
@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 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.
I would remove (for MTsat and T1):
The other scans seem acceptable.
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:
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.
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:
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,
wow! great catch @valosekj 👍
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.
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