mriqc
mriqc copied to clipboard
nipreps
Tissue class mapping wrong with T2w inputs
The following is based on my experience with running T2w anatomical scans through version 22.0.6, but looking through the current code in the master branch, I don't see any reason to expect that it wouldn't be an ongoing problem with the current version.
This line of code
https://github.com/nipreps/mriqc/blob/24f786ae9e312b55830139e354627e837ea5703a/mriqc/qc/anatomical.py#L213C1-L213C16
defines the following mapping between the tissue labels used in MRIQC and the FAST segmentation labels:
FSL_FAST_LABELS = {"csf": 1, "gm": 2, "wm": 3, "bg": 0}
That mapping is indeed correct for T1w anatomicals. But at least in our T2w data, the typical segmentation that we are getting out of FAST (as launched by the MRIQC default settings) has GM = 1, WM = 2, and CSF = 3. But MRIQC doesn't appear to account for that altered mapping for T2w data.
The end result is that any MRIQC metric that is dependent on the T2w segmentation is either mislabeled, or just wrong (e.g., CJV and CNR are intended to be based on GM and WM, but per above what MRIQC is labeling "wm" is typically actually CSF, and what it is labeling "gm" is typically actually WM, in the case of T2w data).
@effigies and other MRIQC developers, as I am also running mriqc on T2 data, it would be great to hear feedback on this issue raised by @mharms Many thanks in advance!
@WilliamFCB : When you look at the actual segmentation maps, are you seeing the same thing that I'm reporting above?
#1099 switched to Atropos, and was included in 23.1.0, but I believe it does the same thing of simply ordering tissues by mean intensity.
It looks like fixing this will be non-trivial, as T1w assumptions are baked into the workflow, and then all anatomical images are passed with no additional parameterization:
https://github.com/nipreps/mriqc/blob/24f786ae9e312b55830139e354627e837ea5703a/mriqc/workflows/anatomical/base.py#L91-L109
It shouldn't be a terribly difficult job, though. The fix seems to me be adding a contrast weighting input to the iterable (using synchronization to keep the variables paired), and pass it as an input to any subworkflows that need to adjust their behavior based on the weighting.
Are there other effects that you're seeing, or is it simply that we need to select an alternative tissue mapping for T2w images?
@mharms, I did not really look before I posted. I just saw your post and thought it deserved a response.
Anyway, having said that, I just located the T2 segmentation files and had a look. I get 1= CSF, 2= GM and 3=WM. So, that follows the T1 format. I used mriqc.23.1.0 by the way.
Cheers William
So, if I understand correctly, you aren't seeing any problems with the segmentation of your T2w data using 23.1.0? Is 23.1.0 still using FAST, or is it using ANTS? What type of T2-weighted scan are you collecting? e.g., Is CSF bright or dark (FLAIR)?
Could you maybe post a snapshot of what you are seeing for a typical segmentation? I've attached an example of the segmentation labels that we are typically getting in our CSF bright T2w scans. (In a small number of cases, we are getting WM coded as 3 from FAST.)
#1099 switched to Atropos, and was included in 23.1.0, but I believe it does the same thing of simply ordering tissues by mean intensity.
Ordering by intensity would have WM < GM in a T2w scan, so if Atropos is assigning numeric segmentation labels consistent with the ordering in a T1w scan, it wouldn't be ordering by intensity.
Attached are a few snapshots. The T2's are not usable because of gibs ringing artefacts. This has the effect that CSF is not always bright. Anyway, I ran mriqc because I was interested to see the QC measures mriqc calculates in this case.