[IGSTK-Developers] Solved registration problem mentioned in lastTCon by inverting regtransform
Frank Lindseth
Frank.Lindseth at sintef.no
Tue Jan 22 20:41:31 EST 2008
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
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
------------------------------
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/20080123/d5bcf17b/attachment-0001.html>
More information about the IGSTK-Developers
mailing list