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?
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.
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.
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.
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?
I’m finding your first message difficult to interpret; if I can’t catch the issue below, you might need to have another attempt at explaining your uncertainty.
The tck2fixel command doesn’t need to generate a new “fixel map”, and if it does, it should just be a duplicate of the index and directions file from the input fixel directory. So there’s no reason for the “dimensions” to have changed at any point, unless you’ve erroneously used the wrong input fixel directory.
When you say “streamline connectivity based fixels.mif”, given that this must be different to the output of tck2fixel (with or without subsequent mrthreshold call), are you referring to the file contained within the fixel-fixel connectivity matrix directory? This may at least explain your claim that that file is “at 1mm iso”, which isn’t actually the case because the contents of that file are not represented on a voxel grid (look at the image dimensions), the voxel sizes are just filled with unity values because it’s currently not permissible to either omit or have invalid values for voxel sizes in the .mif format.
The question then is what steps need to be either modified or re-run based on the generation of such a mask. fixelcfestats is designed to be able to operate on a fixel-fixel connectivity matrix that was generated using all fixels, but a restricted fixel mask for GLM and statistical enhancement. Technically you could re-run fixelconnectivity to produce a new fixel-fixel connectivity matrix that includes only those fixels within the mask, and that would slightly reduce the storage size of that matrix, but the outcome should be no different. Where there would potentially be a difference is whether or not fixel data smoothing using fixelfilter is constrained to only those fixels within the mask (whether by using the -mask option, or generating a new fixel-fixel connectivity matrix based on that mask and then using that matrix within fixelfilter). I honestly don’t know how to give a general recommendation here: poorly-connected fixels may correlate with high subject variance and therefore omitting them from not only statistical inference but also data smoothing may be beneficial… I have plans for addressing this more explicitly in the future, but for now I can only say that either approach is valid and that I’ve not done enough testing to advise one way over the other.
Thanks for your reply Rob, you are right, I meant tck2fixel generates a fixel_data_out.mif along with index and directions files identical to the input fixel mask. And I was indeed referring to fixel-fixel connectivity matrix which contains fixel.mif at 1mm iso.
Based on your suggestion: I am re-running fixelconnectivity providing the fixel_folder_out from tck2fixel as the input fixel_directory.
Followed by the fixel2filter step using mask (i.e the image obtained upon mrthreshold of the fixel data.mif from tck2fixel step) prior statistical analysis. Correct me if you meant to use any another image as the mask in the fixel2filter step.
Hi, @rsmith
Sorry for reviving such old threads. I have received the similar warning as this thread, since the number is relatively high (i.e. 200000+ fixels), so I tried to generated a mask according to your recommandation here. But I’m not familiar with MRtrix3, after searching relevant posts, I’m still don’t know how to write the command.
I run the tck2fixel below, and got the TDI.mif successfully, but when I tried to run the mrthreshold, I met errors. Could you please help me amend my commands? I’d very appreciate your help.
mrthreshold: [ERROR] Image "fixel_mask_tck2fixel/TDI.mif" does not represent spatial data (has axis with size 1)
mrthreshold: [ERROR] Automatic thresholding can only be performed for voxel data
Another message maybe useful, I viewed the TDI.mif, and there shows nothing.
