[IGSTK-Developers] Re: IGSTK-Developers Digest, Vol 16, Issue 11

Patrick Cheng cheng at isis.georgetown.edu
Wed Mar 8 15:59:01 EST 2006


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



More information about the IGSTK-Developers mailing list