ERROR message

1

Dear MRtrix team,

I’m getting the following error message when I try to open files with Mrview:

bash-3.2$ mrview dwi.mif
mrview: [ERROR] invalid first line for key/value file “dwi.mif” (expected “mrtrix image”)
mrview: [ERROR] error opening image “dwi.mif”

It happens in every file of the same folder, niftis and mif. They were working 30 min ago.

Thanks

2

Hi @Inaki,

Did you update MRtrix (i.e. git pull and ./build) in those 30 minutes, or do anything else to those files?

Cheers,
Thijs

3

No I did not. It was running tckgen, when it finished I tried to check the tracks and I it did happen.

bash-3.2$ tckgen fod.mif -seed_image ROIS/Left_PIm.nii.gz -include ROIS/Left_MT_GM.nii.gz -exclude segmentation/struct2DTICSF.nii TRACKS/PIm_MT_L.tck -num 20000 -unidirectional -force
tckgen: [WARNING] existing output files will be overwritten
tckgen: [100%] uncompressing image "ROIS/Left_MT_GM.nii.gz"
tckgen: [100%] uncompressing image "ROIS/Left_MT_GM.nii.gz"
tckgen: [100%] uncompressing image "ROIS/Left_PIm.nii.gz"
tckgen: [ 16%] 1999911 generated, 3259 selected
tckgen: [WARNING] less than desired streamline number due to implicit maximum number of attempts; set -maxnum 0 to override
tckgen: [100%] 2000000 generated, 3259 selected
bash-3.2$ mrview dwi
dwi.mif dwi.nii.gz dwi_e.mif
bash-3.2$ mrview dwi.
mrview: [ERROR] unknown format for image "dwi."
mrview: [ERROR] error opening image "dwi."
bash-3.2$ mrview dwi.nii.gz
bash-3.2$ mrview dwi.mif
mrview: [ERROR] invalid first line for key/value file “dwi.mif” (expected “mrtrix image”)
mrview: [ERROR] error opening image "dwi.mif"
bash-3.2$ mrview mask.mif
mrview: [ERROR] invalid first line for key/value file “mask.mif” (expected “mrtrix image”)
mrview: [ERROR] error opening image "mask.mif"
bash-3.2$ mrview v.mif
mrview: [ERROR] invalid first line for key/value file “v.mif” (expected “mrtrix image”)
mrview: [ERROR] error opening image “v.mif”

4

Hi Inaki,
Can you open other images with mrview successfully?

Sounds like something has happened to the dwi.mif file. Perhaps you have renamed it from a *.nii to a *.mif file without converting it with mrconvert?

Cheers,
Dave

5

Yes, images in other folders are OK. The mif folders were converted from Dicom, but also binary .mif masks are corrupted.

Well, I guess I have to repeat it anyway.

Thanks

6

Hi there,

  1. Can you clarify whether both .mif and NIfTI images are refusing to open, or only .mif files? Your initial post suggested the former, but in the terminal output it looks like mrview dwi.nii.gz executed successfully.

  2. If you install hex editor software, you will be able to see the raw binary contents of any file. Attaching a screenshot from such a program highlighting the start of one of the problematic files would be helpful for us in diagnosing where the problem lies.

  3. Have you performed a system update recently, or made any changes to your locale settings? The image format is verified by simply comparing the very start of the file contents to the string “mrtrix image”; there’s an outside chance that such a change may be sufficient for that basic string comparison to start failing.

Rob

7

This is really strange - no idea how a command could corrupt images it wasn’t told to access… But:

If NIfTI files are affected too, it really points at some form of filesystem corruption. Presumably the error message is different? Just out of interest, what does ls -l report? Are the files still the expected size…?

My first thought here is that you might have run out of space on the storage device - that often leads to strange issues that aren’t immediately obvious.

Another possibility is a subtle bug in the kernel-side filesystem code. What OS are you running, and what drive are you writing to? For example, are you running on Linux with a Windows-formatted external drive (particularly NTFS)? I’ve seen that cause issues recently.

And as @rsmith said, a simple check for mif images is to look at the content - the header is human-readable text. But there’s no need for a hex editor, you can take a look with a simple head dwi.mif (this dumps the first 10 lines by default). The first line should be “mrtrix image”.

8

If NIfTI files are affected too, it really points at some form of filesystem corruption. Presumably the error message is different? Just out of interest, what does ls -l report? Are the files still the expected size…?

sorry, only mif files are wrong. ls -l reports

w-r–r–@ 1 carrilc MONASH\Domain Users 0 21 Apr 15:30 dwi.mif
-rw-r–r–@ 1 carrilc MONASH\Domain Users 82271925 21 Apr 15:49 dwi.nii.gz
-rw-r–r–@ 1 carrilc MONASH\Domain Users 0 21 Apr 15:29 dwi_e.mif
-rw-r–r–@ 1 carrilc MONASH\Domain Users 0 21 Apr 15:35 ev.mif
-rw-r–r–@ 1 carrilc MONASH\Domain Users 0 21 Apr 15:33 fa.mif
-rw-r–r–@ 1 carrilc MONASH\Domain Users 508454 21 Apr 15:34 famasked.nii.g

My first thought here is that you might have run out of space on the storage device - that often leads to strange issues that aren’t immediately obvious.

that is not the problem,

Another possibility is a subtle bug in the kernel-side filesystem code. What OS are you running, and what drive are you writing to? For example, are you running on Linux with a Windows-formatted external drive (particularly NTFS)? I’ve seen that cause issues recently.

Im running El Capitan, the drive is a Seagate_Backup_plus, actually using NTFS driver.

And as @rsmith said, a simple check for mif images is to look at the content - the header is human-readable text. But there’s no need for a hex editor, you can take a look with a simple head dwi.mif (this dumps the first 10 lines by default). The first line should be “mrtrix image”.

No output after head dwi.mif/

It seems it only happens in the external driver data.

Inaki

9

All of the .mif files in that directory have a size of 0; so there’s no chance of reading anything from them. This can happen if the target filesystem runs out of storage space at write time, but isn’t the only possible reason.

The most useful thing for us would be if you can consistently reproduce the problem within a specific set of circumstances; there’s not enough information for us to work with if it’s just a single observation of an error. So, for instance:

  1. Does the issue occur exclusively when writing to the external NTFS file system? Let us know what other targets (file system & internal/external) you are or are not able to successfully write to.
  2. Is it influenced by whether or not the external drive is ‘safely’ removed after writing to it?
  3. Is it definitely confined to the .mif file format? I.e. Can you write multiple .mif files to the drive and they are all empty, then write multiple .nii files to the drive using the same command and they are all OK? If so, what about other image formats?
10

The one difference between the .mif files and the .nii.gz files is that the latter is compressed. This means the data will be held in RAM and written to disk subsequently using standard writes. The .mif file on the other hand will be accessed via memory-mapping - at least since the changes in a recent commit a couple of weeks ago. It could be that the MacOSX code for NTFS doesn’t handle memory-mapping very well, especially considering that writing to NTFS volumes is not officially supported on MacOSX. If this is correct, I’d expect writing .mif.gz files would be OK, but writing .nii files (uncompressed) would also be affected.

11

Actually, forget that last post - this wouldn’t explain why the files seemed fine half an hour prior to the problem showing up, as per the original post… I do think this is going to turn out to be a buggy NTFS implementation on MacOSX…