<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 23, 2008, at 2:41 AM, Frank Lindseth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Matt and Andinet,</div><div><br class="webkit-block-placeholder"></div><div>Thank you for the update.</div><div><br class="webkit-block-placeholder"></div><div>I agree that in the "not using a reference-tool" case the "scene-graph" should look as suggested by Matt below,</div><div>this is in line with the design document (page 3):</div><a href="http://public.kitware.com/IGSTKWIKI/images/5/5a/IGSTK-CoordinateSystem-C.pdf">http://public.kitware.com/IGSTKWIKI/images/5/5a/IGSTK-CoordinateSystem-C.pdf</a><div>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.</div></div></blockquote><div>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?</div><div><br class="webkit-block-placeholder"></div><div>- Frank</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>But I thought we started with this configuration Torleif?</div><div><br class="webkit-block-placeholder"></div><div>It's a good idea to make the Landmark3DRegistration method explicit, and it's probably a good idea to have both methods.</div><div>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)</div><div>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 </div><div>(e.g. </div><div>image->RequestSetImageToTrackerTransform(ImageToTrackerTransform, tracker ) =</div><div>image>RequestSetTransformAndParent(ImageToTrackerTransform, tracker )</div><div>and</div><div><div>CTimage->RequestSetImageToImageTransform(ImageToImageTransform, MRImage ) =</div><div>CTimage >RequestSetTransformAndParent(ImageToImageTransform, MRImage )</div><div>)</div><div>but it's probably wise to postponed such adaptions until the functionality have been tested/used for a while.</div><div><br class="webkit-block-placeholder"></div><div>A little question while we are talking about the scene-graph:</div><div>How should we think when specifying where the view(=camera in this regard?) points???</div><div>Think in terms of three different cases:</div><div>1) One image</div><div>2 Multiple images (info. from more then one image is presented in a given view)</div><div>2a) The different images are not interconnected (situation right after the images have been read into the system)</div><div>2b) The transforms between the images have been found (image2image reg.)</div><div>There are three candidates, the view could point to:</div><div>1) One of the images</div><div>2) The referance-tool or the tracker itself (if ref-tool is not used)</div><div>3) One of the tracker tools (in order to let the camera be controlled by a tool for example)</div><div>What is preferred, what is the consequences, etc.?</div><div><br class="webkit-block-placeholder"></div><div>Regards,</div><div>Frank</div><div><br></div></div><div><br><div><div>On Jan 22, 2008, at 11:34 PM, Matt Turek wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>Torleif,<br><br>I'm glad you found a way to make your registration problem work.<br><br>I have a suggestion, though, that might be a little "cleaner". I'd set up the coordinate systems like this:<br><br> image<br> ^<br> |<br> -----------------------<br>Identity --> | | <----- Landmark Registration Transform.<br> view tracker<br> ^<br> | <----- Identity<br> |<br> tracker tool<br><br>Here are a few reasons for my suggestion:<br> 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.<br> 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.<br><br>Matt<br><br><br>Torleif Sandnes wrote:<br><blockquote type="cite">Hello.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I have found a solution to the problem I had with landmarkregistration:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I set up the scenegraph with the image, tracker, trackertool and view like this:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">image->RequestSetTransformAndParent(identity, tracker.GetPointer())<br></blockquote><blockquote type="cite">...<br></blockquote><blockquote type="cite">trackerTool->RequestSetTransformAndParent(identity, image);<br></blockquote><blockquote type="cite">pointerSpatialObject->RequestSetTransformAndParent(transform, trackerTool.GetPointer());<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">view->RequestSetTransformAndParent(identity, image);<br></blockquote><blockquote type="cite">...<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> tracker<br></blockquote><blockquote type="cite"> /<br></blockquote><blockquote type="cite"> / <--- Landmark Registration Transform goes here<br></blockquote><blockquote type="cite"> /<br></blockquote><blockquote type="cite"> image<br></blockquote><blockquote type="cite"> / \<br></blockquote><blockquote type="cite"> / \<br></blockquote><blockquote type="cite"> / \<br></blockquote><blockquote type="cite"> trackertool view<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">After registration:<br></blockquote><blockquote type="cite">image->RequestSetTransformAndParent(registrationTransform, tracker);<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This resulted in a registration that moved the pointer rep further away from the volumerendering, so<br></blockquote><blockquote type="cite">I tried to inverse the registration transform I got from igstk::Landmark3DRegistrationTransform:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">image->RequestSetTransformAndParent(registrationTransform.GetInverse(), tracker);<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This resulted in a registration that works.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards,<br></blockquote><blockquote type="cite">Torleif_______________________________________________<br></blockquote><blockquote type="cite">IGSTK-Developers mailing list<br></blockquote><blockquote type="cite"><a href="mailto:IGSTK-Developers@public.kitware.com">IGSTK-Developers@public.kitware.com</a><br></blockquote><blockquote type="cite"><a href="http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers">http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers</a><br></blockquote><br><br>-- <br>Matt Turek, Ph.D.<br>R&D Engineer<br>Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: 518-371-3971 x142<br>email: <a href="mailto:Matt.Turek@kitware.com">Matt.Turek@kitware.com</a><br><br>_______________________________________________<br>IGSTK-Developers mailing list<br><a href="mailto:IGSTK-Developers@public.kitware.com">IGSTK-Developers@public.kitware.com</a><br>http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers<br></blockquote></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><br class="Apple-interchange-newline"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" color="#696969" face="Helvetica Neue" size="3"><span class="Apple-style-span" style="font-size: 11px;; color: rgb(105, 105, 105); font-family: Helvetica Neue; "><br class="khtml-block-placeholder"></span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div></span></span></span></span></div></span> </div><br></div></div>_______________________________________________<br>IGSTK-Developers mailing list<br><a href="mailto:IGSTK-Developers@public.kitware.com">IGSTK-Developers@public.kitware.com</a><br>http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers</blockquote></div><br></body></html>