Hey Peter,
yes, flipping is not the problem... The problem is detecting when the flip
is needed for VTK files. Let's say I simply feed a VTK file to
Mitk-diffusion without any a priori knowledge of the tools used to generate
it, the ideal case would be to be able to detect if a flip is needed or
not. However, in real life, there is not foolproof solution... My comment
was more of a realization than a question.
Cheers!
--
JC
2015-04-28 5:43 GMT-04:00 Peter Neher <p.ne...@dkfz-heidelberg.de>:
> It's easy to correct. I also do it when tracking with mrtrix. You can use
> the MITK MiniApp MitkFiberProcessing to flip the fibers. Here is an example
> with mrtrix:
> 1. Use streamtrack to create a .tck file
> 2. use tracks2vtk to convert .tck to .fib (which is vtk)
> 3. MitkFiberProcessing -i myFibers.fib -p 110 -o myFlippedFibers.fib
> the -p option lets you specify the flipping dimension. in this case the
> fibers are flipped in x and y but not in z direction (110). so using -p
> 110 converts from RAS to LPS.
>
> Peter
>
>
> On 27.04.2015 14:58, Jean-Christophe Houde wrote:
>
> 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>:
>
>> 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>
>> :
>>
>>> 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]
>>> *Gesendet:* Mittwoch, 22. April 2015 17:07
>>> *An:* 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
>> https://lists.sourceforge.net/lists/listinfo/mitk-users
>>
>>
>
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
