[MINC-users] Issue with itk_convert_xfm

[Robert D. Vincent]

Hi all,

My apologies for the lengthy message. There may well be issues with the
mnc2nii/nii2mnc pair, but part of the problem may be that itk_convert
doesn't obey one of MINC's conventions, which is that direction_cosines are
not supposed to encode axis flipping information. In some cases,
itk_convert can create a MINC file with direction cosines of [-1, 0, 0].
These might not be handled correctly in some MINC tools. Here's what I
mean, illustrated using one of the standard NIfTI example files:

% wget http://nifti.nimh.nih.gov/nifti-1/data/avg152T1_RL_nifti.nii.gz
% itk_convert avg152T1_RL_nifti.nii.gz RL.mnc
% mincinfo RL.mnc
file: RL.mnc
image: unsigned byte 0 to 255
image dimensions: xspace yspace zspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    xspace                     91            2          -90
    yspace                    109            2         -126
    zspace                     91            2          -72

% mincinfo -attvalue xspace:direction_cosines RL.mnc
-1 0 0

That -1 apparently means that the X axis is flipped, but MINC assumes that
any flipping is encoded in the step size. I'm sure itk_convert is
internally consistent, so of course it works just fine in many cases.

There are also inconsistencies between the "NIfTI-world" coordinate system
in Andrew's example and the MINC coordinate system. Again using the NIfTI
example file, I tried the following:

% make_transform 10 10 10 trans.xfm
% itk_convert_xfm trans.xfm trans.mat
% antsApplyTransforms --input avg152T1_RL_nifti.nii --transform trans.mat
--output out.nii --reference-image avg152T1_RL_nifti.nii
% fslview avg152T1_RL_nifti.nii out.nii

The transformation moves the image in the +X and +Y direction, but in the
-Z direction (see the enclosed screen capture - the original image is blue,
the transformed image is red). Given the original transform, I would have
expected that the signs of all three components of the transform would be
negative. This example uses no MINC tools other than make_transform, so I
suspect that there is some inconsistency between MINC's coordinate system
and the coordinate system assumed in itk_convert_xfm or antsApplyTransforms.

By way of comparison, performing the same transform using mincresample
(using -invert_transformation) moves the image -10 in X, -10 in Y, and -10
in Z  (at least according to the MINC conventions for these directions:
MINC's convention is for X to increase from patient left to patient right,
Y from patient posterior to patient anterior, and Z from patient inferior
to patient superior).

    -bert
​
 Screenshot from 2016-01-18 11:31:20.png
<https://drive.google.com/file/d/0B1186QfZ5IbuajJMcjZQblhmTEFWNXdVVnJJZ3Yzek05WVRR/view?usp=drive_web>
​

On Mon, Jan 18, 2016 at 3:18 PM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi Alex,
>
> I have a long missive about some related issues that is awaiting
> moderation...
>
> But to address the question about data types, part of the problem is that
> NIfTI defines a global floating-point slope and offset that is applied to
> _all_ voxel values, but there is no provision for per-slice scaling.
> Therefore nii2mnc can easily preserve the voxel data type, however, mnc2nii
> has to do quite a bit of work to determine if the data type can be
> preserved without losing precision. I think the default behavior was
> therefore just to convert everything to float.
>
>     -bert
>
> On Mon, Jan 18, 2016 at 3:07 PM, Alex Zijdenbos <zijdenbos at gmail.com>
> wrote:
>
>> However, itk_convert seems to suffer from a number of issues itself.
>>
>> - it does not appear to pay attention to the MINC_COMPRESS env var, so
>> MINC
>> output is not internally compressed (ugh!)
>> - it does not insert a history attribute, so minchistory doesn't like the
>> generated volumes
>> - it does not preserve the data type. From a few quick experiments, it
>> seems that any MINC volume that is not "unsigned byte 0 to 1" is converted
>> to a float NifTI volume. Not sure about the reverse direction. Is Kitware
>> friendly with Seagate? ;-)
>>
>> The latter point applies to nii2mnc/mnc2nii as well by the way; neither
>> converter seems to preserve the file data type, or only does it in certain
>> situations. It's not clear to me what the logic behind that is. Avoiding
>> issues due to slice-based scaling perhaps?
>>
>> I have now gotten to write an nii2mnc/mnc2nii wrapper that uses
>> itk_convert
>> with some mincreshape to fix the above issues; hoping that nii2mnc/mnc2nii
>> can be improved.
>>
>> -- A
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>