Fixelcfestats warning

We’ve noticed a warning similar to this popping up after running the fixelcfestats command in the latest MRtrix release:

[WARNING] A total of 820 fixels do not possess any streamlines-based connectivity; these will not be enhanced by CFE, and hence cannot be tested for statistical significance

Can I assume it’s very much just a warning to give you some idea how many fixels aren’t being tested? A very large number would then indicate something has gone wrong with streamline construction but not too many (wrt total fixels) should be fine?

Hi,

Just wondering if anyone has encountered this error and if it is something to be concerned about?

Thanks!

1 Like

Hi Michael / @louiselav,

For clarity, this warning is specific to the development branch of MRtrix3, and will not appear if you are utilising either tag 3.0_RC3 or the master branch.

The warning relates to this CFE modification, which is utilized by default in the development branch and explicitly disabled using the -cfe_legacy option. In the corresponding poster (and as will appear in a manuscript if I ever find the time to write such a thing ever again), I described how this modification can be detrimental to results if there are fixels included in the analysis mask that are not traversed by any streamlines in the tractogram (it has to do with the interaction between this specific modification and FWE control). My mitigation strategy is to automatically exclude such fixels from the analysis, and alert the user of such. My wider recommendation is that in the definition of a fixel analysis mask, streamlines visitation should be taken into account; I however have not done the requisite testing across multiple datasets to recommend a default heuristic. For now, tck2fixel | mrthreshold can be used to place a lower limit on streamline count per fixel; I’d also like to be able to extract the total “extent” of connectivity of each fixel and apply a threshold to that, but it would require a little coding.

A very large number would then indicate something has gone wrong with streamline construction but not too many (wrt total fixels) should be fine?

If it’s a really large number, it would suggest that the voxel mask / FOD segmentation parameters used to generate fixels in template space was quite liberal, but the whole-brain streamlines tractography was quite restricted. In that case the advice above is increasingly pertinent.

Cheers
Rob

Hi All,

As a follow-up to the previous message, I see the warning message with fixelcfestats upon processing DWI data (single shell 69 directions, b=1160) with the latest Mrtrix3/3.0.1 release and following the latest documentation for Fixel based analyses- Single Tissue CSD.

fixelcfestats: Number of fixels in template: 1265035
fixelcfestats: [WARNING] A total of 206230 fixels do not possess any streamlines-based connectivity; these will not be enhanced by CFE, and hence cannot be tested for statistical significance

The template mask was generated upon masking any holes at the individual subject level upsampled masks. Comparing the template mask (used to generate fixel_mask) with the Tractogram generated from tracks_2_million_sift.tck there seems to be fixels included in the analysis mask that are not part of the tractogram streamlines.

What is the recommended next steps, given the latest Mrtrix3/3.0.1 release version.

Thank you.
Best Regards,
Anup

Welcome Anup!

The appearance of this particular warning does not necessarily mean that any of your processing needs to change. I left the warning in place because the fact that some of the fixels in the template (or in the fixel mask if one is explicitly provided) will not be tested despite their presence (deemed a necessity due to this change) warrants a notification of reasonable priority to the user; but it does not preclude statistical inference from proceeding once those fixels are internally excluded by fixelcfestats.

What I didn’t get to resolve prior to the 3.0.0 release was exactly how I would recommend deriving such a mask. It’s quite common to use tck2fixel then mrthreshold to select template fixels with at least some number of streamlines passing through them, and use that as a fixel mask for statistical inference, and in retrospect perhaps I should have added that step to the FBA pipeline documentation. What I’d prefer to do is use a combination of streamline count and streamline connectivity (as encoded in the fixel-fixel connectivity matrix) to derive that mask, and potentially use other information as well; but I don’t yet have all of the requisite tools in place.

So no need to panic: “warnings” are usually put there to flag that some assumption is being made independently of the user, or that something should be verified, but processing can still proceed unlike “errors”. But it’s worth thinking about all of the things that contribute to the determination of which fixels get tested and which do not.

Rob

Thanks Rob for your reply,
Regarding your suggested next steps using tck2fixel first:
this step generates a fixel-map using the SIFT based_2 million input tracks and the input fixel_mask used to define the fixels and directions?
the resulting fixel_map is similar to the dimensions of fixels.mif upon running fixel-fixel connectivity but with total #template analysis fixels as mentioned earlier and with upsampled resolution used 1.25 iso.

The next step is to mrthreshold to generate the mask with same dimensions and 1.25 resolution to be used in conjunction with the streamline connectivity based fixels.mif which is at 1mm iso ? will stats then need to be run on the resulting matrix mask upon fixel filter. Thanks for all your clarifications for FBA analyses w/ver 3.0.1

Hello, I would like to follow-up on the steps post editing fixel mask processed using latest version 3.0.1. I the previous post was suggested to tck2fixel and then mrthreshold to generate a mask. What are the next steps using this mask? i.e. generate fixel connectivity matrix based on this mask, fixelfilter and followed by running stats?

Best Regards,
Anup