Mtnormalisation clarifying questions in AFD/Fixel walkthrough

Hello all,

I have two questions regarding errors I get with mtnormalise. It ran on all of my subjects except for one, which gets
mtnormalise: [ERROR] error reading from file "/TEST111717_WMFOD_GRP.nii.gz": /TEST111717_WMFOD_GRP.nii.gz: incorrect data check

What exactly does incorrect data check mean?

Second question: mtnormalise actually doesn’t seem to work. When I do:
mrinfo MTNORMTEST111717_WMFOD.nii.gz -property lognorm_scale,

I get the message:

mrinfo: [WARNING] no "lognorm_scale" entries found in "MTNORMTEST111717_WMFOD.nii.gz".

Are either of these errors due to the fact that I’m running mtnormalise on nifti files rather than .mif? Would converting all files for the AFD/Fixel walkthrough to .mif help? Thank you very much for your help :space_invader: !

ETA: MRtrix3 has been updated to 3.0 RC2

ETA2: So I converted one subject to mif just to try it out, and it does look like a nifti issue:

$ mrinfo wmfod_norm.mif -property lognorm_scale
$ mrinfo MTNORMTEST111717_WMFOD.nii.gz -property lognorm_scale
mrinfo: [WARNING] no "lognorm_scale" entries found in "MTNORMTEST111717_WMFOD.nii.gz"

Any possibility of mtnormalise working on nii.gz files in the future?

Hi Amanda,

mtnormalise: [ERROR] error reading from file "/TEST111717_WMFOD_GRP.nii.gz": /TEST111717_WMFOD_GRP.nii.gz: incorrect data check

That’s emanating from one of these two lines. “Incorrect data check” is not a message that MRtrix3 is generating, but one it is simply echoing from the GZ file handling library when it encounters an error. So I can only suggest that your file may have been somehow corrupted. One way to test this would be to try to uncompress the .nii.gz into a .nii using gunzip.

mrinfo MTNORMTEST111717_WMFOD.nii.gz -property lognorm_scale

The NIfTI image format is not capable of storing arbitrary key-value pairs in the image header. Therefore, while mtnormalise internally writes this parameter to the output image header within the code, that information is immediately lost if the image data are written to a NIfTI image, and there is no way to recover it. This is a fundamental limitation of the NIfTI format. We recommend sticking to the .mif format, and exporting to NIfTI explicitly only when data must be imported into some other software, partly for this reason.

If one absolutely insists on using NIfTI, one trick is to use the MRtrix3 config file, specifically two options: NIfTI.AutoLoadJSON and NIfTI.AutoSaveJSON. This uses sidecar JSON files to store any relevant key-value entries that would have been encapsulated within the image header if the .mif format had been used.


Hi Rob,

Thank you very much for the information, it is always helpful :slight_smile: We are considering switching to .mif format due to the fact it is such an integral part of the analyses we want to do (AFD/Fixel analysis).

Thanks again!