[Insight-developers] Physical coordinate transforms (Bug No. 6558) was: Backward Compatibility

[Andreas Keil]

Dear Luis, Stephen, and Bill,

thank you for your remarks on bug no. 0006558
(http://www.itk.org/Bug/view.php?id=6558). I totally agree with Stephen on
creating new functions.

In the meantime, Volker Daum added a note to the bug report observing that
ITK's interpolation functions all work with center-based coordinates - of
course ;-)

I therefore think it would be safe to go for the center-based solution
when implementing new functions (without #define). I would very be happy
to bring forward this solution. However, I think there's a lot of other
issues to discuss. It may even be necessary to bring this topic together
with the one on direction cosines and itk::OrientedImage. It would maybe
make sense to clearly define the coordinate systems / coordinates which
are available in ITK (index, continuousIndex, physicalPoint,
patientBasedPoint, ...) and then name the transformation functions
accordingly. And there's the suggestion of using template programming for
speeding up the transformations...

Do you think it would make sense to create a Wiki page on this topic and
try to come to a conclusion there? If we would like to create a
long-lasting and general solution (for ITK 4.0?) it would maybe be a
better placce to discuss than the bug report.

Andreas

A question on the side: I am wondering why the developers mailing list's
return-path header is set to the author instead of the list? Should
discussions become private per default?




-----Original Message-----
From: stephen.aylward at gmail.com [mailto:stephen.aylward at gmail.com] On
Behalf Of Stephen Aylward
Sent: Tuesday, May 13, 2008 13:29
To: Andreas Keil
Cc: Insight-developers at itk.org
Subject: Re: [Insight-developers] Backward Compatibility

This may be a situation where we create a new function that performs
the operation correctly, and we begin to deprecate the old function.

It is highly likely that someone in the world has also discovered this
feature and developed a work-around in their code.  If we change it,
we will break their code, i.e., WE will create a bug in their code
that would be extremely difficult for them to detect and potentially
critical to the output they produce.

The new function name should be more explicit of the operation it
performs:

TransformPhysicalPointToCenteredIndex   ?
TransformPhysicalPointToRoundedIndex ?

etc

That's my suggestion.

Stephen

On Tue, May 13, 2008 at 5:16 AM, Andreas Keil <andreas.keil at cs.tum.edu>
wrote:
> Dear ITK developers,
>
>  triggered by the "adopt a bug program" - I consider getting more
involved
>  in ITK. For this reason, I kindly ask you to point me to ITK's backward
>  compatibility policy. So far, I found the sources mentioned at
>  http://www.itk.org/Wiki/ITK_Policies_and_Procedures which tell me that
>  this issue is still an open discussion. I am still wondering how
strictly
>  backward compatibility is enforced, i.e. in which cases backward
>  compatibility is allowed to be broken. (I mean, there must be cases
where
>  it may be broken, e.g. when fixing severe bugs.)
>  I am specifically wondering about the following two bugs I reported:
>
>  # 0004560 (http://www.itk.org/Bug/view.php?id=4560)
>  Here, I would vote for reopening the issue and throwing exceptions
>  whenever one of the Set... methods is called with the parameter i out
of
>  bounds. Throwing an error here would not really change ITK's behaviour.
It
>  would only change the exception handling which is anyways only
performed
>  in case a user used the class incorrectly. If I were such a user, I
would
>  be glad to have a changed behaviour here, wouldn't I?
>
>  # 0006558 (http://www.itk.org/Bug/view.php?id=6558)
>  In the case of this so far unattended but IMHO really severe bug, every
>  fix would change behaviour since the current implementation is plain
>  wrong. I would have volunteered to work on a fix. However, I don't feel
>  experienced enough to work on this bug which is located in the heart of
>  ITK - the ImageBase class, esp. since it requires changing ITK's
>  behaviour.
>
>  Looking forward to your comments,
>  Andreas.