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

Luis Ibanez luis.ibanez at kitware.com
Wed May 14 08:18:34 EDT 2008


Hi Andreas,

Yes, it is a great idea to create a Wiki-proposal page.

We have created a stub for you at:
http://www.itk.org/Wiki/ITK_Oversight_Committee#2008

(please modify the name to match your Wiki user account).

The link in the last row of the table points to
http://www.itk.org/Wiki/Proposals:Refactoring_Index_Point_Coordinate_System

Please feel free to sketch there a proposal for refactoring
the conversions between Physical Points and Indices.

For the sake of clarity, it will be great to insert some diagrams
in the proposal.

You may want to reuse the ones that we created for the Software Guide.
They are available in

          InsightDocuments/SoftwareGuide/Art/
              ImageOriginAndSpacing.fig

They are XFig diagrams.
Or... feel free to use any other drawing system. However, it will be
nice if you made the source files available (e.g. upload them to the
Wiki), since it is likely that we will need to draw on top of them,
or will need to make corrections.


----

About the reply option in the list, what we use to do is "reply all".

It is much better if all discussions remain public. ITK is a fully
open project and we prefer to keep record of all the discussions
that relate to design and implementation of the code.




     Thanks



        Luis



-------------------
Andreas Keil wrote:
> 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.
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> 


More information about the Insight-developers mailing list