Hi Peter,
after a few full days of testing, I found the "issue". In fact,
there is no real issue. As was explained earlier, MITK works in
LPS. However, other tools work in RAS. For example, the tck file
format is saved with regards to the affine from the header of the
nifti file that was used to do the tracking. The only thing I
found out is that our colleague that coded tck support in Mitk
had already added a *-1 on the X and Y coordinates, so that they
fit with the volumes. Without knowing it, he was already doing
the RAS -> LPS flip.
The only question that remains, and that probably cannot be
answered is: what do we do with VTK files? If they were created
with a tool compatible with Mitk (or ITK/VTK), they'll be in LPS,
so everything will load fine. However, if they were created by a
tool working only with Niftis, and using the RAS convention,
they'll load incorrectly. Sadly, there's no easy way to detect
and correct that automatically.
Thanks everyone for your time!
--
Jean-Christophe
2015-04-23 3:46 GMT-04:00 Peter Neher <p.ne...@dkfz-heidelberg.de
<mailto:p.ne...@dkfz-heidelberg.de>>:
Hi JC,
the fibers in MITK are always represented as points in
physical space without any transform. We simply hand the
vtkPolydata, which contains the fiber points in world
coordinates, to the mapper. No additional transform is
applied. When saving fibers in vtk/vtp format, a possible
transform is not preserved anyway. The format does not
support that directly as far as I know.
Peter
On 22.04.2015 21:00, Jean-Christophe Houde wrote:
Hi Caspar,
it all makes sense. However, that raises another
semi-related question: we are currently coding a loader for
the .tck streamlines format. The .tck format (at least from
mrtrix version 0.2) saves the points in world space, using
the underlying image transform as the reference. So,
normally, points are saved as RAS.
When reading the file, we take the file as-is, and put the
points in a vtkPolyData without doing any transform. What is
surprising is that, even though MITK uses a LPS coordinate
system, our points (which follow a RAS coordinate system)
are displayed exactly in the correct spot...
Therefore, I'm wondering if there is any additional
transform that is done by the rendering code, or if there is
another aspect I didn't take into account...
Best,
--
Jean-Christophe
2015-04-22 13:25 GMT-04:00 Goch, Caspar Jonas
<c.g...@dkfz-heidelberg.de <mailto:c.g...@dkfz-heidelberg.de>>:
Hi Jean-Christophe,
MITK uses ITK for a lot of the image loading and Nifti
in particular [1,2]. Due to that it shares ITK’s
preferred orientation LPS. AFAIK the q/sform uses RAS as
a standard, so the flip is probably due to ITK
conversions as you assumed.
Does this answer your question?
Best,
Caspar
[1]
http://www.itk.org/Doxygen/html/classitk_1_1NiftiImageIO.html
[2]
http://www.itk.org/Doxygen/html/classitk_1_1ImageIOBase.html
*Von:*Jean-Christophe Houde
[mailto:jean.christophe.ho...@gmail.com
<mailto:jean.christophe.ho...@gmail.com>]
*Gesendet:* Mittwoch, 22. April 2015 17:07
*An:* mitk-users@lists.sourceforge.net
<mailto:mitk-users@lists.sourceforge.net>
*Betreff:* [mitk-users] Orientation and transforms question
Hi everyone,
I would like to have some clarifications on the
interpretation of orientations and transforms in Mitk.
First, what is the preferred orientation in MITK? LPS,
RAS, or something else?
Secondly, there always seems to be some modifications
applied to the affines of my images when I load them.
When looking at the affine information in the Nifti
image available in [1], using fslhd, I get a qform of
qform_code 1
qto_xyz:1 1.000000 -0.000000 0.000000 -125.834106
qto_xyz:2 0.000000 1.000000 -0.000000 -103.860718
qto_xyz:3 0.000000 0.000000 1.000000 -53.192493
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
and a sform of
sform_code 1
sto_xyz:1 1.000000 0.000000 -0.000000 -125.834106
sto_xyz:2 0.000000 1.000000 -0.000000 -103.860718
sto_xyz:3 0.000000 0.000000 1.000000 -53.192493
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
which are exactly the same, save for some -0 switched to
0 and vice-versa. Those switches should have no effect,
at least to my knowledge.
However, when loading this image in a software built on
Mitk (based on release 2014.10), the IndexToWorld
transform shown in the details of the image is
IndexToWorldTransform:
Matrix: -1 0 -0
-0 -1 0
0 0 1
Offset: [125.834, 103.861, -53.1925]
Clearly, there is a -1 factor on the 2 first rows of the
transform (and therefore, on the offset as well). I
guess it's a transform to go from RAS to LPS? If so, is
this always applied on Nifti images, or there are some
specific cases?
This really has some implications when we want to save,
for example, a VTK polydata file in a tool outside of
Mitk, and the load it inside Mitk.
Thanks for your time!
[1]
https://dl.dropboxusercontent.com/u/53085014/mitk/t1.nii.gz
---
Jean-Christophe Houde, M.Sc.
Research assistant
Sherbrooke Connectivity Imaging Lab
Sherbrooke University
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through
live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
