[IGSTK-Developers] View refactoring- Camera control

Andinet Enquobahrie andinet.enqu at kitware.com
Thu Jul 12 08:36:42 EDT 2007


>
> Hi Frank,
>
> A synchronization between multiple orthogonal slices should probably
> be implemented between multiple image representation classes, instead
> of the View class itself.
>
> The View class is just the abstraction of the RenderWindow, where
> many objects beside images may be displayed.


I totally second Luis on this. Let us not forget that the function of 
the view class is
aggregation of graphical representations of spatial objects into one 
coherent
scene.

Synchronization between interactions and visualization does not fit with 
the functionality
of the view class. And at this point there is no dedicated component to 
handle this synchronization
in IGSTK. The assumption is that the application developer handles the 
synchronization at the
application level. For example, that is what Patrick did in the 
NeedleBiopsy application,
when a user picks/draws a point in one view, the other views (orthogonal 
orientation) get resliced
automatically to reflect this selection. 

So, I think the MAIN question is

"Is this a component-level function or application level function?"

1) Do we need a dedicated/separate/standalone component (class) to 
handle synchronization functionalities?
In other words, do we need something like vtkINRI3D ( Insight Journal 
contribution that Ziv pointed out) ?

OR

2) Do we leave it for the application developer to handle the 
synchronization?


-Andinet









>
>
>    Luis
>
>
> -------------------------
> Frank Lindseth wrote:
>
>> Hi Andinet,
>>
>> This looks very good.
>> Ideally the re-factoring of the ImageSliceRep. should be done first 
>> in order to see the needed functionality to display oblique slices in 
>> an optimal way for example, but I guess most things can be done using 
>> these methods.
>> Just a little note, in our present system the surgeon can "set" the 
>> view in the 3D scene using a tool/pointer: The view follows the tool 
>> (or guide wire)  in real time, and when a good view is found the view 
>> can be "freezed" or saved. In order to do this (just by using the 
>> axes of the tool) it would be nice to have a RequestSetViewDirection 
>> too.
>>
>> And while talking about the view class re-factoring:
>> I'm hoping that a good synchronization scheme can be build into the 
>> view-class (for croshair positioning for example) :
>> - Synchronization between the three different views (e.g. axial, 
>> coronal and sagital) for a single volume.
>> - Synchronization between corresponding views from different volumes.
>> - Synchronization between the "2D and 3D display" of the same slice.
>> - etc.
>>
>> Regards,
>> Frank
>>
>> On Jul 5, 2007, at 9:02 PM, Andinet Enquobahrie wrote:
>>
>>> Team,
>>>
>>> One of the main weaknesses of the view classes is lack of camera 
>>> control as
>>> pointed out by several people. As part of the view class refactoring 
>>> effort,
>>> I will be adding Request methods that provide control of  some of 
>>> the camera
>>> parameters to the user.
>>>
>>> I am proposing to add the following methods
>>>
>>> // Set camera position
>>> RequestSetPosition(double x., double y, double z);
>>>
>>> //Set focal point coordinates
>>> RequestSetFocalPoint( double x, double y, double z);
>>>
>>> //Set view vector up
>>> RequestSetViewUp( double vx, double vy, double vz);
>>>
>>> //Set clipping range
>>> RequestSetClippingRange( double dNear, double dFar);
>>>
>>> //Set parallel projection on
>>> RequestSetParallelProjectionOn( );
>>>
>>> //Set perspective projection on
>>> RequestSetPerspectiveProjectionOn()
>>>
>>> Let me know if you see the need to have control of
>>> other parameters of the camera.
>>>
>>> Thanks
>>>
>>> -Andinet
>>>
>>> -- 
>>> ==========================================================
>>> Andinet A. Enquobahrie, PhD
>>> R&D Engineer
>>> Kitware Inc.
>>>
>>> 28 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-371-3971 x124
>>> www.kitware.com
>>>
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com 
>>> <mailto: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 <mailto:thomas.lango at sintef.no>
>> Telephone: +47 928 09 372
>> Telefax: +47 930 70 800
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>


-- 
==========================================================
Andinet A. Enquobahrie, PhD
R&D Engineer
Kitware Inc.

28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x124
www.kitware.com





More information about the IGSTK-Developers mailing list