[Insight-users] Not so Silly questions about registration

[Luis Ibanez]

David, Daniel


I'll take back some of my statements:


1) I have to admit that the gradient filter should

    a) produce valid output with all types

       or

    b) prevent users from instantiating it for
       the types that are known not to be valid.

    So, a bug report has been filled to this end.
    Bug Id  283 in Gnats.

    http://www.itk.org/cgi-bin/gnatsweb.pl/Insight/


2)  Documentation of the filters should state the
     valid types on which they can be instantiated,
     and mention those types that are known to be
     invalid.


3)  The MeanSquaresImageMetric should produce valid
     output when instantiated on unsigned char,

     or

     It should prevent users from performing such
     instantiation. (through concept checking for
     example, as Josh pointed out).

     A bug has been logged in Gnats:  Bug Id 284



I will however stand in the following points:


1)  PTA - Pixel Type Awareness is fundamental.

     Automatics ('transparent') type conversions are
     undesirable. Even when they happen, the user
     shold be aware of their existence. Since
     lateral effect can be expected from such
     conversions.


2)  It is hard to expect that ITK components could
     be used as black boxes. I admit that this would
     be nice, but this seems to be unrealistic at this
     point.

     Parameter tunning is an inherent aspect of
     correct algorithm use. Unfortunately this is
     required for fitting algorithms to particular
     applications.

     We could imagine a higher layer of ITK classes
     encapsulating the domain-specific details.
     E.g.  a itk::MRItoPETRegistrationMethod class
     could encapsulate a number of components and
     define appropriate default values for the
     parameters.  This may be a layer to be added
     and to be evaluated.


3)  I understand that parameter fitting impose a
     barrier for users. However, let's remark that
     this is not an ITK specific issue. It is an
     intrinsic characteristic of every algorithmic
     implementation.

     Take any published paper on medical imaging
     and count the number of parameters associated
     with the method described in the paper. Then go
     back and check if the authors mention the numerical
     range for all the parameters. Then pass again and
     check if the authors provide different sets of
     parameters for different image modalities. Pass
     again and check if the authors will send you the
     source code for the method implementation.

     Whenever you find such a paper, we could be in
     position to measure how complete or incomplete is
     ITK and we could evaluate robustness in a fair
     context.

     In the meantime the best we could do is to gather
     Segmentation and Registration recipies defining
     sets of ITK components and their parameters theat
     have been proved to be effective for specific
     problems. The problem definition will probably
     include: Image modality, anatomical structure, and
     purpose of the processing.


4)  The users should be encouraged to write specific
     applications for every new specific problem.
     ITK should be as generic as possible, but the
     medical image applications developed on top of
     ITK (or any other toolkit) should be as specific
     as possible since this reduce the risk of unexpected
     behavior at run time. There is an important difference
     between generality and robustness.

     FDA requirements for software validation will encourage
     you to include *only* relevant functionalities in a
     particular application. The more specific, the better.
     Simply because the more specific your application is,
     the easier is to test it for conformace to a particular
     purpose.



        Luis



----------------------------------

David Holmes 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
>