<P>
Where can I look for datasets for Guidewire and Needle Biopsy. <BR>
<BR>
<BR>
On Wed, 08 Mar 2006 igstk-developers-request@public.kitware.com wrote :<BR>
>Send IGSTK-Developers mailing list submissions to<BR>
> igstk-developers@public.kitware.com<BR>
><BR>
>To subscribe or unsubscribe via the World Wide Web, visit<BR>
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers<BR>
>or, via email, send a message with subject or body 'help' to<BR>
> igstk-developers-request@public.kitware.com<BR>
><BR>
>You can reach the person managing the list at<BR>
> igstk-developers-owner@public.kitware.com<BR>
><BR>
>When replying, please edit your Subject line so it is more specific<BR>
>than "Re: Contents of IGSTK-Developers digest..."<BR>
><BR>
><BR>
>Today's Topics:<BR>
><BR>
> 1. Re: Conclusion on igstkTransform issues - David&Patrick<BR>
> (David Gobbi)<BR>
> 2. Accessing StateMachine from derived classes (Julien Jomier)<BR>
> 3. Image-to-Image registration (Julien Jomier)<BR>
><BR>
><BR>
>----------------------------------------------------------------------<BR>
><BR>
>Message: 1<BR>
>Date: Tue, 07 Mar 2006 16:44:00 -0500<BR>
> From: David Gobbi <dgobbi@atamai.com><BR>
>Subject: Re: [IGSTK-Developers] Conclusion on igstkTransform issues -<BR>
> David&Patrick<BR>
>To: Luis Ibanez <luis.ibanez@kitware.com><BR>
>Cc: IGSTK Developers <igstk-developers@public.kitware.com><BR>
>Message-ID: <440DFEA0.9050202@atamai.com><BR>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>
><BR>
>Hi Luis,<BR>
><BR>
>I missed your point about defining special types for elapsed<BR>
>vs. abolute times. If we do that, then I agree that we can redefine<BR>
>mathematic operations to make sure that special "Forever" value<BR>
>can be treated properly.<BR>
><BR>
>It will be necessary to make sure that there is never silent<BR>
>conversion between these types and "double". I recommend using<BR>
>"Time" and "TimeDuration" as the names of these types.<BR>
><BR>
> - David<BR>
><BR>
><BR>
>Luis Ibanez wrote:<BR>
> ><BR>
> > Hi David,<BR>
> ><BR>
> > Adding boolean Flags inside classes is poor way of<BR>
> > implementing the logic that should be managed by a<BR>
> > State Machine.<BR>
> ><BR>
> > The flags will plague the code with "if" statements,<BR>
> > and will generate spaghetti logic that cannot be fully<BR>
> > tested nor formally verified.<BR>
> ><BR>
> > Conceptually, any new extra boolean flag in a class that<BR>
> > already has a State Machine is equivalent to duplicating<BR>
> > the number of States in that class, since now the developer<BR>
> > has to consider the effect of the flag on every transition.<BR>
> > Although it is likely that the flag will affect only a small<BR>
> > subset of all the States, it still will be up to the developer<BR>
> > to make sure that she/he will hack the appropriate places in<BR>
> > the code. The process of maintaining such style of code over<BR>
> > many years is very error-prone.<BR>
> ><BR>
> ><BR>
> > I agree with you that the use of special values is not the<BR>
> > correct way of managing error conditions, nor special cases.<BR>
> > My point, that I probably exposed poorly in my previous email,<BR>
> > is that by replacing the plain "doubles" with a custom made C++<BR>
> > class for representing the concept of Time and TimeLapses is the<BR>
> > best way of enforcing that the values will be used consistently<BR>
> > and that the application developers will not have the option of<BR>
> > performing risky operations.<BR>
> ><BR>
> ><BR>
> > A custom made Time class may have its own algorithmic rules,<BR>
> > such as making sure that:<BR>
> ><BR>
> > Forever + 1000 = Forever<BR>
> ><BR>
> > The point is that the Time class will remove from the API<BR>
> > the notion that a number is used for representing time.<BR>
> > When I mention the concept of "Forever", more than a value<BR>
> > in the Time class, it is a "State" of the time class. The users<BR>
> > of the Time class will not have to perform checks ("if"s) on<BR>
> > its state, instead we will implement inside the Time and TimeLapse<BR>
> > classes all the algebraic operations that we need for the time.<BR>
> ><BR>
> ><BR>
> > If that state is managed by the Time class itself, we can make sure<BR>
> > that Time operations are done consistently all over the toolkit,<BR>
> > instead of relying on developers to use the rules correctly on<BR>
> > every new class.<BR>
> ><BR>
> ><BR>
> ><BR>
> > Luis<BR>
> ><BR>
> ><BR>
> ><BR>
> ><BR>
> > ------------------<BR>
> > David Gobbi wrote:<BR>
> >> Hi Luis, Patrick,<BR>
> >><BR>
> >> In general I don't like "special values" and would prefer if there<BR>
> >> was a<BR>
> >> separate flag in igstkTransform to identify static vs. dynamic.<BR>
> >><BR>
> >> This would mean adding methods like SetStaticTranslationAndRotation(),<BR>
> >> and the "static" flag would be set when these methods are called. The<BR>
> >> SetStaticFlag() method for setting the flag would be private, and<BR>
> >> there would<BR>
> >> be a public GetStaticFlag() method for getting the flag. How does<BR>
> >> this sound?<BR>
> >><BR>
> >> On problem of defining a special value like "Forever" is that simple<BR>
> >> math on<BR>
> >> very large floating point values can cause bad things to happen. For<BR>
> >> example,<BR>
> >> if "Forever" is used as a duration, then "Forever" plus the start<BR>
> >> time might<BR>
> >> cause an overflow, or it might be equal to "Forever" due to limited<BR>
> >> numerical<BR>
> >> precision, which is counter-intuitive.<BR>
> >><BR>
> >> So what I'm saying is that if we use a special value, we would need<BR>
> >> to check<BR>
> >> for that special value whenever we do any math that involves the<BR>
> >> time. But<BR>
> >> if we're checking for a special value, we might as well just have a flag<BR>
> >> instead.<BR>
> >><BR>
> >> - David<BR>
> >><BR>
> >><BR>
> >> Luis Ibanez wrote:<BR>
> >><BR>
> >>><BR>
> >>><BR>
> >>> Hi Patrick,<BR>
> >>><BR>
> >>><BR>
> >>> You are right about the potential misuse of the long times.<BR>
> >>><BR>
> >>><BR>
> >>> We can remomve that risk when we add a specific type for<BR>
> >>> representing Time and TimeLapses, since that type could<BR>
> >>> define a constant that is considered to be an infinite time.<BR>
> >>><BR>
> >>><BR>
> >>> In practice we can take the NumericTraits::max() of the<BR>
> >>> type that we choose for internal representation of the time.<BR>
> >>> We could call that static value something like:<BR>
> >>><BR>
> >>><BR>
> >>> Time::Forever()<BR>
> >>><BR>
> >>><BR>
> >>> In this way, the intent of the value will be clearer<BR>
> >>> to the readers of the code.<BR>
> >>><BR>
> >>><BR>
> >>><BR>
> >>> Luis<BR>
> >>><BR>
> >>><BR>
> >>> -----------------------<BR>
> >>> Patrick Cheng wrote:<BR>
> >>><BR>
> >>>> Hi Luis,<BR>
> >>>><BR>
> >>>> I agree on statement 2) and 3).<BR>
> >>>><BR>
> >>>> But for 1), to be 'safe by design', we should not make any<BR>
> >>>> presumption that an operation does no go over a "long period of time".<BR>
> >>>><BR>
> >>>> This "long duration" is easily being misused, and at least, it's<BR>
> >>>> not consistent through out our code. some examples:<BR>
> >>>><BR>
> >>>> **********************************************************************<BR>
> >>>> [[[Super Long Period]]]<BR>
> >>>> igstkTrackerTool.cxx<BR>
> >>>> Line 31<BR>
> >>>> m_ToolCalibrationTransform.SetToIdentity( 1e300 );<BR>
> >>>><BR>
> >>>> igstkMeshReader.cxx<BR>
> >>>> line91-92:<BR>
> >>>> // Provide an identity transform with a long validity time.<BR>
> >>>> const double validityTimeInMilliseconds = 1e30;<BR>
> >>>><BR>
> >>>> [[[Wrong]]]<BR>
> >>>> igstkPivotCalibration.cxx<BR>
> >>>> Line 149<BR>
> >>>> this->m_CalibrationTransform.SetTranslationAndRotation(<BR>
> >>>> translation, quaternion, 0.1, 1000);<BR>
> >>>> Line 286<BR>
> >>>> this->m_CalibrationTransform.SetTranslation(translation, 0.1, 1000);<BR>
> >>>><BR>
> >>>> igstkPrincipalAxisCalibration.cxx<BR>
> >>>> Line 204<BR>
> >>>> this->m_CalibrationTransform.SetRotation( quaternion, 0.1, 1000);<BR>
> >>>> ************************************************************************<BR>
> >>>><BR>
> >>>><BR>
> >>>> Luis Ibanez wrote:<BR>
> >>>><BR>
> >>>>><BR>
> >>>>> Hi Patrick,<BR>
> >>>>><BR>
> >>>>><BR>
> >>>>> 1) The double use of Static and Dynamic transform will require<BR>
> >>>>> SpatialObject to have both of them as member variables.<BR>
> >>>>> Since SpatialObjects should be able to be "static" or "tracked".<BR>
> >>>>><BR>
> >>>>> What is the difficulty with having the "static" transforms be<BR>
> >>>>> represented with a time stamp of long duration ?<BR>
> >>>>><BR>
> >>>>><BR>
> >>>>> 2) When composing transforms, the time stamp of the final transform<BR>
> >>>>> must by the intersection among all the time stamps of the<BR>
> >>>>> transforms<BR>
> >>>>> involved on the composition.<BR>
> >>>>><BR>
> >>>>> We could add to the TimeStamp class, as service method that will<BR>
> >>>>> compote the intersection between two TimeStamps. This operation<BR>
> >>>>> is associative, so by applying it by pairs we can compose any<BR>
> >>>>> number of TimeStamps.<BR>
> >>>>><BR>
> >>>>><BR>
> >>>>> 3) It is better to have a explicit "Compose" method, than having<BR>
> >>>>> an operator overload. The Compose method name could also make<BR>
> >>>>> clearer whether we are pre-composing or post-composing the<BR>
> >>>>> transform.<BR>
> >>>>><BR>
> >>>>><BR>
> >>>>><BR>
> >>>>><BR>
> >>>>> Luis<BR>
> >>>>><BR>
> >>>>><BR>
> >>>>><BR>
> >>>>> ---------------------<BR>
> >>>>> Patrick Cheng wrote:<BR>
> >>>>><BR>
> >>>>>> Hi everybody,<BR>
> >>>>>><BR>
> >>>>>> This is the conclusion of the discussion between david and me.<BR>
> >>>>>> Welcome to comment on it.<BR>
> >>>>>><BR>
> >>>>>> =======================================================================<BR>
> >>>>>><BR>
> >>>>>><BR>
> >>>>>> Problem 1. We need both static and dynamic transform.<BR>
> >>>>>> (Registration and calibration transforms should be static, and<BR>
> >>>>>> tracker transforms should be dynamic)<BR>
> >>>>>><BR>
> >>>>>> Solution: Make subclasses of igstk::Transform,<BR>
> >>>>>> igstk::DynamicTransform and igstk::StaticTransform<BR>
> >>>>>> StaticTransform which do not have time stamp. In base class we<BR>
> >>>>>> provide pure virtual fuction:<BR>
> >>>>>> bool IsStatic()/IsDynamic();<BR>
> >>>>>><BR>
> >>>>>> Q? Do we some times have to switch the transform of a object<BR>
> >>>>>> from dynamic to static or the other way around?<BR>
> >>>>>><BR>
> >>>>>> =======================================================================<BR>
> >>>>>><BR>
> >>>>>><BR>
> >>>>>> Problem 2. We currently don't have a simple transform compose<BR>
> >>>>>> method, and we are not taking care of time stamps in the current<BR>
> >>>>>> implementation of the transform multiplication.<BR>
> >>>>>><BR>
> >>>>>> e.g.<BR>
> >>>>>> Ta is static transform, Tb is dynamic, and Tc is dynamic.<BR>
> >>>>>> When we do T = Ta * Tb * Tc<BR>
> >>>>>> to get the final valid time stamp for T, we should first ignore<BR>
> >>>>>> Ta, and pick up the earlier expiration time from Tb and Tc, and<BR>
> >>>>>> minus current time, to get the valid time period for the T, and<BR>
> >>>>>> set a right time stamp for it.<BR>
> >>>>>><BR>
> >>>>>> Solution: Add a simple function or operator such as:<BR>
> >>>>>> transform = transform1.compose( transform2 )<BR>
> >>>>>> equals to:<BR>
> >>>>>> transform = transform1 * transform2<BR>
> >>>>>><BR>
> >>>>>> This will avoid the wrong matrix composition, and make code<BR>
> >>>>>> simpler and cleaner.<BR>
> >>>>>> Also this compose() method will calculate the correct time stamp<BR>
> >>>>>> automatically according to predefine rules.<BR>
> >>>>>><BR>
> >>>>>> =======================================================================<BR>
> >>>>>><BR>
> >>>>>><BR>
> >>>>>> David, I hope you still agree on these points.<BR>
> >>>>>><BR>
> >>>>>><BR>
> >>>>><BR>
> >>>>><BR>
> >>>>><BR>
> >>>><BR>
> >>>><BR>
> >>><BR>
> >>> _______________________________________________<BR>
> >>> IGSTK-Developers mailing list<BR>
> >>> IGSTK-Developers@public.kitware.com<BR>
> >>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers<BR>
> >>><BR>
> >><BR>
> >><BR>
> >><BR>
> ><BR>
> ><BR>
><BR>
><BR>
><BR>
>------------------------------<BR>
><BR>
>Message: 2<BR>
>Date: Tue, 07 Mar 2006 20:30:53 -0500<BR>
> From: Julien Jomier <julien.jomier@kitware.com><BR>
>Subject: [IGSTK-Developers] Accessing StateMachine from derived<BR>
> classes<BR>
>To: Luis Ibanez <luis.ibanez@kitware.com><BR>
>Cc: 'IGSTK-developers' <igstk-developers@public.kitware.com><BR>
>Message-ID: <440E33CD.4030303@kitware.com><BR>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>
><BR>
>Hi Luis,<BR>
><BR>
>I know we talked about it a long time ago and I'm sorry I don't recall<BR>
>the answer but is there a way to access the superclass state machine<BR>
> from derived classes?<BR>
>It's not critical for what I'm implementing but I am just wondering if<BR>
>it is possible with the current implementation.<BR>
><BR>
>Thanks for the help,<BR>
><BR>
>Julien<BR>
><BR>
><BR>
><BR>
>------------------------------<BR>
><BR>
>Message: 3<BR>
>Date: Tue, 07 Mar 2006 20:33:29 -0500<BR>
> From: Julien Jomier <julien.jomier@kitware.com><BR>
>Subject: [IGSTK-Developers] Image-to-Image registration<BR>
>To: "'IGSTK-developers'" <igstk-developers@public.kitware.com><BR>
>Message-ID: <440E3469.7000903@kitware.com><BR>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>
><BR>
>Hello,<BR>
><BR>
>Is anybody working on the Image-to-Image Registration classes yet? or<BR>
>should I start the implementation from scratch?<BR>
><BR>
>Let me know,<BR>
>Thanks,<BR>
><BR>
>Julien<BR>
><BR>
><BR>
><BR>
>------------------------------<BR>
><BR>
>_______________________________________________<BR>
>IGSTK-Developers mailing list<BR>
>IGSTK-Developers@public.kitware.com<BR>
>http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers<BR>
><BR>
>End of IGSTK-Developers Digest, Vol 16, Issue 11<BR>
>************************************************<BR>
</P>
<br><br>
<a href="http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3"><IMG SRC="http://adworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff.com/signature-home.htm/1963059423@Middle5?OAS_query=null&PARTNER=3" BORDER=0 VSPACE=0 HSPACE=0></a>