[Insight-users] Not so Silly questions about registration

[David Holmes]

Luis, Josh, Lydia, Dan, and others:

First, let me apologize for going off the deep end in
my last note.  I went a little overboard in my
comments.  I think it was due to a Moutain Dew caffine
overload.

Anyway, I very much agree with everyone that parameter
tweeking is a necessary evil when working with medical
image processing.  There is clearly not one solution
for all problems.  My point was simply that both API
programmers and Application programmers must make
their code as robust as possible.  So far, the ITK
group has accomplished this through very nice generic
programming which allows for any number algorithms to
be fashioned for any number of problems. As
application programmers, the trick is to structure the
application to achieve the best results and provide as
straigtforward interface as possible.  Regardless of
the level of programming, however, I'd like to avoid
situations in which a filter only works if the data is
collected by a given scanner, or in a given format, or
for a given anatomical orientation, etc, etc.  I
realize that all of these factors may result in
different solutions, but still expecting the algorithm
to work towards a useful solution.  This is what I
mean by robust.

Thanks

david



--- David Holmes <holmesd3@yahoo.com> wrote:
> Luis-
> 
> I appreciate your feedback.  In response to your
> first
> note, I happen to agree more with Dan on this issue.
> 
> Just because your input datatype is unsigned char,
> there is no reason that everything processed within
> that object needs to be unsigned char.  Internal
> processing which requires floats should be carried
> out
> in floats.  For example, there is no reason that
> within the framework, the gradient info couldn't be
> calculated and stored as a float regardless of the
> input datatype.  I think that this is a case where I
> was possibly too pixeltype aware -  (i.e. the pixel
> data is unsigned char, not float).  Although not a
> naive user, I take the mindset of a good
> object-oriented program.  I pass my stuff to a
> object
> and wait for a response.  It is not necessarily my
> job
> to dig into someone elses class and determined the
> process step by step.  In fact, I should be able to
> answer all of my question about a class from the
> header and public/protected methods defined -- as
> well
> as the documentation.  In particular, I expect that
> the object (i.e. the registration object) should
> take
> my data as is and deal with it accordingly.  If it
> cannot handle my data, then that should be
> documented.
>  I was unable, at first glance, to see any
> documentation that stated a simple transform
> registration with the regularstepgradientoptimizer
> will only work with float data.  Instead, I would
> have
> expected the registration object to resolve that
> problem for me.  If this is not the case, then I
> would
> have to dig over every piece of code to determined
> every programming detail of the algorithm which
> means
> I would have to dig into the methods of the classes
> which don't fit well with my understanding of OO
> concepts such as encapsulation.  I realize that this
> is somewhat of an extreme viewpoint, and I will
> admit,
> I don't complete adhere to it, but I think that it
> makes the point.  In this particular case, I think
> that the issue is that I was unable to find the
> supporting documentation without diggging into a lot
> of code.
> 
> With regards to your second note, I think it is
> unreasonable to use your simple example.  Rarely is
> anyone going to divide two int and store it in an
> int.
>  That just doesn't make sense.  The correct response
> to dividing two int is to type one of them and store
> as a float.  Once again, this is something that
> could
> be done within a class rather than requiring
> everything be the same type from the beginning.  In
> the same manner, to make an image of type std:string
> doesn't make sense.  It is a matter of common sense.
> 
> There is nothing in "common sense" thinking that
> says
> that I shouldn't be able to pass two unsigned chars
> into a registration framework and work towards an
> achieveable goal (even if it is not identical), but
> as
> the results show that a reasonable solution cannot
> be
> found.  In contrast, there is no common sense to
> dividing two int and storing in an int if precision
> is
> an issue or creating an image of type std::string.
> 
> In general, I think that ITK is a very nice toolkit.
> 
> One of those features is the generic programming
> with
> templates, however, this does not imply that it is
> robust - as my example shows.  When reviewing the
> mailing list, there are several cases in which the
> answer to a question has been along the lines of
> "this
> example was tailored to the particular
> problem...because your application may be different,
> you must adjust the parameters to fit your specific
> problem."  In particular with an image guided
> surgery
> system, the software must be robust, because the
> programmer and user don't have all of the necessary
> time to create data specific solutions for every
> case
> - particularly in real-time as things are changing. 
> I
> admit some small amount of tweaking is necessary for
> determining the optimal solution, but a programmer
> or
> user shouldn't have two write a completely new
> program
> for each specific problem.
> 
> To summerize:
> 
> (1) I like ITK
> (2) I am sorry to have complained so much
> (3) I do appreciate the help that you have given me
> (4) I recognize that we all have different
> perspectives on how we solve problems.  I think the
> key is to try and find the best solution for every
> one
> (5) I think that, in this case, there may be a need
> for further documentation
> 
> 
> Thanks
> 
> david
>  
> --- Luis Ibanez <luis.ibanez@kitware.com> wrote:
> > 
> > Hi Daniel,
> > 
> > I'm affraid to have to disagree.
> > 
> > It doesn't make perfect sense to replace floats
> with
> > chars
> > and expect to get the same results, not even with
> > simple
> > operations.
> > 
> > Let's consider:
> > 
> >      T a;
> >      T b;
> >      T c = a * b;
> >      T d = a / b;
> >      T e = a - b;
> >      T f = a + b;
> > 
> > Can we expect this to work the same for T=char and
> > T=float ?
> > 
> > T=float and T=double will already give different
> > results...
> > 
> > and if you use VC++, T=float in debug mode and
> > T=float in
> > release mode will also give different results.
> > 
> > Even if we use the NumericTraits<> and cast to the
> > computational
> > types, there are always lateral effects the we
> have
> > to care about.
> > 
> > Do we want to discover these secondary effects at
> > run time in
> > an image guided surgery system ?
> > 
> > or do we want the developers to deal with the
> > problem at compile
> > time when they can afford the time to analyze the
> > problem and fix
> > it while having enough coffee available.
> > 
> > If we put ourselves in the shoes of a naive user
> of
> > Insight,
> > the first thing we should do is to take the
> naivety
> > out of him.
> > Naivety is not a desirable quality for a developer
> > of medical
> > image applications.
> > 
> > Insight is not only a software toolkit, it is also
> > an educational
> > resource. I think we should be commited to insist
> in
> > the special
> > requirements of medical imaging as opposed to
> plain
> > computer
> > graphics concepts. Insight is not Photoshop. The
> > images that we
> > are intended to process contain information about
> > somebody lying
> > on a bed in a hospital. Taking care of the
> > implications of data
> > types doesn't seem to be such a burden when we
> > consider it in
> > this perspective.
> > 
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/