[Insight-developers] Coordinate system semantics of ImageIOBase?

[Steve M. Robbins]

On Mon, Dec 29, 2008 at 12:10:22PM -0500, Luis Ibanez wrote:

> Since you list is long and very detailed, please find my
> comments below, interleaved with your text.

Thanks for your detailed responses.  You have answered
most of my questions, but a few questions were not
asked quite right so I have some follow-on clarifying
questions, below.


>> 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?
>>
>
>
>   GetDimensions() and SetDimensions() relate to the number of Pixel
>   along each of the directions of space.

What I meant to ask is: "what space?".  In your response, you are
calling the axes X, Y, and Z.  But this is an "image space" distinct
from the "world space", right?  This is the space that some people
would say uses IJK coordinates?

Furthermore, in this "image space" isn't it true that the pixel
spacings are precisely 1.  The spacing values in ImageIOBase
are for the world space only, right?


>> 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?
>>
>
>
>       This is a delicate point.
>
>       The standard in ITK is to use LPS.

So what happens if your image is not of a person?  Is the stance of
ITK that:

  1. ITK is only used for medical data, so there is always a
     patient-centric world reference frame.
or

  2. ITK specifically uses LPS for medical data.  Other image sources
     are free to choose their own world reference frame.

Sorry to belabour the point, but I am serious about augmenting the
documentation of this class and I want to be both specific and
accurate.  If the case is 2, are there any other reference systems
that have been settled on?  For example, I thought someone was using
ITK for astronomy.


>> 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() ?
>>
>
>        Yes, you must pay attention to (e.g. Respect) the ImageIORegion.
>
>        In the Read() method, you should simply read the pixel
>        data the way it is stored in the image file.
>
>        Pixel type conversion will be managed for you by the
>        ImageFileReader. Please see lines: 401-417 of
>        Insight/Code/IO/itkImageFileReader.txx

Understood.  But this gets in the way of pixel intensity scaling ...

>> MINC files can have either per-slice or per-volume intensity
>> transformation (i.e. slope and intercept); where should this be done?
>>
>
>
>         Potential intensity transformations must be done in the
>         Read() method. See for example: itkGDCMImageIO.txx:
>         lines 575-738.
>
>         Note that you must pay attention here to the pixel type,
>         to make sure that the resulting intensities can be stored
>         without losses.

This is the sticking point.  MR images often have "real" values
ranging up to 10^5 or 10^6 quantized down into 16 bits.  MINC may even
store these using *signed* shorts.  If the Read() method has to stuff
the signed shorts into the buffer provided AND rescale them back to
the "real" values of 10^5 or 10^6, we're sure to lose precision.

DICOM must suffer from the same issue; how is it handled there?

... steve peruses itkGDCMImageIO.cxx ...

So the rescaling blindly happens.  Does this not cause anyone
problems?  Oh, wait ... here's a subtlety that I didn't pick up on
previously: itkGDCMImageIO changes the IOComponentType to suit the
data in the file.

So am I correct to summarize the semantics of the IOComponentType as
follows?

  1. It is set according to the file data, NOT by the user of the
     ImageIOBase (subclass)?
  2. It represents the required component type to hold the data
     *after* applying any intensity transformation to the pixel
     values?

The intensity transformation in point 2 does include LUTs and DICOM's
Palette Colour transformations (meaning that the output would be RGB)?
What do you do when there are two LUTs for the image?

Thanks,
-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/20081229/4b1205fa/attachment-0001.pgp>