Population template FOV cropped issue

Hi MRtrixers!

So far I’ve been following along the FBA multi-tissue CSD tutorial without issue (Fibre density and cross-section - Multi-tissue CSD — MRtrix 3.0 documentation) - until running the population_template command and having the occipital cortex cropped out of the template:

I checked all the masks to see if there was an issue with coverage - but the masks look fine. I saw a similar issue in the thread here: Population_template FOV .

I’m going to try re-running the command with the flag -initial_alignment robust_mass option to see if that fixes the issue - but in the meantime I have 2 questions:

  1. How can I save the debug output to a file for later viewing? I tried:
    population_template /study_template/fod_input -mask_dir /study_template/mask_input /study_template/wmfod_template.mif -voxel_size 1.25 -initial_alignment robust_mass -template_mask study_template/template_mask.mif -force -debug -nocleanup -scratch /data/AS_HC_Study/FBA/study_template/scratch > /study_template/debug.txt

but the STDOUT still goes to the terminal.

  1. Anything else I should try looking at to troubleshoot while this runs?

Thanks for your time,


Hi again, re-running with -initial_alignment robust_mass completed, but unfortunately did not fix the issue. From the other thread, please see below the requested images of the initial template and first linear template that was cropped (which in my case, was the very first linear template) :

Hi Ariana,

I happened to have a similar issue earlier and am happy to share with you how to solve it. What I found was that some subject had different q-form and s-form in the header of the nifti images from others. So once you identify which subjects have this issue, then you can rerun your analysis without those subjects. Then I think you will find the cropped issue is gone.

Hope it helps.

Jiaying Zhang


I solved the problem in the past following Max’s suggestion about modifying the line in population template:

Otherwise, I’d modify population_template and replace this line by

      average_inv = None

and check if the problem goes away. If so I’d be interested in the content of the linear_transforms_* folders in the scratch dir generated with this modification.

I hope this helps.

Best regards,


Hi Jiaying Zhang,

Thanks for sharing this - I wasn’t aware there was the possibility for different q/s form headers (I’m new to neuroimaging - lots to learn lol). I’ll check this out, though ideally I’d like to be able to keep the subjects I had chosen for the template. Is this I guess only an issue for forming the template - but not an issue for registering subjects to the template later down the line?

Hi Manuel,

Thanks for sharing this again. I saw your post / this solution, but posted again for the following reasons:

  1. I saw you were using neonatal data, and didn’t see anyone else with adult data with a similar issue, so I was concerned maybe something was weird about my data and didn’t want to change source code before trying other possible work arounds (assuming most people work with adult imaging data)
  2. I’m not sure what changing that line of code changes exactly for the formation of the template - Max asked to look at the output afterwards but the thread ended there. I’d be interested to hear what changing this line changes about the population template creation?


I changed the source code as Manuel suggested, and got what appears to be a proper population template. If it’s possible to explain what changing this line of code altered, I’d appreciate it - thanks!

Setting average_inv = None results in deactivating the drift correction that prevents scaling, rotation or translation between template iterations in the linear registration steps. The template might take longer to converge and might be overall different in shape and location due to the lack of this linear correction.

I’ve created an issue population_template: bogus average space · Issue #2467 · MRtrix3/mrtrix3 · GitHub for this bug. If you’re willing to help us find the cause for this issue, could you please have a look at the instructions there?

Will do! Thanks a lot for the explanation

@abesik has sent me some data to investigate (thanks!) … but I haven’t had time to look into it.

Soothsaying, sform vs qform issues are quite unlikely the culprit here. You might not encounter the issue after resetting the NIfTI transforms but I think that would be a side effect. (And you’d need to make sure no unexpected side effects creep in: NIfTI transform ambiguity).

Ah I see. Sure, just let us know when you figure out this problem.Thanks!


The issue was a bug in the drift correction to which resetting the centre of the input images is a sensible workaround. If you want, you can try the fix proposed in the population_template_space_init_drift_fix branch which should solve the FOV issue. Note that this fix does change the behaviour of population_template and is not yet part of the master code branch and it might change before it makes it there. To check the effect of the drift correction on the template shape, you could add the option -linear_no_drift_correction.

Thanks a lot for taking the time to figure this out, Max! Really appreciate it.

Just to clarify… to check the effect of drift correction on the template shape, I should add the option -linear_no_drift_correction to the proposed fixed version of the command and compare that to running the fixed command without this option, as opposed to comparing it to the original command with this option? Is this the equivalent to modifying the original code to set average_inv = none or is this different?

Within your git fix, you mention: " deactivating drift correction via -linear_no_drift_correction leads to visible distortion in the affine levels that increase with the number of levels iterations."

Sorry… I am not familiar with all the math that’s going on here - but does this mean it is best not to deactivate drift correction for the actual population template that is to be used in analysis (but it is useful just as a way to examine how this new modification to the code impacts the template shape?)

The drift correction is supposed to prevent the template from gradually changing its size or overall shape over iterations. We do that by (approximately) preserving the average transformation at each linear registration stage. The “new” drift correction is very similar to the old version, except that it does not factor out the average transformation after initialisation (which is fixed and therefore cannot drift). I’d leave this feature active except for in edge cases (i.e. debugging or when dealing with registration outliers).

-linear_no_drift_correction is a new option added in the population_template_space_init_drift_fix branch that deactivates this feature – similar to setting average_inv = None. (However, there were other changes to the code in that branch that affect the initialisation so you’d get different results compared to the master branch code if you use any of the robust initialisation methods.) I just mentioned this option in case you ran population_template with the average_inv = None and would like to see the effect of deactivating the drift correction on the template shape. In my data, the effect was clearly visible but even if this is the case for your data as well, the overall template shape might not matter for your analysis. Besides, there are multiple ways of defining an average affine transformation so there is no universal ground truth appearance.

Thank you for explaining that!

Unfortunately I seem to be running into issues running this new command…

I have tried using the -force option - still gave the error. I tried to switch the directories I saved the template into / also changed the name of the output file and still got the error. The command I used was:

/home/abesik-local/mrtrix3_testbranch/bin/population_template /data/AS_HC_Study/FBA/study_template/fod_input -mask_dir /data/AS_HC_Study/FBA/study_template/mask_input /data/study_template_testbranch/wmfod_template_testbranch.mif -voxel_size 1.25 -force

(I’ve been using bash instead of the python command).

I am running it on the same participants I included when I ran the population_template command before - is there somehow a file somewhere that needs to be deleted before I can run this again?

Hey everyone, to finish up this thread… the issue I had above was a result of needing to fully build the testbranch of MRtrix so that other commands (eg mrgrid) required for population_template to run properly are compiled, as opposed to just building the particular population_template command (which is actually a script and so isn’t compiled anyway). The wiki page for testing branch code has been edited to reflect this - Thanks Max for solving this!

Just wanted to share the end result of the three different population template commands…


Top left, wmfod_template is the edited original source code per above to deactivate linear drift correction (average_inv = None).
Top right, wmfod_template_testbranch is the result of the testbranch population_template_space_init_drift_fix code.
Bottom left, wmfod_template_testbranch_noL is the result of the testbranch population_template_space_init_drift_fix code but with -linear_no_drift_correction

The two template with no linear drift correction are very similar, but not the same, as Max mentioned they would be. The size and shape of the testbranch template is different than those with no linear drift correction. Thanks again Max for your help with this / everyone else for commenting. Cheers!

1 Like