[Insight-developers] *.nii Endianness

[Kevin H. Hobbs]

I'm working on a set of files from ADNI with the extension ".nii".

I don't really know the differences between NIFTI and Analyze formats.

The values in the images differ when I read them with ITK or Paraview
from the values I get when I read them with Freesurfer or nifti_tool.

I believe this is an endianness issue and I believe that ITK is ignoring
the endianness of the data.

My machine runs Fedora 17 on x86_64 and I use ITK from a nightly
dashboard build.

When I read a particular image of pixel type short, with freesurfer or
nifti_tool I see values in { 20, 21 }.

When I read that same image in ITK or ParaView I see values in { 5120,
5376 }.

octave:13> disp(dec2hex ({20,5120,21,5376}))
0014
1400
0015
1500

I looked at the file with hexdump and in the data part I see 0014 and
0015 which are bigendian 20 and 21.

I asked google about nifti endianness and the nifti header :

http://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields

Endianness of the file is determined by looking at dim[0].

The dim field is an array of eight shorts beginning at offset 40.

dim[0] holds the dimension of the image and is restricted to integer
values from 1 to 7.

dim[1] to dim[7] hold the number of pixels along each dimension.

According to hexdump the 3 dimensional image has "00 03" at byte offset
40 so it must have been written on a bigendian machine.

In my ITK reader I have:

  // Reader
  typedef itk::ImageFileReader< SImageType >  ReaderType;
  ReaderType::Pointer reader = ReaderType::New();
  reader->SetFileName( in_file );
  reader->Update();
  std::cout
    << "Read by : "
    << reader->GetImageIO()->GetNameOfClass() << std::endl;
  std::cout
    << "Byte order is : "
    << reader->GetImageIO()->GetByteOrderAsString(
      reader->GetImageIO()->GetByteOrder() ) << std::endl;


and I get :

Read by : NiftiImageIO
Byte order is : OrderNotApplicable

ITK correctly interprets the bigendian dimensions "00a6 0100 0100" as
"166 256 256" instead of the rather strangely shaped little endian
interpretation "42496 1 1".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: OpenPGP digital signature
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20130702/13021854/attachment.pgp>