Mrview error: file "DWI.mif" is smaller than expected. Segmentation fault

Hi there,

I’m trying to get to grips with DWI brain mask estimation.

I create a mask using:

dwi2mask DWI.mif mask.mif

which completes successfully. DWI.mif if the file generated in the structural connectome tutorial using:

mrconvert data.nii.gz DWI.mif -fslgrad bvecs bvals -datatype float32 -stride 0,0,0,1

Now when I try:

mrview DWI.mif -roi.load mask.mif

I get the error: file “DWI.mif” is smaller than expected. Segmentation fault.

I don’t understand why mrview data.nii.gz produces an output after uncompressing, meanb0.mif (also generated following the tutorial) is also viewable, but DWI.mif is not. And also trying:

dwi2mask data.nii.gz mask2.mif

which completes and then:

mrview data.nii.gz -roi.load mask2.mif

Also leads to a segmentation fault, although this time not with the error message about being smaller than expected. I’m sure I’m just missing something obvious about the actual nature of DWI.mif thinking it is something it isn’t, but I do not understand these errors.

Any help would be appreciated,



There’s not many ways for this error to occur. The only thing I can think of is an unexpected error during write-back of the DWI.mif image when it was originally generated - most likely due to running out of space on the storage device. Are you sure there is enough space on your drive to store these new images?

Also, what platform are you running on? I’m surprised to see the commands generating the problem images completing without error…

I’m running through a remote desktop, I believe its using CentOS. I just recreated another DWI.mif file running with -info and -debug and didn’t see any issues produced. I then transfer the DWI.mif from the cluster to my desktop using WinSCP and use mrview in MingGW which leads to the error.

I think right now there may be too few tests and too many variables for us to be able to tell with any certainty what’s going wrong. With these kinds of errors, it’s infinitely useful (both for yourself and for us) to figure out one use case where the error occurs, and a similar use case where it does not: this narrows the possible sources of the error.

The one that’s screaming out to me is the use of WinSCP, coupled with the use of HCP data in the structural connectome tutorial. Either that program itself, or the Windows file system to which you are writing, may be imposing a file size limit, truncating the file on your local system (and that truncation may be silent). MRtrix3 predicts how large the file should be based on the number of voxels and the data type stored, and throws an error if there is a mismatch; which is there precisely to detect issues such as file truncation.

The “segmentation fault” may be an unresolved problem with mrview when an error is encountered before the Qt window is fully initialised. If your installation is older than a month or so there’s a chance that it’s already been fixed, but that would only prevent the subsequent “segmentation fault” error, not the fundamental problem with the file size. It would be beneficial to test whether or not the file DWI.mif can be used by other MRtrix3 commands on your local system, and if not what error is reported: this would tell us whether it’s strictly a GUI problem, or whether the file has been corrupted in transfer / storage and can no longer be read by any program.

Even though it is smaller due to the use of compression (and therefore less likely to be truncated), trying to open dwi.nii.gz on your local system would likely result in the same problem, since MRtrix3 has to un-compress the image in order to display it / operate on it anyway. A better test would be to downsample dwi.nii.gz on the remote system using mrresize, transfer it to your local system, and try to open that. Since the downsampled image should be smaller than the maximum file size limit, this test would tell us whether it is indeed the file size limit that’s introducing the problem, or whether files are being corrupted in transfer regardless of size.

You could get a clearer answer by running

mrinfo DWI.mif
ls -l DWI.mif

both on the cluster, and then separately on your local system. You can figure out the expected size of the file as the product of the image dimensions times the number of bytes per voxel (presumably 2 bytes if your data are stored as 16-bit integers), information that mrinfo will provide you with. You can then verify that the file is big enough from the output of ls -l. If they match on the cluster, but not on your local system, that would indicate an error in the transfer.

I ran

mrinfo DWI.mif
ls - l DWI.mif

on the cluster and the local machine and the exact same information was presented:
Dimensions: 145x174x145x288
Voxel size: 1.25x1.25x1.25x1
Data type: 32bit float

ls -l DWI.mif outputs: 4214432100

However using

du DWI.mif

The output does vary slightly: 4119684 cluster to 4115660 local

Also resizing with:

mrresize -scale 0.5 DWI.mif DWI2.mif

Produced a file that I successfully transferred to my local system and was able to view with mrview.

The original DWI.mif could not be used with for example mrresize, giving the same error of smaller than expected. I have successfully viewed files like 5TT.mif and meanb0.mif which are much smaller, transferred using WinSCP. So it would indeed appear to be a truncation issue.