[Insight-developers] more notes on images with affine transformations in the header

brian avants stnava at gmail.com
Tue Jul 5 12:54:50 EDT 2011


hi everyone (hans and kent, especially),

currently, the image classes do not appear to check that the direction
matrix is orthogonal.

e.g. line 143   Modules/Core/Common/src/itkSpatialOrientationAdapter.cxx
//TODO:  Should check that directions are orthoganal.
  return direction;

what does appear to check orthogonality is writer classes.

i have only checked nifti for the moment.  test code is here:

  typename ImageType::Pointer image = reader->GetOutput();
  typename ImageType::DirectionType testdir=image->GetDirection();
  testdir[0][0]=1;
  testdir[0][1]=0.2;
  testdir[1][0]=0.5;
  testdir[1][1]=1;
  image->SetDirection(testdir);
  typedef itk::ImageFileWriter<ImageType> writertype;
  typename writertype::Pointer writer = writertype::New();
  writer->SetFileName("test.nii");
  writer->SetInput( image );
  writer->Update();

this will write out an image with an orthogonal direction matrix
presumably because nifti i/o forces this conversion (silently).

if you switch the extension to "mhd", then the direction matrix in the
output image is the same
as that set in code.   you can run a registration etc using this
non-orthogonal transform to physical space.  that is, if i use an
image with the above direction matrix as the "fixed" image and an
image resampled by that affine matrix (testdir), i get an identity
transform as the solution for the mapping between them.  this is the
use case we want to support .... and we do, to some extent, though
the support is undocumented and inconsistent.

in short, given current git itk, you can add a non-orthogonal transform to the
header of an image in code.  you can then run image operations on this
image without, it appears, any checking that the header orientation is
orthogonal.  obviously, it requires significant code review to check
if all filters that use direction
matrices will be correct if the header transformation is affine.

so, a minimal solution to this problem would be:

-- allow nii to write non-orthogonal direction matrices via the sform
   and setting the sform code to NIFTI_XFORM_ALIGNED_ANAT and qform code
   to UNKOWN

-- provide explicit warnings/exceptions in other i/o classes that
cannot write affine header txs.

this page has other details:

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

any thoughts?

b.a.


More information about the Insight-developers mailing list