Issues reading and saving NIfTI images

[neurolabusc]

I tried med3web. When I attempt to load NIfTI images (File/OpenFromComputer) that work fine with MRIcroGL, FSLeyes, SPM, etc, I get the error "Wrong header data type". Examples are the reference images in the "Ref" folder of dcm_qa.

When I choose File/SaveAsNifti a NIfTI file is stored, but when I attempt to view it with popular tools (MRIcroGL, FSLeyes, SPM, etc), the slices are wrapped in the left-right direction (perhaps the file writing ignored the 352 byte header offset).

[neurolabusc]

Running the demo program and immediately saving the image creates an invalid file that takes 57672028 bytes on disk. One expects the file size to be at least 57672032 bytes (dim1 * dim2 * dim3 * nbyper)+352. It appears that the vox_offset is being set to zero (instead of 352) and the 348 byte header is not being padded with 4 extra bytes to align on quad-word boundaries. You can see this in Matlab (using SPM) or the command line (using FSL):

Matlab (SPM):

>>img = spm_read_vols(spm_vol('fx.nii'));
Error using read_hdr (line 65)
Bad vox_offset (0.000000) for "fx.nii".

Command Line (FSL):

$ fslhd fx.nii
sizeof_hdr     348
data_type      INT16
dim0           3
dim1           512
dim2           512
dim3           110
dim4           0
dim5           0
dim6           0
dim7           0
vox_units      Unknown
time_units     Unknown
datatype       4
nbyper         2
 ...
$ ls -l fx.nii
-rw-r--r--@ 1 rorden  staff  57672028 Mar 21 08:27 fx.nii

This violates the NIfTI specification:
https://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h
When the dataset is stored in one file, the first byte of image data is stored at byte location (int)vox_offset in this combined file. The minimum allowed value of vox_offset is 352; for compatibility with some software, vox_offset.

[VladislavShubnikov]

Thank you for trying our product (under active development stage now). You are absolutely correct - some Nifti files are not supported for read. We have downloaded your test files and have created internal task to read this data. Now our project is under deep changes: we are moving under ReactJS, and most functionality will be completely rewritten. In new version we will support (i hope) reading your files. New version of our med data web viewer will be ready in a month or two. If you need some urgent project modification, please contact me directly via email, mentioned in my personal github profile.

I tried med3web. When I attempt to load NIfTI images (File/OpenFromComputer) that work fine with MRIcroGL, FSLeyes, SPM, etc, I get the error "Wrong header data type". Examples are the reference images in the "Ref" folder of dcm_qa.

When I choose File/SaveAsNifti a NIfTI file is stored, but when I attempt to view it with popular tools (MRIcroGL, FSLeyes, SPM, etc), the slices are wrapped in the left-right direction (perhaps the file writing ignored the 352 byte header offset).

[VladislavShubnikov]

Addition: currently we are working in brunch "feature/reactjs". We already have fixed problem with reading your sample files. Below you can see how this file rendered in 3d mode

:

[itMaxiru]

after opening dicom and saving it to nifty and then opening the black image. How to fix it?

[DanilRostov]

@neurolabusc thank you for opening this issue.

We have create a bug for Nifti.
Also, recently we have released MRI-viewer version 2.0. You could try it out.
If you face any problems please open new issue with details and screenshots.
Thank you.

[neurolabusc]

@DanilRostov is the live demo version 2, or do I need to build a copy? I still have issues with the live demo linked from the project home page:

1. Open this page which I assume is MRI-viewer version 2.0
2. Click Open from URL and choose NIfTI image https://neurolabusc.github.io/niivue_volumes/fslmean.nii.gz
3. Nothing happens.
4. Drag and drop of uncompressed .nii NIfTI images from local device also has no response.
5. While I can open sample datasets like the lungs, the Save NIfTI button does nothing.

The NIfTI image is from this repository and has CORS permission for sharing as seen in this NiiVue live demo.

[DanilRostov]

@neurolabusc Thank you for sharing this details. This is another bug we're working on. Currently opening via external link broken.

We will post an update here as soon as it fixed.