[Insight-users] Orientation pb itk/Volview UPDATE possible bug Volview?!

[SCHMID, Jerome]

Hi,

Well it seems that my previous post was in part erroneous but I was confused by a strange Volview behaviour. BTW I have been looking for a Volview mailing list, is there anyone?

My purpose: have an image loaded in a way that the coordinate system in volview is the same that the itk one: the first voxel of the data is the origin voxel, x is from left to right, y from top to bottom (as in usual image system, ), z such as we have a right handed frame.

If we look at the axial view in Volview (usually bottom left panel) a correctly loaded image with such constrains must have its origin in the bottom right corner of the view. For clarity (I hope...!) and example, imagine the left picture is an image stored in memory like this: X### ###@ ####

Loaded in a raw fashion in a viewer will produce:

X###
###@    origin X is thus top left
####

in volview one should see in the axial view:

####
@###    as expected as the origin in the axial view is in the bottom right corner
###X

I tried loading in volview raw images, analyze Image (a .hdr and .img pair) and vtk images (.vtk). I have been looking for the correct orientation settings in volview in order to reach my goal:

- Load a pure raw file > Volview settings RAS + Posterior + Right gives the correct result.

- Load a hdr image (created with importImageFilter + analyze itk writer filter) > Volview settings RAS + Posterior + Left gives the correct result. So loading with default orientation options (SAR + Anterior + Right ) does *not* give correct results for our purpose.

- Load a vtk image (created with importImageFilter + vtk itk writer filter) >
3 behaviours (here is the possible Volview bug):
1) in the directory of the foo.vtk file, there are _not_  a foo.hdr/foo.img Analyze pair ( notice the same name wihtout extension for the files ) > the loading with the _default_ volview settings in orientation gives the correct result. Is because Volview is based on vtk and the file to load is vtk...?
2) in the directory of the foo.vtk file _there is a foo.hdr_  but not the foo.img > Okay the behaviour is like 1)
3) in the directory of the foo.vtk file _there is a foo.hdr *and* the foo.img > The behaviour is odd: the hdr info is used instead of the vtk header info! The origin is not set ( such as in the analyse format which means to not support the origin option) and the orientation is like in the hdr file....

I erased always the .vvi files produced by volview and I hadn't noticed any temp/bak files in the volview directory that could explain this phenomenon...A possible bug?

Regards,

Jerome

>>
>>
>>>Hi,
>>>
>>>I am encountering some orientations issues in itk/Volview, I post here even if it is a volview related topic as it deals with itk itself also.
>>>
>>>The pb is simple. Let's suppose I work on 2D images for simplicity and that volview is able to load such images.
>>>First I load a raw image in volview with the _default_ orientation options (RAS + anterior + right). The result is as expected: in the axial view the R(ight) part corresponds to the left part of my raw image (the view is flipped thus).
>>>
>>>Now in an itk prgm, I use an importImageFilter with the raw data + a writter to Analyze or vtk format. The result is then a file .hdr or .vtk readable in Volview.
>>>If I load this new file in Volview, always with default orientation options, the result is not as previously: the axial view looks like the raw image, which means that actually the image is flipped vertically. >From a visualization viewpoint this could be not a pb, but the  (x,y) coordinates are now "erroneous".
>>>
>>>I suspect that the Vtk and Analyse writer sets a kind of default orientation that Volview recognizes.
>>>
>>> 
>>>
>>I've had a similar problem several times before.
>>
>>First a clarification,
>>
>>The default RAS co-ordinates in VolView are R = +x
>>A = -y (increasing rows... is equivalent to decreasing y )
>>
>>With raw files, things are as expected.. Usually what I would like to have, is not the default settings, but
>>R = +x
>>A = +y
>>This ensures that the co-ordinates are displayed correctly (with respect to  the ITK co-ordinate system)
>>
>>On a related note, I've had the same problem with paraview in the past
>>For instance:
>>a VTK file and a MetaImage file both written out using ITK:
>>end up with different co-ordinate conventions when read in using Paraview:
>>
>>The VTK image is flipped vertically, the meta image file is not !
>>
>>Its the same with VolView too...
>>
>>I suspect the VTK writer in ITK may not be doing the right thing, but I haven't looked at it.
>>
>>>So here come 2 questions:
>>>
>>>- Is there a way to bypass the orientation setting, i.e. the physical origin will be always defined as the bottom-left pt?
>>> 
>>>
>>The RAS - xyz mapping is what defines where the origin is going to be. Not sure what you mean by "the physical origin will be always defined as the bottom-left pt?". I don't think you want to bypass it. What would be useful is if each file format's orientation is consistently interpreted from its headers by all toolkits.
>>
>>>- How an itk reader filter will behave with such .hdr and .vtk files? Will it take the raw data or apply some kind of orientation correction due to some orientation setting?
>>> 
>>>
>>As far as I've see, if they were written out using ITK, they read correctly using ITK. With MetaImage/Analyse files, you can specify the orientation while creating it.
>>
>>>Sorry for the difficult reading but without images it may sound a little unclear.
>>>
>>>
>>>Thanks!
>>>
>>>Best Regards,
>>>
>>>Jerome
>>>
>>>_______________________________________________
>>>Insight-users mailing list
>>>Insight-users at itk.org
>>>http://www.itk.org/mailman/listinfo/insight-users
>>>
>>> 
>>>
>
>
>_______________________________________________
>Insight-users mailing list
>Insight-users at itk.org
>http://www.itk.org/mailman/listinfo/insight-users
>