[vtk-developers] A new way to look at images

David Gobbi david.gobbi at gmail.com
Mon Jan 24 18:07:24 EST 2011 

Hi Bill,

I'll see what I can do.  Back in 2005, I wrote a VTK image viewer
app that dealt with oriented images in either of two user-selectable
coordinate systems (DICOM and MINC).  It was a pain in the backside.

There is a limit to what the mapper can do, because it has to respect
the actor's data-to-world transform matrix.  In general, the mapper
isn't allowed to play around with coordinate systems, because if it
does, then picking won't work (unless the picker is wise to whatever
extra coordinate transforms the mapper is applying, but that could get
ugly).

What I did with my own software was write plug-ins for all the readers
that would add orientation metadata to the FieldData of the image
data, but that metadata was always interpreted at the application
level.  For my new classes, I think the best thing would be to handle
orientation within the viewers and interactors.  But I'll think about
how the mappers could be designed to make this easier to accomplish.

 - David


On Mon, Jan 24, 2011 at 2:46 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> David,
>
> It would be great to have mapper that respected dicom's image
> orientation and the difference between vtk's graphics oriented image
> coordinate system and itk's image(medical)-oriented coordinate system.
> These are huge sources of confusion in the graphics versus imaging
> communities.
>
> Keep up the good work,
>
> Bill
>
>
> On Mon, Jan 24, 2011 at 4:38 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Will,
>>
>> I'll see if I can get everything onto the wiki this week.  I haven't
>> figured out all the names yet, the reslicing mapper is the only one
>> that I've written so far.
>>
>> One thing that I should add is that, when it is all done, I plan to
>> make vtkImageActor into a subclass of the new vtkImage class.
>> At that point, vtkImageActor will become a special vtkImage that
>> has a built-in mapper and a built-in SetInput() method (purely for
>> backwards compatibility).
>>
>> Replacing vtkImageActor has been on my agenda for years now.
>> It doesn't "fit" the VTK pipeline properly:
>> - it has no VTK5-style SetInputConnection method (and cannot,
>>  since it isn't a vtkAlgorithm)
>> - since it has no mapper or property, it can't work with vtkLODProp3D
>> - it requires "unsigned char" input: it would be nice if it could do
>>  the color mapping and window/level itself
>>
>> These are all things that my new design will address (and of course I
>> also needed a new mapper that could do reslicing).  The overall goal
>> is to improve the way that images are displayed and interacted with,
>> by putting image display on an equal footing with volume and geometry
>> display.
>>
>> Ah... I said that I'd put the info on the wiki, so I guess I don't need to
>> put everything in this email.  Thanks for your support thus far.
>>
>>  - David
>>
>>
>> On Mon, Jan 24, 2011 at 1:53 PM, Will Schroeder
>> <will.schroeder at kitware.com> wrote:
>>> Hi David-
>>> I see what you are saying and it makes sense, I am wondering what would
>>> be the names of the various image mappers  (since you indicate that there is
>>> more than one)?
>>> W
>>>
>>> On Sat, Jan 22, 2011 at 10:33 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>
>>>> Hi Will,
>>>>
>>>> I did think of ImageSliceActor and several other names, but the issue
>>>> is the "reslicing" is done by the mapper class, not by the actor
>>>> class.  So right now I have my vtkImage class paired with a mapper
>>>> that displays images by reslicing them.  By I also intend to write
>>>> another mapper for viewing 2D images.
>>>>
>>>> The idea here is that the three major Prop3D types will be vtkActor,
>>>> vtkVolume and vtkImage.
>>>>
>>>> The vtkImage class would be the definitive image-viewing class for
>>>> VTK.  It would have:
>>>> 1) a mapper that reslices the image and displays the slice
>>>> 2) a mapper that does what vtkImageActor does
>>>> 3) a mapper for doing slice display of vtkUnstructuredGrid data
>>>> 4) down the line, perhaps some GPU-specialized mappers
>>>>
>>>> What I'm trying to say here is that the reslicing behaviour that I
>>>> described in my previous email is all in the mapper.  The vtkImage
>>>> "actor" class, on the other hand, is meant to be very generic.  It is
>>>> just a Prop3D that image-related mappers can be attached to.
>>>>
>>>>  David
>>>>
>>>>
>>>> On Sat, Jan 22, 2011 at 7:32 AM, Will Schroeder
>>>> <will.schroeder at kitware.com> wrote:
>>>> > David this is very clever and seems pretty intuitive to use (I did not
>>>> > actually try it).
>>>> > I think my initial (minor) concern is naming, while I think what you've
>>>> > come
>>>> > up is pretty good I can see how a novice might get confused.  Did you
>>>> > consider something like "ImageResliceActor", "ResliceActor" or simply
>>>> > "Reslice"?
>>>> > W
>>>> >
>>>> >
>>>> > On Fri, Jan 21, 2011 at 6:53 PM, David Gobbi <david.gobbi at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi All,
>>>> >>
>>>> >> I've been experimenting with a new way of rendering 3D images in VTK.
>>>> >> So far, it is working fairly well.  Here is a rough description of the
>>>> >> new VTK classes I've written:
>>>> >>
>>>> >> vtkImage - a new prop for image viewing, analogous to vtkVolume and
>>>> >> vtkActor
>>>> >> vtkImageProperty - holds the lookup table, window/level, etc.
>>>> >> vtkImageMapper3D - a new mapper that does image reslicing and texturing
>>>> >>
>>>> >> Using these classes is very simple: just set up the camera, and the
>>>> >> vtkImage object will automatically display the slice at the camera
>>>> >> focal point.  To show a different slice, just move the focal point so
>>>> >> that it lies at a different position in the 3D image.  To slice in a
>>>> >> different orientation, rotate the camera around the focal point.  In
>>>> >> other words, the slicing is completely controlled by the camera.  This
>>>> >> makes everything work nicely with the VTK interactors, and also
>>>> >> simplifies the intermixing of images and geometry.
>>>> >>
>>>> >> My reason for making this class is that I've seen plenty of users on
>>>> >> the list who struggle with vtkImageReslice and with vtkImageViewer.  I
>>>> >> wanted to make it as easy to view an image in VTK as it is to view an
>>>> >> actor. I have the code on my github account
>>>> >> git://github.com/dgobbi/VTK.git in the branch "image-prop"
>>>> >> http://github.com/dgobbi/VTK/tree/image-prop
>>>> >>
>>>> >> The code includes a modified vtkInteractorStyleImage class that has
>>>> >> new interactions for rotating the camera with shift-leftbutton (for
>>>> >> oblique slicing) and for adjusting the focal point with
>>>> >> shift-middlebutton (for slicing through the image).  There is also a
>>>> >> python example in Examples/ImageProcessing/Python/ImageMapper3D.py.
>>>> >> All of this is still preliminary development, but so far I haven't
>>>> >> encountered any show-stopping bugs.
>>>> >>
>>>> >> Please let me know what you think.  I'll try to make a wiki page with
>>>> >> more details next week.
>>>> >>
>>>> >>  - David
>>>> >> _______________________________________________
>>>> >> Powered by www.kitware.com
>>>> >>
>>>> >> Visit other Kitware open-source projects at
>>>> >> http://www.kitware.com/opensource/opensource.html
>>>> >>
>>>> >> Follow this link to subscribe/unsubscribe:
>>>> >> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > William J. Schroeder, PhD
>>>> > Kitware, Inc.
>>>> > 28 Corporate Drive
>>>> > Clifton Park, NY 12065
>>>> > will.schroeder at kitware.com
>>>> > http://www.kitware.com
>>>> > (518) 881-4902
>>>> >
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>

More information about the vtk-developers mailing list