OK, there’s a lot of different concepts / issues getting blurred together in this thread… In general, if your issue is not described well by the title of an existing thread, it’s best to create a new thread, and simply include a link to the other thread in your post in case if it has some relevance.
The issue of non-unity partial volume sums described earlier above is caused by some hard-to-reproduce issue in the FSL command
fast, which then propagates through to the
5ttgen fsl script. There was also an issue with an earlier version of the
5ttgen fsl script that caused the same warning to be issued, but with a much greater number of voxels; that was an issue with my own code that has since been fixed. The fact that you are using the
5ttgen gif algorithm means that neither of those are applicable: this is something else, which, given how lightweight the
5ttgen gif script is, may be something to do with the GIF software rather than
5ttgen gif. I would suggest looking closely at the raw output from that software, and contacting the developers if you believe there to be some issue. Alternatively, if you can better isolate the root cause of the issue (e.g. maybe some fraction of those voxels is being assigned to some other tissue class that the
5ttgen gif algorithm is ignoring? Maybe it’s just a floating-point tolerance issue?), then that’s something we can chase up here.
The fact that you receive a similar warning using the
5ttgen fsl script is probably not some intrinsic deficiency or curse in your image data, but just luck that you happen to be receiving the same error that is occurring for a different reason. However if you’re using an up-to-date MRtrix3 installation, I would expect the number of non-unity voxels with the
5ttgen fsl algorithm to be significantly less than that of the image you have provided.