[MINC-users] Issue with itk_convert_xfm

[Robert D. Vincent]

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
>