[IGSTK-Developers] Synchronization, (data/viz) management and the new (Oblque) ImageSliceRep

[Frank Lindseth]

Dear all,

As previously stated we need a good solution to synchronization,  
(data/viz) management and slicing (presented in 2D and 3D views) in  
order to be able to introduce the first application based on IGSTK  
into the OR.
We have been looking into vtkInria3D, vtkImagePlaneWidget/ 
vtkImageOrthoPlanes ++ as suggested by the team.
The vtkInria3D library offers many of the solutions that we seek for  
"overall coordination" within an application.
We strongly feel that similar functionality should be part of IGSTK:  
this is functionality that is needed in almost all real IGS apps. and  
should therefore be done the right way once an for all instead of  
forcing each app. developer to reinvent the wheel every time (there  
are both "ease of use" and safety aspects to this).
I know that there are a lot of other IGSTK things going on right now,  
but we (i.e. Torleif) will have to start working on this now and it  
would be nice to have the teams view on the best approach:
1) vtkImagePlaneWidget / vtkImageOrthoPlanes (3D view) +  
ImageSliceRep.(2D view) based on grabbing the pixels from the  
different vtkImagePlaneWidget +
and Observer sync. (see mail from Luis below).

2) vtkInria3D:  Borrow, adapt or integrate...

3) Something else (Patrics'  new ObliqueImageSliceRep? ++)

Maybe we could use a little bit of the next Tcon time on this.
In that case it would be nice if people looked at the vtkINRIA3D  
paper beforehand,
focusing more on the functonality it offers than the way it's  
implemented (at this stage):
http://insight-journal.org/dspace/handle/1926/559
http://www-sop.inria.fr/asclepios/software/vtkINRIA3D/

Thanks.

- Frank


On Aug 17, 2007, at 6:16 PM, Luis Ibanez wrote:

>
> Hi Torleif,
>
> Thanks for taking a look at the VTK image widgets.
>
> 1) I agree with you that the Axial, Coronal, Sagittal
>    views should not rotate. This shouldn't be a problem
>    since, presumably, you will use View2D classes for
>    those windows, and therefore the mouse interactions
>    for rotation will already be disabled.
>
> 2) Currently the vtkImagePlaneWidget always disable the
>    cross hair when the left mouse button is released.
>    We could derive from this class, overload the method
>    StopCursor() and modify it to not call ActivateCursor(0)
>    and ActivateText(0).  That should keep the latest
>    position of the cross hair in the widget.
>
> 3) Regarding the synchronization. We will still need an
>    extra class for it. Something along the lines of an
>    Observer that listens to the N instances of the planes,
>    and dispatch messages to all of them would probably
>    do the trick.
>
> 4) I'm wondering if this should simply be added as
>    a functionality to the current ImageSpatialObject
>    Representation class...
>
>
>    Luis
>
>
>
> -------------------------
> Torleif Sandnes wrote:
>> On Jul 12, 2007, at 4:46 AM, Luis Ibanez wrote:
>>>
>>> As we discussed during the tcon,
>>> it may be useful to look at the following VTK classes:
>>>
>>>          vtkImagePlaneWidget
>>>          vtkImageOrthoPlanes
>>>
>>>  http://www.vtk.org/doc/nightly/html/classvtkImagePlaneWidget.html
>>>  http://www.vtk.org/doc/nightly/html/classvtkImageOrthoPlanes.html
>>>
>>>
>>> in order to gather feedback for the Cross Hairs class.
>> Thanks for the pointers.
>> I have experimented with vtkImagePlaneWidget and it looks good  
>> except  for a few things:
>> 1. I don't want the user to be able to rotate the plane. the acs  
>> view  should be entirely 2D
>> 2. I want the crosshair indicating position to be present at all  
>> times.
>> The drawback with vtkImageOrthoPlanes is that it isn't able to   
>> synchronize a 3D view in addition to three 2D views.
>> I had a look at vtkInria3D as Ziv suggested and the  
>> synchronizedviews  example. This is exactly what I wanted in my  
>> application. I think  something like the vtkImageView/2D/3D should  
>> be a part of igstk.  While I agree with you that synchronization  
>> should occur between  representations and not views, I strongly  
>> believe that functionality  like this in some form is something  
>> that will be needed over and over  again in IGS applications.
>> I guess you get the general idea from the attached screenshot: an   
>> axis indicates position and position is updated in all four  
>> views.  position, window level/width slize and zoom can be  
>> synchronized.
>> What do you think?
>> --------------------------------------------------------------------- 
>> ---
>> Regards,
>> Torleif
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers



------------------------------
Frank Lindseth
Research Scientist (PhD)

SINTEF Health Research
Dept. Medical Technology
N-7465 Trondheim, Norway
Location: Olav Kyrres gt. 9, 4th floor, Trondheim

E-mail: Frank.Lindseth at sintef.no
Telephone: +47 928 09 372
Telefax: +47 930 70 800


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20070820/ecb48a91/attachment.html>