HCPpipelines
HCPpipelines copied to clipboard
Washington-University
Outline of brainmask.2.nii.gz file not rendering correctly in fMRIQC scene in Workbench 1.5
Presumably, this is related to the fact that MNINonLinear/brainmask.2.nii.gz has a 'LabelTable' associated with it, even though it doesn't contain any label information (e.g., all the values are either 0 or 1).
I'm guessing that something changed in wb_view in v1.5 such that outline mode no longer works on such a file. Either that, or something in wb_command or the HCPpipelines code itself changed to result in this embedded LabelTable that wasn't present in previous versions.
Where is some data that we can look at? In the HCA data in ceph, this file appears to be written by FSL, with no XML extension that could contain a label table.
It definitely is version dependent:
e.g.,
/ceph/intradb/archive/CCF_HCA_STG/arc001/HCA6522969_V1_MR/RESOURCES/Structural_preproc/HCA6522969_V1_MR/MNINonLinear/brainmask.2.nii.gz
which was run with QuNex 0.93.2, has an associated LabelTable.
The equivalent for HCA6000030_V1_MR, which was run with QuNex 0.48.19, does not.
That looks like it was still written by FSL, but FSL 6.0.5 may be blindly copying extensions from the input volume, while 6.0.1 discarded them.
It appears to be occurring at L220 of Freesurfer2CaretConvertAndRegisterNonLinear.sh.
[mharms@login02 MNINonLinear]$ pwd
/ceph/intradb/archive/CCF_HCA_STG/arc001/HCA6522969_V1_MR/RESOURCES/Structural_preproc/HCA6522969_V1_MR/MNINonLinear
[mharms@login02 MNINonLinear]$ which applywarp
/export/fsl/fsl-6.0.5/bin/applywarp
[mharms@login02 MNINonLinear]$ applywarp --interp=nn -i brainmask_fs.nii.gz -r ROIs/ROIs.2.nii.gz -o ~/brainmask_fs.2.nii.gz
[mharms@login02 MNINonLinear]$ wb_command -file-information ~/brainmask_fs.2.nii.gz | grep -i table
Maps with LabelTable: true
i.e., applywarp is propagating the extensions from the -r argument, rather than the -i argument!!
This was not the case under FSL 6.0.4:
[mharms@login02 MNINonLinear]$ which applywarp
/export/fsl/fsl-6.0.4/bin/applywarp
[mharms@login02 MNINonLinear]$ applywarp --interp=nn -i brainmask_fs.nii.gz -r ROIs/ROIs.2.nii.gz -o ~/brainmask_fs.2.nii.gz
[mharms@login02 MNINonLinear]$ wb_command -file-information ~/brainmask_fs.2.nii.gz | grep -i table
Maps with LabelTable: false
Yes, I had also just found that the extension was being copied from the reference, not the input data file.
So, what's the command we would run to strip the LabelTable extension from the file?
We don't have a dedicated command for stripping extensions, but wb_command -volume-math 'x' -var x brainmask_fs.2.nii.gz brainmask_fs.2.nii.gz should get the job done.
Alternatively, wb_command -volume-resample should be able to replace the core features of applywarp, but only exists starting with 1.5.0.
In this case, though, there isn't even a transform in the resampling, so wb_command -volume-affine-resample with the identity matrix should work, which is much older (specifically, works for our specific volume spaces that have been carefully made so that FSL's interpretation of the header agrees with what nifti mm space says should happen during resampling - you could give the -flirt option to be safe, though).
I think I'll just use the -volume-math 'x' hack to strip the extension, in a PR to fix this. Sound ok?
That is probably the approach that is least likely to change what voxels are "on" in the mask. We should check for other applywarp commands that use the Atlas_ROIs file (or other label files, such as the "mis-labeled" brainmask_fs.2.nii.gz) as a reference, though.
So, in this particular script, we have wmparc.2.nii.gz and Atlas_wmparc.2.nii.gz are created using applywarp from Atlas_ROIs, but both are followed by an explicit -volume-label-import anyway, so those should be fine, right?
Perhaps more concerning is that both [T1w,T2w}_restore.nii.gz are created from applywarp -r Atlas_ROIs.2.nii.gz and thus have "LabelTable = true". What would the implications of that be?
Yes, -volume-label-import ignores the label table of the input file.
Structural images will display very wrong with label rendering. It would probably show colors in the background noise where the values round to something that is in the label table, and transparent everywhere there is tissue (values larger than the labels in the table).
I think the only wb_commands that specifically round their output values based on the assumptions of writing label data have "label" in their name, so the internal values of the data files should be intact (a byproduct of being lazy and not implementing a special case for writing label data as an integer type...). Other volume viewers that don't understand our header extension shouldn't be confused by it, either.
@coalsont: How do you want to proceed on this? Do you want me to submit a PR that fixes the 3 incorrectly tagged "Label" files that are generated in this particular script? Do you want to handle it yourself as part of a broader review of the entire repo for this particular issue?
I have other things to work on, please proceed.
You might want to write a test of "is this file a label volume", using wb_command -file-information -no-map-info, and use it to run a comparison of find "$Subjdir" -name '*.nii.gz' between a subject run with FSL 6.0.1 and 6.0.5, for completeness.