[Insight-developers] astronomy images, SpecialCoordinatesImage and ImageIO

Kent Williams kent at psychiatry.uiowa.edu
Tue Aug 29 13:49:41 EDT 2006


You seem to be conflating two things that should be considered as 
separate issues.

For ImageIO you need to do these things to produce properly oriented images.

1. Set the image origin in world (or patient) coordinates. This is 
well-defined for medical images; for Astronomy, you need to choose a 
convention and stick with it.
2. Set the Direction Cosines for the image. This is 3 vectors 
representing the orthogonal X,Y, and Z images -- basically describing 
the way the local coordinate system of the image data is rotated from 
the canonical world coordinate system vectors.
3. Set the spacing in each dimension.

When you read in the image data, it normally is organized physically the 
same way it is on disk.  For most ImageIO classes, this boils reading 
the actual image data down to
1. Find the offset of the start of image data in the image file.
2. Read all the pixels in.
3. Byte swap if necessary.

ImageIO only understands this system of orientation representation. If 
you need to attach your complex physical to index transform parameters 
to the image, you pretty much have to add it as a Metadata object to the 
MetaDataDictionary for the ImageIO instance.  The ImageFileReader 
derivatives to read images will copy the ImageIO's metadata to the 
output image.

Your Image class (derived from itk::SpecialCoordinatesImage) can recover 
its physical-to-index transform parameters from the MetaDataDictionary 
the first time the Transform* functions is called, and store it as 
member data. Then, the transform parameters can be passed into your 
library code to do the actual transformation.  If you build ITK 
pipelines, they will copy the metadata from the input to the output, 
where that makes sense, and also pass the Orientation and Spacing down 
the pipeline.  But the ITK filters won't know anything about your 
special physical-to-index data; you'll have to set that yourself on the 
output image type in your application.

A useful class to consider deriving a new subclass from is 
itkOrientationAdapterBase (in itkOrientationAdapter.h). This defines a 
two-way interface to convert from your orientation representation to the 
ITK direction cosines -- i.e. just the rotation portion of your 
orientation representation.  This lets you go back and forth between 
your representation and the one in every type derived from itk::ImageIOBase.

I may not understand entirely what you're trying to do with reading & 
writing FITS data, but I hope this makes things a bit clearer.  Be sure 
and read through this page in the wiki for a thorough treatment of the 
orientation issue: http://www.itk.org/Wiki/Proposals:Orientation



Michael Halle wrote:

> Hello,
>
> I'm part of the team working to get FITS astronomy images into ITK. 
> During the last programmer's week, Doug Alan got volume reading 
> completed;  now we're working on quantitative information.
>
> I've hit a code structuring issue and I'd like some advice.  FITS 
> images have potentially complex physical to index transforms, and we 
> have a library that will take care of those transforms for us.  So, we 
> need to use an image that allows us direct access to the methods like 
> TransformIndexToPhysicalPoint and their inverses.
>
> It looks like a SpecialCoordinatesImage is a good base class for this 
> type of image, since these Transform* methods are the only ones left 
> abstract.
>
> The problem is that if we implement the Transform* methods in a 
> subclass of SpecialCoordinatesImage, we're specializing both the 
> ImageIOBase subclass and the ImageBase subclass to be able to read 
> FITS files.
>
> It seems like it would be nice to contain the FITS-specific 
> information in a subclass of ImageIOBase, and have a concrete subclass 
> of itkSpecialCoordinatesImage just use the Transform* information it 
> gets from this class.
>
> So, should we just take the simple approach and create both FITSImage 
> and FITSImageIO classes, or look at the cleaner but more complex 
> approach?
>
> Thanks for any advice....
>
> Michael Halle
> Surgical Planning Lab / Harvard IIC
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>



More information about the Insight-developers mailing list