[IGSTK-Developers] Solved registration problem mentioned in lastTCon by inverting regtransform

[Frank Lindseth]

Thanks a lot Matt, that definitely made it clearer.

In addition to my comments below it will be very interesting to see  
the performance in a rather complex case, involving a lot of volumes.
E.g. it is not unusual to have 4-6 MR volumes (MRTissue, MRA, fMRI,  
DTI) + 5-10 Ultrasound volumes in neurosurgery, I'm not sure about the  
best way to organize all these data (in terms of performance for  
example, or wether it matters). Some time ago the following examples  
were created:
http://public.kitware.com/IGSTKWIKI/index.php/SceneGraphExamples#A_more_complex_example
Should certain constructions be avoided?

You tend to put the image in the  center, as apposed to the reference  
frame/tool for example, it this just a preference or what?

So I guess that making the view a child of the tool will not make the  
camera follow the tool (a feature we have experienced to be very  
effective in some cases), what would be the best way to achieve this  
effect.

- Frank

On Jan 23, 2008, at 9:20 PM, Matt Turek wrote:

>
> Frank,
>
> Here's a multivolume example that might help answer your questions  
> regarding the coordinate systems.
>
> http://public.kitware.com/IGSTKWIKI/images/5/55/Multivolume_Coordinate_System_Example.pdf
>
> Please feel free to follow-up with more questions.
>
> Matt
>
>
> Frank Lindseth wrote:
>> Matt and Andinet,
>>
>> Thank you for the update.
>>
>> I agree that in the "not using a reference-tool" case the "scene- 
>> graph" should look as suggested by Matt below,
>> this is in line with the design document (page 3):
>> http://public.kitware.com/IGSTKWIKI/images/5/5a/IGSTK-CoordinateSystem-C.pdf
>> and I think that the figures on page 1 and 3 should be uploaded on  
>> an easy to find place (IGSTK wiki / www), together with some  
>> explaining text.
>> But I thought we started with this configuration Torleif?
>>
>> It's a good idea to make the Landmark3DRegistration method  
>> explicit, and it's probably a good idea to have both methods.
>> It's important that the user is led in the right direction (safety  
>> by design...) and that the different components fits together, so  
>> if the only sensible image-tracker/ref-tool relationship is child- 
>> parent, its only natural that the Landmark3DRegistration returns  
>> the TransformFromImageToTracker that could be passed directly to  
>> image->RequestSetTransformAndParent(TransformFromImageToTracker,  
>> tracker)
>> The scene-graph concept is very flexible (this is very good and it  
>> looks very promising), it might be wise to remove some if this  
>> flexibility (not needed) from the surface (lead the user in the  
>> right direction, make wrong use difficult) and it might be wise to  
>> introduce some convenient method to make the API more IGS (e.g.  
>> image->RequestSetImageToTrackerTransform(ImageToTrackerTransform,  
>> tracker ) =
>> image>RequestSetTransformAndParent(ImageToTrackerTransform, tracker )
>> and
>> CTimage->RequestSetImageToImageTransform(ImageToImageTransform,  
>> MRImage ) =
>> CTimage >RequestSetTransformAndParent(ImageToImageTransform,  
>> MRImage )
>> )
>> but it's probably wise to postponed such adaptions until the  
>> functionality have been tested/used for a while.
>>
>> A little question while we are talking about the scene-graph:
>> How should we think when specifying where the view(=camera in this  
>> regard?) points???
>> Think in terms of three different cases:
>> 1) One image
>> 2 Multiple images (info. from more then one image is presented in a  
>> given view)
>> 2a) The different images are not interconnected (situation right  
>> after the images have been read into the system)
>> 2b) The transforms between the images have been found (image2image  
>> reg.)
>> There are three candidates, the view could point to:
>> 1) One of the images
>> 2) The referance-tool or the tracker itself (if ref-tool is not used)
>> 3) One of the tracker tools (in order to let the camera be  
>> controlled by a tool for example)
>> What is preferred, what is the consequences, etc.?
>>
>> Regards,
>> Frank
>>
> -- 
> Matt Turek, Ph.D.
> R&D Engineer
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-371-3971 x142
> email: Matt.Turek at kitware.com
>



------------------------------
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/20080124/0ac3ff93/attachment.html>