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

Andinet Enquobahrie andinet.enqu at kitware.com
Wed Jan 23 19:31:02 EST 2008


Hi Frank,


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.
>

As discussed in

http://public.kitware.com/IGSTKWIKI/index.php/Talk:ImageSliceRepresentation#About_Questions

We will need a separate View class that derives from igstk:View and the
parameters of the camera in the view class will be synchronized with the
pose (position and orientation) information coming from a tracked object.

This class is not yet implemented. This task is also tangentially related
with the other items
in the Todo list
- ImageSliceRepresentation and
- Event dispatcher and synchronization


-Andinet






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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20080123/e613a2b2/attachment-0001.html>


More information about the IGSTK-Developers mailing list