[Insight-developers] Coordinate system semantics of ImageIOBase?

[Rupert Brooks]

Hi Steve,

I took your code and tried to compile it.  However i got blocked
compiling your tests on Windows (see below).
so i went back and used the tests that Andrew and I were using.  Heres
where im at so far, i will pursue it
a bit further this week.

Im ccing the list because, well, it will be good to get rid of this
bug and i saw that Luis is probably working on
it as well.

Ok - first my compilation troubles.
1 - Minor correction: #include <cctype> is needed in
itkMINCImageIO.cxx.  std::lower lives there according
to the standard, i think.  Anyway, visual studio thinks it does.
Probably it gets dragged in by one of the other
includes on unix.

2 - larger problem: popen   popen is not standard on windows, but your
CreateMincFile.h uses it.
Ultimately this is a sidetrack issue, as its just being used for the
testing. However, it blocked
me from compiling your test suite for the moment.

3 -boost issues - i had trouble getting FIND_PACKAGE(Boost to work
properly.  Eventually i just took it
out of the CMake.  On windows I have Boost in my include path and it
does some kind of magical auto
linking so this didnt pose any problems.  This is almost certainly a
configuration problem on my end.

As for the pre-existing tests- i had to take out the part about
dimorder to get them to work.  Its non-standard
anyway, so that is not really a problem.  However, test 01 fails right
away with data not matching expectations
and i stopped there.  I havent had time to dig into the why yet.  The
good news, however, is that the file
'thisbreaksreader' no longer causes a nasty crash in the HDF library.

I read through the code a bit.  Its gone from about 1600 lines to
about 400, making reading a lot easier :-).
Just a couple questions:

MINC and ITK use different ways of specifying the origin / offset of
the coordinate system.  I believe
that MINC uses the xstart, ystart, zstart as the distance _along the
x,y,z direction cosines_, while
ITK places the origin _such that pixel 0,0,0 is at the origin_.
However, it looks to me (line 315, itkMINCImageIO.cxx)
that you are putting the start into the origin, which would only work
when the direction cosines are
lined up with the coordinate axes.  Maybe im out in left field here though?

If the spacing is negative (legal in MINC) then the direction cosine
gets flipped.  Good so far, but Isn't it also necessary
to either flip the image in memory, or shift the origin to the other
end of the negative axis?

Anyway, let me finish by saying nice work, and I really appreciate you
taking this on.

Cheers,
Rupert B.


On Fri, Jan 9, 2009 at 7:03 AM, Rupert Brooks <rupe.brooks at gmail.com> wrote:
> Steve,
>
> I'll go through it in detail this weekend.  As for supporting only
> MINC2, ease of implementation justifies the choice for me ;-)
>
> Thanks for working on it, i think its really going to be helpful
> Rupert

<snip>

-- 
--------------------------------------------------------------
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