[vtkusers] Correct anatomical orientation of volumes from Niftii and DICOM

[David Gobbi]

I'll have to provide some background before answering your questions,
please bear with me and hopefully everything will come together at the
end.

Originally (meaning around 20 years ago) VTK was very limited as far
as image display is concerned.  The original vtkImageMapper always
displayed images in a 2D pixel coordinate system where the first pixel
in the image was at the bottom left.

Of course, for most image file formats the first pixel in the file is meant
to be at the top left.  Such file formats include JPEG, DICOM, and many
others.  So in general the VTK image readers flip the image vertically,
and the FileLowerLeft flag can be used to tell the readers not to flip the
image.  There are some exceptions, however.

So the vtkDICOMImageReader flips the DICOM image vertically by
default, in order to make the 2D slices look right when displayed with
the vtkImageMapper.  It should be obvious that flipping the images
can mess things up as far as the 3D coordinate system is concerned.
Also, it's 2018 and nobody should be using vtkImageMapper anymore,
there are much better ways of displaying images in VTK.  By using
3D image rendering and by setting the ViewUp of the camera, one
can keep the images in their original orientation and still display them
properly.

The vtkGDCMImageReader does this same vertical flip when reading
images, and of course I strongly recommend setting FileLowerLeftOn()
to stop it from doing so.

So now we get to your first question.  The readers do, indeed, try to
handle certain orientation issues themselves.  But often what they do
hurts more than it helps.  That is why, in that document of mine that you
linked to earlier, I recommend setting up the reader so that it reads the
pixels directly into memory without any flips or other mangling.  Once
you have done so, you can go to the official, standard documentation
for the file formats to figure out how to properly orient and position the
images in 3D space.

For your second question, I'll turn it into an exercise.  You know that
in DICOM, left is +x and anterior (towards the nose) is -y.  So first,
verify that this is the view orientation that you are providing for your
'axial' view.  When I say verify, I don't mean to do so by displaying
an image and seeing if it looks like... that's not independent verification!
Verify with vtkAxesActor or with something similar:
https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/DisplayCoordinateAxes/

Once you've verified that the camera is correct, you can display
output of vtkDICOMImageReader and vtkGDCMReader and check
which is correct.

After you've made sure that everything is correct for the axial view,
you can do the same for the other views (again, using vtkAxesActor
to verify the camera).

That should be enough to get you started.

 - David



On Fri, May 11, 2018 at 7:44 AM, ochampao <ochampao at hotmail.com> wrote:

> Hi David.
>
> Thanks for the detailed reply. It's clear I need to familirize myself more
> with the two formats.
>
> I have a few follow-up questions:
>
> 1) I understand that we need to look into the information stored in each
> file to determine how to position and orient the volume. What is not clear
> to me is how much of this is done by the readers themselves. Are there some
> rules/conventions/logic that each reader follows when orienting and
> positioning the reconstructed volume in vtk's world coordinate system? Can
> we make some assumptions about the reconstructed volume (vtkImageData)
> generated by the reader?
>
> 2) Let's put Niftii on the side for a moment. With in my code above the
> same
> volume appears with it's x and y axes reversed when using
> vtkGDCMImageReader
> (loadDicomGDCM()) compared to when using vtkDICOMImageReader (loadDicom())?
> How can I ensure the correct volume orientation (or equivalently the
> correct
> camera perspective)?
>
>
> Panos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtkusers/attachments/20180511/1abbbb7d/attachment.html>