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