nii2mnc miscalculates minc start values

[jesperfr]

We need nii2mnc to convert Nifti files for processing in the Minc file format. But for about half of the files, the start values are miscalculated. It seems that the image orientation is correct (the cosines are ok), but the start values are wrong.

We are running on Ubuntu Server 64-bit 14.04 LTS and the code is from master.

$nii2mnc -version
program: 2.3.00
libminc: 2.3.00
netcdf : 4.3.3.1 of Dec 27 2015 17:18:07 $
HDF5   : 1.8.15

We have verified that the Nifti files are placed correct compared to the input Dicom files. If we use the dcm2mnc program, the minc files are OK!

$dcm2mnc -version
program: 2.01.01 built Dec 28 2015 15:25:58
libminc: 2.3.00
netcdf : 4.3.3.1 of Dec 27 2015 17:18:07 $
HDF5   : 1.8.15

We have tested on a number of Nifti files with Axial, Sagittal and Coronal orientation, and the conversion seems to fails primarily on Sagittal and Coronal oriented Nifti files.

[rdvincent]

Can you submit a test case (e.g. a NII file) that exhibits the problem?

[jesperfr]

example.zip
This is an example of one of the problematic files. If we convert the Dicom files directly to Minc, we get:

    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    176            1     -88.4114
    zspace                    256           -1      135.043
    yspace                    240           -1      118.052

But if we apply nii2mnc to the Nifti file inside the zip archive, the resulting Minc file has these dimensions:

    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    176            1     -86.5886
    zspace                    256            1     -119.043
    yspace                    240           -1      136.948

I can produce more examples if needed.

[rdvincent]

@jesperfr You might want to try to code from the develop branch. I just tried your example files with a build from the develop branch, and it seems more correct to me.

[jesperfr]

I have just tried the develop branch of nii2mcn:

$ nii2mnc -version
program: 2.4.01
libminc: 2.4.01
netcdf : 4.3.3.1 of Mar 13 2016 09:52:18 $
HDF5   : 1.8.15

But it still give exactly the same start values as the master branch, which clearly are different than for the Minc file created directly from the Dicom files:

$ nii2mnc test.nii developer_test.mnc
<nifti_image
  nifti_type = 'NIFTI-1+'
  header_filename = 'test.nii'
  image_filename = 'test.nii'
  image_offset = '352'
  ndim = '3'
  nx = '240'
  ny = '256'
  nz = '176'
  dx = '1'
  dy = '1'
  dz = '1'
  datatype = '4'
  datatype_name = 'INT16'
  nvox = '10813440'
  nbyper = '2'
  byteorder = 'LSB_FIRST'
  scl_slope = '1'
  scl_inter = '0'
  xyz_units = '2'
  xyz_units_name = 'mm'
  time_units = '8'
  time_units_name = 's'
  slice_dim = '3'
  slice_code = '5'
  slice_code_name = 'alternating_increasing_2'
  slice_start = '0'
  slice_end = '175'
  descrip = 'TE=2.980000019;sec=41916.7300;phaseDir=+'
  aux_file = 'NA'
  qform_code = '1'
  qform_code_name = 'Scanner Anat'
  qto_xyz_matrix = '0.00325232 0.0272039 0.999625 -92.0255 -0.998391 -0.0565039 0.00478601 124.217 -0.0566129 0.998032 -0.0269764 -110.653 0 0 0 1'
  qto_ijk_matrix = '0.00325232 -0.998391 -0.0566129 118.052 0.0272039 -0.0565039 0.998032 119.957 0.999625 0.00478601 -0.0269764 88.4114 0 0 0 1'
  quatern_b = '0.508129'
  quatern_c = '-0.477825'
  quatern_d = '-0.51967'
  qoffset_x = '-92.0255'
  qoffset_y = '124.217'
  qoffset_z = '-110.653'
  qfac = '-1'
  qform_i_orientation = 'Anterior-to-Posterior'
  qform_j_orientation = 'Inferior-to-Superior'
  qform_k_orientation = 'Left-to-Right'
  sform_code = '1'
  sform_code_name = 'Scanner Anat'
  sto_xyz_matrix = '0.00325234 0.0272039 0.999625 -92.0255 -0.998391 -0.0565038 0.00478602 124.217 -0.0566128 0.998032 -0.0269764 -110.653 0 0 0 1'
  sto_ijk matrix = '0.00325234 -0.998391 -0.0566128 118.052 0.0272039 -0.0565038 0.998032 119.957 0.999625 0.00478602 -0.0269764 88.4114 0 0 0 1'
  sform_i_orientation = 'Anterior-to-Posterior'
  sform_j_orientation = 'Inferior-to-Superior'
  sform_k_orientation = 'Left-to-Right'
  num_ext = '0'
/>
Using s-form transform:
  0.0033,   0.0272,   0.9996, -92.0255, 
 -0.9984,  -0.0565,   0.0048, 124.2169, 
 -0.0566,   0.9980,  -0.0270, -110.6525, 
  0.0000,   0.0000,   0.0000,   1.0000, 
xspace start:  88.4114 step:  -1.0000 cosines:  -0.9996  -0.0048   0.0270 flip: 1
yspace start: -118.0520 step:   1.0000 cosines:   0.0033  -0.9984  -0.0566 flip: 1
zspace start: 119.9569 step:  -1.0000 cosines:  -0.0272   0.0565  -0.9980 flip: 1

$ mincinfo developer_test.mnc 
file: developer_test.mnc
image: signed__ short 0 to 0
image dimensions: xspace zspace yspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    176            1     -86.5886
    zspace                    256            1     -119.043
    yspace                    240           -1      136.948

Which differs from the start values from the Minc file generated directly from Dicom (which is placed correct):

$ mincinfo dcm2mnc.mnc
file: dcm2mnc.mnc
image: unsigned short 0 to 4095
image dimensions: xspace zspace yspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                    176            1     -88.4114
    zspace                    256           -1      135.043
    yspace                    240           -1      118.052

[fristed]

@rdvincent Any progress on this issue. I have similar issues with nii2mnc.

[rdvincent]

@fristed No, I think I need a better test case to reproduce the exact problem. As far as I have been able to tell, we correctly convert the NIfTI header's transform. If you have a specific dataset that exhibits this issue I'd be happy to check it out.

[jesperfr]

sagittal.zip
coronal.zip
Great to hear!
I have attached two zip files as examples of sagittal and coronal orientations that both produce faulty start values when converting from Nifti to Minc.

Each zip file contains 3 files:
dcm2mnc_OK_zero.mnc (converted directly from Dicom to Minc. Correct start values)
dcm2nii_OK_zero.nii (converted from Dicom to Nifti. Correct start values)
dcm2nii2mnc_Not_OK.mnc (converted from Nifti file above to Minc. Not correct)

Please contact me, if you need more information or examples.
/Jesper

[fristed]

@rdvincent Can you reproduce the problem from the images uploaded by @jesperfr ?

[rdvincent]

@jesperfr It would be great if I could get the original DICOM for at least one of these examples.

[jesperfr]

@rdvincent These acquisitions were made on a patient, so the complete dataset can not be made available. Would the first and last Dicom slice be enough? They should provide enough spatial information to produce the image geometry and orientation.

[rdvincent]

That should be enough.

[jesperfr]

@rdvincent That sounds fine!
Here is the first and last dicom file for each of the two series mentioned above.
Sagital_Cororal_Dicom.zip

[fristed]

@rdvincent Did you have time to test the example?
@jesperfr Perhaps it would be easier to test if you upload the nifti file as well?

[rdvincent]

@fristed Thanks for the reminder, I have spent some time on this but I'm not convinced that I have resolved the problem. @jesperfr Having more test cases (ideally with complete DICOM) would be helpful.

[fristed]

@rdvincent I have another test case attached. This is a nifti file with a binary mask. When I do nii2mnc and mnc2nii the image is reshaped. Here are the XYZ dimensions:

Original: 240 256 176
nii2mnc: 176 240 256 (XZY order)
mnc2nii: 176 240 256
nii2mnc: 176 240 256 (ZYX order)

As you can see the dimensions are consistent after the first conversion, however, the dimension order changes.

I use a freshly updated version of the develop branch from minc-toolkit-v2
test.nii.gz

[rdvincent]

@fristed Are all of the files correct in the sense that they all have the same geometry in world space?

As of now, mnc2nii always reorders dimensions to yield an nii file with ZYX organization. This was done to make the conversion simpler, since for files with vector or time dimensions we must reorder things to be compatible with NIfTI (NIfTI supports arbitrary ordering of spatial dimensions, but enforces specific ordering of nonspatial dimensions relative to the spatial dimensions. MINC doesn't allows you to put a nonspatial dimension anywhere you like.

My plan is to change this to preserve the organization of the hyperslab if possible, but it hasn't made it into the code base yet. The original bug had to do with an error in the actual computation of the voxel-to-world transform - I think that is now fixed.

[jesperfr]

Hi Robert,
I would like to test the new voxel-to-world transform.
It is fixed in minc-toolkit-v2 master branch?
Yours,
Jesper Frandsen

2016-11-21 19:24 GMT+01:00 Robert D Vincent notifications@github.com:

@fristed https://github.com/fristed Are all of the files correct in the
sense that they all have the same geometry in world space?

As of now, mnc2nii always reorders dimensions to yield an nii file with
ZYX organization. This was done to make the conversion simpler, since for
files with vector or time dimensions we must reorder things to be
compatible with NIfTI (NIfTI supports arbitrary ordering of spatial
dimensions, but enforces specific ordering of nonspatial dimensions
relative to the spatial dimensions. MINC doesn't allows you to put a
nonspatial dimension anywhere you like.

My plan is to change this to preserve the organization of the hyperslab if
possible, but it hasn't made it into the code base yet. The original bug
had to do with an error in the actual computation of the voxel-to-world
transform - I think that is now fixed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ9zpJtMhljEX3mVf_jltWyBSzyFpVdEks5rAeHLgaJpZM4HvRj8
.

[rdvincent]

@jesperfr It should build in minc-toolkit-v2, but you should take care to check out the develop branch of all projects and subprojects.

[fristed]

@rdvincent Yes, they do align in world space. I guess a simple resampling will have to do, though it would have been nice to be able to convert back and forth in a consistent way.

[rdvincent]

@fristed I completely understand. I intend to add a special case to preserve the dimension ordering for spatial-only volumes, but I just haven't had time to implement it yet.

[fristed]

@rdvincent No worries. We all appreciate the hard work you put into developing and maintaining MINC 👍

[vfonov]

I made a new tag ( release-1.9.14) for minc-toolkit-v2 two weeks ago that contains all the updated subprojects as of then.
https://github.com/BIC-MNI/minc-toolkit-v2/releases/tag/release-1.9.14

[gdevenyi]

debs for trusty, xenial and debian jessie available at:
https://www.dropbox.com/sh/pah0ngr3rzu6j3j/AACLsWS1QoRhz1Rxeh-_2zSla?dl=0

[jesperfr]

Hi Robert, Thanks for your work!! I downloaded the developer branch 2 days ago and have just finished testing the nii2mnc conversion. All the cases that failed in March now completes correctly. Great work! Cheers, Jesper 2016-11-22 15:26 GMT+01:00 Robert D Vincent <notifications@github.com>:

…

@fristed <https://github.com/fristed> I completely understand. I intend to add a special case to preserve the dimension ordering for spatial-only volumes, but I just haven't had time to implement it yet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQ9zpCpBLGY8ZrU2ND5xXZTgzBAZDei2ks5rAvuFgaJpZM4HvRj8> .

[rdvincent]

@jesperfr Thanks for the confirmation. I'm going to leave this issue open for now to remind me to address the concern @fristed has raised.

[fristed]

@rdvincent While the fixes to nii2mnc seemed to work on all our test data, we have now discovered a dataset where mnc2nii produces a nifti file with swapped orientations.
mask.zip
Applying mnc2nii results in a mis-oriented volume and nii2mnc does not recover it. Perhaps you can take a look?

[gdevenyi]

Fixed