[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