ITK: Nifti file can not be opened after Jul 2020 commit

This Nifti file can not be opened after ENH: Prefer to use sform over qform when both are set. The file was generated by VINCI.

The issue was posted in the Slicer forum.

In particular, this block scope, starting at the line 1913, prevents loading. The error message “ITK only supports orthonormal direction cosines. No orthonormal definition found!” is not applicable.

Looks like that IO expects a header like this (a kind of IndexToPointMatrix)

…
pixdim 0.0 0.865759 0.865759 0.796 0.0 0.0 0.0 0.0
…
srow_x   0.865759 0.0      0.0      -54.975697
srow_y   0.0      0.865759 0.0      -54.975697
srow_z   0.0      0.0      0.796    -37.411999

but there is

…
pixdim 0.0 0.865759 0.865759 0.796 0.0 0.0 0.0 0.0
…
srow_x    1.0   0.0    0.0     -54.975697
srow_y    0.0   1.0    0.0     -54.975697
srow_z    0.0   0.0    1.0     -37.411999

The file worked with earlier releases, orientation and spacing were correct:

Spacing: [0.865759, 0.865759, 0.796]
Origin: [54.9757, 54.9757, -37.412]
Direction:
-1  0  0
 0 -1  0
 0  0  1

The file can be opened If the block is removed. Spacing and orientation will be like above again, sform will be preferred.

Just FYI, please close the issue if not possible to fix.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (15 by maintainers)

Commits related to this issue

Most upvoted comments

@issakomi please open a new issue with details of the problem

The problem with MINC2 for me is that it depends on HDF5, which is a a huge and complex library. I particularly dislike HDF5 because when we had any ITK or Python build problems or crashes then many times it turned out to be related to HDF5. If bringing in a large and complex dependency is acceptable then I would rather go for DCMTK or GDCM and use DICOM.

NRRD is nice and simple, human-readable, almost self-descriptive. A reader or writer can be implemented in a few hours in any programming language. Therefore, it nicely complements DICOM.

@issakomi My reading is that the file is incorrectly written. Based on the documentation for the nifti1 file format standard, the pixel dims SHOULD NOT BE USED if the sform_code > 0.

That implies that the sform matrix should have the pixeldims embedded in the sform values.

Previous versions of ITK trusted that the pixel dims were correct. This version explicitly checks that the pixel-dimentions are properly encoded.

   METHOD 3 (used when sform_code > 0):
   -----------------------------------
   The (x,y,z) coordinates are given by a general affine transformation
   of the (i,j,k) indexes:

     x = srow_x[0] * i + srow_x[1] * j + srow_x[2] * k + srow_x[3]
     y = srow_y[0] * i + srow_y[1] * j + srow_y[2] * k + srow_y[3]
     z = srow_z[0] * i + srow_z[1] * j + srow_z[2] * k + srow_z[3]

   The srow_* vectors are in the NIFTI_1 header.  Note that no use is
   made of pixdim[] in this method.