[IGSTK-Developers] Solved registration problem mentioned inlastTCon by inverting regtransform
Frank Lindseth
Frank.Lindseth at sintef.no
Wed Jan 23 06:20:02 EST 2008
On Jan 23, 2008, at 2:41 AM, 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.
I realize now that there is a small difference between Matt's figure
(below) and the design document figure above, the direction of the
arrow between image and tracker, in my head the figure in the design
document is the preferred way, at least if multiple images are
involved, but are there any differences in terms of consequences for
the different options?
- Frank
> 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
>
>
> On Jan 22, 2008, at 11:34 PM, Matt Turek wrote:
>
>>
>> Torleif,
>>
>> I'm glad you found a way to make your registration problem work.
>>
>> I have a suggestion, though, that might be a little "cleaner". I'd
>> set up the coordinate systems like this:
>>
>> image
>> ^
>> |
>> -----------------------
>> Identity --> | | <-----
>> Landmark Registration Transform.
>> view tracker
>> ^
>> |
>> <----- Identity
>> |
>> tracker tool
>>
>> Here are a few reasons for my suggestion:
>> 1. The Landmark3DRegistration computes the transform from the
>> tracker to the image. This is why you needed to use the inverse
>> before. Andinet updated Landmark3DRegistration to make the get
>> transform method names more explicit. Hopefully the direction of
>> the transform will now be clear.
>> 2. In our current implementation, the tracker tool's transform is
>> being managed by the tracker. The tracker tool is attached to the
>> tracker's coordinate system during trackerTool-
>> >RequestAttachToTracker(). This behavior is slightly different if
>> there is a reference tool. In the case of a specified reference
>> tool, the reference tool is the parent of the other tracker tools.
>> A tracker tool should only be a child of the tracker or another
>> tracker tool.
>>
>> Matt
>>
>>
>> Torleif Sandnes wrote:
>>> Hello.
>>>
>>> I have found a solution to the problem I had with
>>> landmarkregistration:
>>>
>>> I set up the scenegraph with the image, tracker, trackertool and
>>> view like this:
>>>
>>> image->RequestSetTransformAndParent(identity, tracker.GetPointer())
>>> ...
>>> trackerTool->RequestSetTransformAndParent(identity, image);
>>> pointerSpatialObject->RequestSetTransformAndParent(transform,
>>> trackerTool.GetPointer());
>>>
>>> view->RequestSetTransformAndParent(identity, image);
>>> ...
>>>
>>> tracker
>>> /
>>> / <--- Landmark Registration Transform goes here
>>> /
>>> image
>>> / \
>>> / \
>>> / \
>>> trackertool view
>>>
>>> After registration:
>>> image->RequestSetTransformAndParent(registrationTransform, tracker);
>>>
>>> This resulted in a registration that moved the pointer rep further
>>> away from the volumerendering, so
>>> I tried to inverse the registration transform I got from
>>> igstk::Landmark3DRegistrationTransform:
>>>
>>> image-
>>> >RequestSetTransformAndParent(registrationTransform.GetInverse(),
>>> tracker);
>>>
>>> This resulted in a registration that works.
>>>
>>> Regards,
>>> Torleif_______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>
>>
>> --
>> 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
>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>
>
>
>
> _______________________________________________
> 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/fb32bf62/attachment-0002.html>
More information about the IGSTK-Developers
mailing list