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

cartik sharma cartik.sharma at gmail.com
Mon Jan 24 20:10:33 EST 2011


hi David/Bill,

This is an interesting thread and it seems like mapper design and classes
that
David is creating will be a boon to vtk pipeline and subsequent workflows.

The idea of measurement for an entity or object should be within a class or
structure
"observing" the object being measured.

So I'd agree with having orientation and position information in a
data-observer class
or metadata (as David suggests) for the mapper, which would store and
retrieve  position/orientation as required.

My 2 cents..
-Cartik


On Mon, Jan 24, 2011 at 5:07 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> 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
> >>
> >>
> >
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110124/a4546e8b/attachment.html>


More information about the vtk-developers mailing list