help > RE: QA histogram "bug"
Dec 9, 2018  10:12 PM | Alfonso Nieto-Castanon - Boston University
RE: QA histogram "bug"
Hi Jon,

Thank you very much for your post. That is in fact a very good point and you are exactly right that this may pose a problem for some of the QA denoising plots generated in datasets that have not been preprocessed using an MNI-based pipeline.

Just to provide some context, originally the "random" sample of ~1000 voxels that is used to generate the histogram displays in the Denoising tab was selected as a subset of the Gray Matter masks defined by the "Gray Matter" ROI (and typically computed as part of normalization/segmentation). From this sample we compute a matrix of 1000x1000 connectivity values (before and after denoising), and then simply displayed the distribution of the resulting FC values. This worked perfectly fine in most scenarios, but at some point (after Cyric et al. 2017) we decided we wanted to also be able to compute correlations across subjects between these FC values and subject-specific Quality Control measures, because those are very informative of the potential residual presence of motion-related effects after denoising. Unfortunately, in order to be able to do this we needed the subset of voxels to be "the same" across different subjects, and the original strategy of selecting subsets of gray matter voxels did not work because those are generally different across subjects. We decided then to modify the selection algorithm to use instead a gray matter mask based on "referenceGM.nii" (which is just the tissue probability map in MNI-space of gray matter voxels). That allowed the selection of the random subset of voxels to be constant across subjects, which allows us to then compute the desired QC-FC correlation measures. Unfortunately, you are exactly right that this change also made the procedure inappropriate for datasets that are not in MNI-space.

In order to fix this I am thinking one potential approach would be having CONN keep the current strategy (selecting voxels randomly within the referenceGM mask) for those projects where the 'analysis mask' field (defined in Setup.Options) is set to the default value (i.e. mask.volume.brainmask.nii), which is indicative of the functional data actually being in MNI-space, while reverting to the previous strategy (selecting voxels randomly within the Gray Matter ROI masks) in all other cases. This would have the advantage of maintaining the same behavior in all standard/MNI-based cases, while also allowing users to explicitly specify an alternative mask used for these plots in all other cases (simply by setting the Gray Matter ROI accordingly). Let me know if you think this sounds reasonable and/or any thoughts/comments/suggestions

Best
Alfonso

Originally posted by Jon Dudley:
Hi all,

This does not apply to most projects but...

Starting in version 18.a (or perhaps 17.f), it appears that the before and after denoising histograms of voxelwise connectivity are generated based off 1,000 (random?) voxels from the set of voxels in the MNI-aligned file ~/conn/utils/surf/referenceGM.nii with values of 0.25 or higher.

As a result, if your CONN project is dealing with data normalized to a different standard space (e.g. a neonate atlas) or if you are using a restricted analysis mask then the QA histograms will not be accurately reflecting the distribution of voxelwise correlations in your data before or after denoising. ETA: this also affects carpet plots.

Cheers!
Jon

Threaded View

TitleAuthorDate
Jon Dudley Dec 6, 2018
RE: QA histogram "bug"
Alfonso Nieto-Castanon Dec 9, 2018
juliabb Dec 29, 2020
Jon Dudley Dec 10, 2018