[Insight-users] Not so Silly questions about registration
Luis Ibanez
luis.ibanez@kitware.com
Tue, 25 Feb 2003 16:25:35 -0500
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
>