[vtkusers] Announcement: New image rendering classes for VTK

Mon Jun 27 13:14:41 EDT 2011

I just want to explain the coord issue in a bit more detail:

By default, most VTK image readers flip the images from their original
top-to-bottom rasterization to a bottom-to-top rasterization instead.  This
can be turned off by setting FileLowerLeftOn() so that VTK keeps the
original rasterization order.  Anyone that cares about image orientation
should ALWAYS keep the original rasterization order, in my opinion, which
means using FileLowerLeftOn() in the reader.

Getting image orientation from the file header is another important thing.
 I recommend getting the ImageOrientationPatient and ImagePositionPatient
and simply storing them in a matrix for use in VTK, i.e. to be used as the
matrix for actors and other prop3Ds, or for reslicing images to get them
into the same coordinate system before combining them.

Finally, with the viewer, I recently added methods to
vtkInteractorStyleImage to allow setting the "up" vector and "left-to-right"
vector for the view window, so that you can establish the correct view
orientation for axial, sagittal, coronal.  Conversely, the same can be done
by setting the  camera position, focal point, and view-up.

A warning: the vtkImageViewer gets the image orientation wrong for any
images that are rasterized from top-to-bottom like DICOM or JPEG.  I advise
that people do not use vtkImageViewer.  The vtkImageViewer2 class is not
much better, its default setting for XY, YZ, and XZ orientations are
incorrect for medical images.  I recommend that people using VTK for medical
images just use a plain vtkRenderWindow in combination with
vtkInteractorStyleImage.

 - David

On Mon, Jun 27, 2011 at 9:12 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> These are not viewer classes, they are just rendering classes and are
> therefore completely agnostic with regards to DICOM.
>
> But for the record, I do not understand all the difficulty people have with
> this issue.  When I view DICOM images, I just do the following:
> 1) I equate the VTK world coordinate system with the DICOM patient
> coordinate system
> 2) I set the data-to-world transform from the information in the DICOM
> header
> 3) I set up the camera in my viewer to display the image in the desired
> orientation
>
> So please let me go on the record as saying that there is no "difference
> between VTK coords and DICOM coords".  That is a vicious rumour that people
> spread for reasons that are beyond me.  You can define the VTK world
> coordinate system to be whatever you want.
>
> The problems that people have are due to the following:
> 1) The VTK image readers and importers don't deal with DICOM image
> orientation correctly
> 2) The vtkImageViewer does not deal with DICOM image orientation correctly
> 3) For each image, you must keep a 4x4 matrix describing the DICOM
> orientation
>
> If someone were to fix the readers and the viewer, this DICOM vs. VTK issue
> would mostly disappear.
>
> Regarding the second question, it's not up to me when these go into a
> stable release, Kitware controls the release schedule ;)
>
>  - David
>
>
>
> On Mon, Jun 27, 2011 at 8:34 AM, Jothy <jothybasu at gmail.com> wrote:
>
>> I wonder whether these classes has any fix for the different coordinates
>> used by DICOm and vtk?
>>
>> Thank you
>>
>> Jothy
>>
>>
>> On Mon, Jun 27, 2011 at 3:31 PM, Lic. José M. Rodriguez Bacallao <
>> jmrbcu at gmail.com> wrote:
>>
>>> so, when this classes will be available in stable vtk?
>>>
>>> right now I am working with an snapshot from vtk git.
>>>
>>> On 6/27/11, Aashish Chaudhary <aashish.chaudhary at kitware.com> wrote:
>>> > Hi David,
>>> >
>>> > What Aaron said  +  Awesome!! (one more time)
>>> >
>>> > Looking at the features list, I think our project will be greatly
>>> > benefited by your work. Thanks for sharing your work.
>>> >
>>> > Regards,
>>> > Aashish
>>> >
>>> >
>>> > On Mon, Jun 27, 2011 at 8:47 AM, Aaron Boxer <boxerab at gmail.com>
>>> wrote:
>>> >> Awesome!!! Nice work; can't wait to use these classes.
>>> >>
>>> >> Aaron
>>> >>
>>> >> On Sun, Jun 26, 2011 at 6:15 PM, David Gobbi <david.gobbi at gmail.com>
>>> >> wrote:
>>> >>> I'm pleased to announce that I have finally completed my work on
>>> several
>>> >>> new
>>> >>> image rendering classes for VTK.  They are in the VTK git development
>>> >>> tree,
>>> >>> and a few of you have already tried them out (if you are one of those
>>> >>> people, note that several feature and performance enhancements were
>>> added
>>> >>> last week).  More info can be found at the following wiki page:
>>> >>>
>>> >>> http://www.vtk.org/Wiki/VTK/Image_Rendering_Classes
>>> >>>
>>> >>> In brief, these classes replace vtkImageActor and provide a much
>>> higher
>>> >>> level of functionality.  They are new VTK actor and mapper classes
>>> >>> specifically meant for image viewing.  What they are not: they are
>>> not
>>> >>> widgets or viewers, although they provide machinery that can be used
>>> to
>>> >>> write widget and viewer classes.  In other words, they are meant for
>>> >>> people
>>> >>> who like to roll their own image viewers.
>>> >>>
>>> >>> The three new classes that I recommend for people to use are the
>>> >>> following:
>>> >>> vtkImageSlice - the new actor class for images
>>> >>> vtkImageResliceMapper - mapper for drawing images for MPR viewers
>>> >>> vtkImageProperty - for controlling lookup tables, window/level,
>>> opacity,
>>> >>> etc
>>> >>>
>>> >>> Typical use cases:
>>> >>>
>>> >>> 1) For an MPR viewer, use vtkInteractorStyleImage and set it to your
>>> >>> desired
>>> >>> view orientation. Then set the following properties in
>>> >>> vtkImageResliceMapper:
>>> >>> mapper->SliceFacesCameraOn()
>>> >>> mapper->SliceAtFocalPointOn()
>>> >>> The interactor will then allow you to pan, zoom, window/level, and
>>> (in 3D
>>> >>> mode) rotate and slice.  See
>>> >>> VTK/Examples/ImageProcessing/ImageInteractorReslice.py for an
>>> example.
>>> >>>
>>> >>> 2) For a 3D ortho object, use multiple vtkImageResliceMapper objects,
>>> and
>>> >>> for each one make a vtkPlane that describes the normal and position
>>> of
>>> >>> the
>>> >>> slice to extract. Then call these methods:
>>> >>> mapper->SetSlicePlane(plane)
>>> >>> mapper->ResampleToScreenPixelsOff()
>>> >>> Turning the "ResampleToScreenPixels" option Off makes rotation
>>> faster, so
>>> >>> it
>>> >>> is recommended when rotations are going to be common operations.
>>> >>>  Example:
>>> >>> VTK/Rendering/Testing/Cxx/TestImageResliceMapperOffAxis.cxx
>>> >>>
>>> >>> Features:
>>> >>> 1) oblique views (obviously!)
>>> >>> 2) nearest-neighbor, linear, and cubic interpolation
>>> >>> 3) modify image orientation with respect to world coords by setting
>>> >>> vtkImageSlice's UserMatrix
>>> >>> 4) fully multi-threaded reslicing and color mapping operations
>>> >>> 5) streaming, i.e. only pulls the data needed for rendering
>>> >>> 6) works well with very large images (as long as they fit in memory)
>>> >>> 7) LOD-style interaction (switches to faster rendering for
>>> interaction)
>>> >>> 8) blend images by adding multiple vtkImageSlice objects to a
>>> >>> vtkImageStack
>>> >>> 9) checkerboard images by setting "CheckerboardOn" in the
>>> >>> vtkImageProperty
>>> >>> 10) thick-slab views (see vtkImageResliceMapper for details)
>>> >>> 11) works with vtkCellPicker for picking image voxels as points or
>>> cells
>>> >>>
>>> >>> For large image viewing, on a 4GB computer (64-bit OS X) I've
>>> displayed
>>> >>> images up to 3GB in size with full interactivity, but YMMV.  As long
>>> as
>>> >>> the
>>> >>> mapper's ResampleToScreenPixels option is On, the mapper will never
>>> try
>>> >>> to
>>> >>> load the full image onto the GPU (which is what causes the
>>> vtkImageActor
>>> >>> to
>>> >>> be slow for large images).  The size of the images that you can
>>> display
>>> >>> is
>>> >>> limited only by main memory, I have displayed stacks of RGB images
>>> that
>>> >>> are
>>> >>> 10000x10000 pixels in size.
>>> >>>
>>> >>> I do not plan to push these into the VTK 5.8 release (even if Kitware
>>> >>> were
>>> >>> to give me the go-ahead), because the VTK development tree has
>>> diverged
>>> >>> too
>>> >>> far from the VTK 5.8 release tree.  These new image classes are only
>>> >>> possible due to recent improvements that I've made to the picker,
>>> lookup
>>> >>> table, and image reslice classes and they probably depend on a
>>> handful of
>>> >>> recent changes made by other people, as well.
>>> >>>
>>> >>>  - David
>>> >>> _______________________________________________
>>> >>> Powered by www.kitware.com
>>> >>>
>>> >>> Visit other Kitware open-source projects at
>>> >>> http://www.kitware.com/opensource/opensource.html
>>> >>>
>>> >>> Please keep messages on-topic and check the VTK FAQ at:
>>> >>> http://www.vtk.org/Wiki/VTK_FAQ
>>> >>>
>>> >>> Follow this link to subscribe/unsubscribe:
>>> >>> http://www.vtk.org/mailman/listinfo/vtkusers
>>> >>>
>>> >>>
>>> >> _______________________________________________
>>> >> Powered by www.kitware.com
>>> >>
>>> >> Visit other Kitware open-source projects at
>>> >> http://www.kitware.com/opensource/opensource.html
>>> >>
>>> >> Please keep messages on-topic and check the VTK FAQ at:
>>> >> http://www.vtk.org/Wiki/VTK_FAQ
>>> >>
>>> >> Follow this link to subscribe/unsubscribe:
>>> >> http://www.vtk.org/mailman/listinfo/vtkusers
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > | Aashish Chaudhary
>>> > | R&D Engineer
>>> > | Kitware Inc.
>>> > | www.kitware.com
>>> > _______________________________________________
>>> > Powered by www.kitware.com
>>> >
>>> > Visit other Kitware open-source projects at
>>> > http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Please keep messages on-topic and check the VTK FAQ at:
>>> > http://www.vtk.org/Wiki/VTK_FAQ
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > http://www.vtk.org/mailman/listinfo/vtkusers
>>> >
>>>
>>>
>>> --
>>> Lic. José M. Rodriguez Bacallao
>>> Centro de Biofisica Medica
>>> -----------------------------------------------------------------
>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>> mismo.
>>>
>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>> por profesionales
>>> -----------------------------------------------------------------
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20110627/691f071a/attachment.htm>