How to use the option of -set_property of mrconvert

Hi experts,

I hope to correct the strides of my data, however, the result does not like what I expected.

The scripts are demonstrated below,
mrconvert input.nii output.nii.gz -set_property -strides -1,2,3 -force
I hope to change input.nii, which has a Data stride 1,2,3, to -1,2,3, but the Data stride of output.nii.gz is 1,2,3, which does not change.

I think there are mistakes made by me, however, I have no idea what is the correct form because I cannot find useful tips.

Can you give me some advice?

Many thanks,

Hi Feihong,

This is the correct command invocation to do what you want:

mrconvert input.nii output.nii.gz -strides -1,2,3 -force

For reference, the -set_property option is there to manipulate generic header entries (i.e. you can add generic fields in the header to store any arbitrary data you might want that way), but it’s not useful when storing NIfTI images, since this format doesn’t support arbitrary header entries¹. It’ll only work properly with the .mif / .mih formats, currently.

All the best,

¹However, if you use NIfTI images along with JSON sidecar data (as per the BIDS standard), then these entries will be stored in the JSON file.

Hi Tournier,

Thanks for your response.
I tried the ‘-set_property’ using in a .mif file, it thus added a ‘-strides: -1,2,3’ item to the header of .mif file.

I also tried the -strides, it seems also change the data illustration accordingly when I open it in ITKsnap. I do not want it to be changed like that, so I cannot use the -strides option as you suggested.

I can state my problem here more clearly. It may associate with the NIFTI tool in a Matlab platform. I generated the 5tt file before fiber tracking using our algorithms. I used save_nii NIFTI to save my .nii file, even I copied the correct data-strides information demonstrated by mrinfo, however, the data-strides information has been changed in NIFTI.

More specifically, I want a strides -1,2,3, but it changed to 1,2,3,is there a tool in Mrtrix to correct such header information?


Hi Feihong,

Yes, the command I suggested above does precisely this. But its effects might not be obvious or correspond to what you’re after, particularly with NIfTI. To really understand what’s going on, I recommend you have a good read through our documentation about strides, and particularly their interaction with the image transform. The NIfTI section also mentions the existence of issues specific to NIfTI, but refers to a missing page – I’ll need to fix in due course… But essentially, the problem is that NIfTI does not allow for arbitrary strides: these are always implicitly assumed to be 1,2,3,… Once you understand this, and add to it the information about stride handling and its interactions with the image transform, things should all make sense (though it’s not a simple to get your head round it).

Of note: the strides reported by mrinfo are those derived following interpretation by the MRtrix back-end (you can add the -config RealignTransform false option to any command to completely disable this – though I would only recommend this for debugging purposes).

To come back to your problem: if you can post the full output of mrinfo input.nii for the file whose strides need fixing, and the equivalent output for the image you’re using as a reference, maybe we can figure out exactly what needs to be done. It would also help to have screenshots of the image displayed in mrview and ITKsnap. Note that mrview (and all MRtrix tools in general) will (or at least should) handle all these issues consistently. It shouldn’t matter what the strides of the input images are, as long as the image as a whole is self-consistent.

It’s also worth pointing out that when using mrconvert to change the strides, this will also re-order the data in the image itself to match. This means the image will still display exactly the same in mrview (and maybe other software packages too, depending on how they handle these things). If the issue is that the image is flipped left/right for example, then that’s not strictly speaking a strides issue, but something you could address using e.g. mrtransform (using the -flip option).

Sorry if this is all sounds a bit complicated… These issues are typically easy to fix, but it takes quite a while to understand what’s going on.

All the best,

Hi Tournier,

Thanks for your detailed response, I really appreciate it and I can learn a lot from your response (& your contributions in this field).
That’s a pity I cannot reply immediately. Our server was down for several days, so I cannot get the data.

First of all, however, my problem is not a big one. There is no problem observed from mrview but ITK snap and more specifically, open segmentation button. This problem only takes place when I first open a T1 image and second open the label image.

Before my proble, I want say, I cannot use the operation ‘-copy_properties’ to fix this problem either, ROIs.nii.gz is the input.nii.gz, while the ROIs_test_strides.nii.gz is the output.nii.gz, and intensity-struct.nii.gz is the data before processing by Matlab - NIfTI package.

mrconvert 5tt/ROIs.nii 5tt/ROIs_test_strides.nii.gz -copy_properties mrbrain/intensity-struct.nii.gz

No matter in mrview or IT-SNAP, if I open the ROIs_test_strides.nii.gz and ROIs.nii, they look the same. as shown below. Sorry for the photo taken by my cellphone because the two tools are installed in two PCs.

mrconvert 5tt/ROIs_strides.nii.gz -set_property strides -1,2,3

The figure below has three parts, the left two are the T1 image superimposed with label maps which name is marked by a red line, i.e., ROI.nii and ROIs_strides.nii.gz. Both are added to ITK-snap by the ‘open segmentation’ button. Meanwhile, the right one is opened by the ‘add another image button’. (Windows platform) And the right one demonstrate ROI.nii and ROIs_strides.nii.gz with no difference eighter.

So, here the problem only takes place when I first opened a T1 image and second opened the label image as a segmentation map.

As for the mrview, I think there is no problem, the fiber tracking results are well.

Left is ROI.nii and right is ROIs_strides.nii.gz.
This problem may not be a real issue, but I ask this question just for curiosity.


OK, the issue is indeed about strides, and this often manifests most obviously when overlaying images together, as you do here. First off, it’s comforting to see that there are no issues with mrview. The remaining issue will most likely be due to the ITKsnap making the implicit assumption that the two images have identical strides – which as you saw was not the case with your original ROI.nii file.

It looks like the conversion with -strides -1,2,3 fixes the issue? If you still need to fix the problem at source, you’ll need to modify the matlab script that produced the data in the first place – assuming that’s a possibility. But that would be outside the scope of this forum, really…

No, that wouldn’t have the effect you want. That will only copy over non-essential header information (e.g. comments, echo time, PE direction, …), but the strides are absolutely fundamental and handled elsewhere in the code.