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