[Insight-developers] Coordinate system semantics of ImageIOBase?

[Rupert Brooks]

Hi Steve,

I'm the reporter of that bug, and I would very much have liked to fix
it.  However, my estimate of how long it would take me was always a
bit too high for me to allow myself to start.  I'm happy to help you
out though if i can.  I assume you can reproduce the failures in the
test code that I posted.

After having read the code a few times, I found myself thinking that i
would have preferred to reimplement the whole thing using the MINC icv
interface.  I dont properly understand that interface, but it seemed
to me that it allowed pulling out an arbitrary block ("hyperslab") of
data, and scaling it consistently as desired.  By using an interface
that is not specific to MINC2, MINC1 could be supported.  Plus i think
it would result in a much smaller and cleaner MINCIO class.  It would
put most of the pressure to get things implemented correctly on the
minc interface developers - who are probably the better ones to do it.
Your thoughts?

As for your questions - i will leave them to the ITK folks - who can
answer how it ought to be.  In my usage of this class, I just wanted
the data in memory, with a directions matrix telling me which way it
was pointed.  However, i think theres an implicit assumption lurking
in ITK, that the direction cosines are right-handed, orthogonal, and
the data is evenly spaced.

Cheers,
Rupert B.



-- 
--------------------------------------------------------------
Rupert Brooks, Ph. D.

Attaché de recherches | Research Associate
Simulation des Matériaux Déformables | Simulation of Deformable Materials
Institut des matériaux industriels | Industrial Materials Institute
Conseil national de recherches Canada | National Research Council Canada
75, de Mortagne, Boucherville, Québec, Canada, J4B 6Y4
Gouvernement du Canada | Government of Canada

On Sun, Dec 28, 2008 at 6:28 AM, Steve M. Robbins <steve at sumost.ca> wrote:
> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFJV2LC0i2bPSHbMcURAsioAJ4qsehNG/Q0zoT+rL2O6ViCShUCywCfVXxA
> Nz2AhXbkZXcJrIxCHO7mXIQ=
> =WQqF
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
>