I manually ran run_first_all and it completed without error, but there’s the same error in the logs, it can not generate L-accu. It seems the problem is because of the registration, since it runs without any error on native T1 brain.
Depends on your definition of “completed without error”. As far as I can tell,
run_first_all never actually returns a non-zero error code to indicate that a problem has occurred; hence the gymnastics in
5ttgen fsl trying to determine whether or not the segmentation was successful.
I would have expected that if the registration had failed, then none of the sub-cortical structures would be segmented. If some structures are segmented but others aren’t, I don’t see how this could be caused by the registration step.
I’m doing 5ttgen to perform ACT. That’s why I registered the T1 to DWI before any other step to prevent further misalignments. Can I do the registration after 5ttgen? Or does MRtrix does it itself for ACT?
Some explicit registration between DWI and T1 is required. You can do this registration before or after
5ttgen, though personally I recommend before, as there’s a possible mistake to be made in registering the T1 to DWI after
5ttgen but failing to apply that transformation to the 5TT image. The point I was making here is that, internally,
5ttgen is entirely independent of the DWI data, and therefore should be invariant to whether or not such a registration step has already been performed.
Moreover, as I noticed, 5ttgen has brain extraction (BET) within its steps. So, I ran it on raw head T1 image (I did it on extracted brain tissue previously, the result was with massive grey matter erosions).
If the image you provide as input to
5ttgen fsl has already been brain extracted, you should indicate this using the
-premasked option. This will bypass the brain masking steps in the script.
5ttcheck: [WARNING] Image "5tt_from_t1.mif" contains 1 brain voxels with non-unity sum of partial volume fractions
So there’s a single voxel in the brain where the tissue fractions don’t sum to 1. Unlikely to severely affect your analysis, hence why it’s only a warning in
5ttgen rather than an error. From memory, this can occasionally occur in isolated voxels in the output of FAST, independently of
5ttgen, and it would seem that in some instances these gymnastics are not sufficient to correct it. But you can use
5ttcheck -masks then
maskdump to tell you exactly where that voxel is, and then examine it through the script’s intermediate images to see where the problem arises.