[Insight-developers] Coordinate system semantics of ImageIOBase?

[Steve M. Robbins]

Hi,

I'd like to help MINC2 support move from Review into ITK proper.
Mantis issue #6038 suggests there are bugs lurking, so I'm writing
test cases for itkMINC2ImageIO.

To do so successfully, I need to understand the semantics of
its base class, ImageIOBase.  I'm getting tangled up in
coordinate system issues.

For example, "GetDimensions" is documented as follows

  /** Set/Get the image dimensions in the x, y, z, etc. directions.
   * GetDimensions() is typically used after reading the data; the
   * SetDimensions() is used prior to writing the data. */

... but I think the intent is that the dimension are NOT
world-space x, y, and z, but rather column, row, and slice.
Is that correct?

The method GetOrigin(int i) returns a double; I assume that
GetOrigin(0), GetOrigin(1), GetOrigin(2) return the column,
row, and slice, respectively, of the world-space origin.
Is that correct?

What should one assume about the world space coordinates?  I believe
it is safe to assume a right-handed coordinate system.  Do we assume
they should be LPS (as in DICOM)?  If so, do we convert incoming
coordinates (MINC uses the RAS convention)?  I would assume not as
I've read about folks using ITK for non-medical images like in
astronomy.  But if no conversion is done, how does an application
handle loading from multiple formats; e.g. DICOM and MINC?

The methods Get/SetDirection() deal with std::vector<double>; should
we assume the vector length for each axis is the same as
GetNumberOfDimensions()?  Is there any plan to address Mantis #5573?

There is no guarantee documented that ReadImageInformation() is called
before Read().  That effectively means that Read() has to call
ReadImageInformation() itself to ensure the dimensions, origin, etc
are set up, correct?

The documentation for Read() is as follows

  /** Reads the data from disk into the memory buffer provided. */
  virtual void Read(void* buffer) = 0;

Do we dump the bits into buffer exactly as they appear on disk with no
type conversion?  We're supposed to pay attention to the
ImageIORegion, right?  So the buffer is guaranteed to be large enough
to hold the region last set with SetIORegion() ?

MINC files can have either per-slice or per-volume intensity
transformation (i.e. slope and intercept); where should this be done?

A MINC file has metadata that describes the image layout; e.g. whether
it is XYZ (axial), XZY (coronal), etc.  When Read(buffer) is called,
do we dump the bits into buffer as they exist on disk or could they
get reordered into XYZ order?

Thanks for reading this far.  I realize I could probably glean most of
what I'm after by looking at code for existing ImageIOBbase
subclasses.  However, some of those could be buggy, so I'd like to get
the consensus from the developers.  I will try to put all the answers
I get into improving the documentation of ImageIOBase.

Regards,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20081228/70dedeea/attachment.pgp>