[Insight-developers] orientation

[Bill Lorensen]

I don't think we should do a branch. We can discuss this more. I won't
do anything rash.

A branch will be too hard to test. We are already sloppy in keeping
one dashboard green. I don't see how we can keep two green.

Changes in behavior are much easier to document and notify users.
Compilations errors are a miserable way to notify users.

Bill

On Wed, Aug 6, 2008 at 8:15 PM, Stephen Aylward
<Stephen.Aylward at kitware.com> wrote:
> Who are you and what have you done with the real Bill Lorensen? :)
>
> This would really break backward compatibility - Kent gave a great
> example.   People who counted on SetDirections having no effect will
> suddenly have their images move.   Registration will fail.  The change
> in behavior could be extremely hard for someone to track down if they
> haven't been reading this thread.
>
> Since is a major break in backward compatibility, let's wait until the
> 4.0 release.   Please don't do this in the main trunk.   I suggest we
> make a branch for 4.0 and put such things in it.
>
> Stephen
>
>
>
>
> On Wed, Aug 6, 2008 at 7:44 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> This might be the right time to do what Kent (and others) are
>> suggesting. Simply rename OrientedImage to Image and make
>> OrientedImage a derived subclass with no new behaviour. I think the
>> time penalty will  be little to none for Release builds.
>>
>> I volunteer to do this over the next month or so. Right now, the
>> weather in the Nortjheast is much to beautiful to stay inside.
>>
>> Kent, can you make a bug for this issue and assign it to me.
>>
>> Thanks,
>>
>> Bill
>>
>> On Wed, Aug 6, 2008 at 2:05 PM, kent williams
>> <norman-k-williams at uiowa.edu> wrote:
>>> In looking back through this thread I think I'm beginning to see where the
>>> problem is: SpatialObject is using methods that are not implemented
>>> consistently between itk::Image and itk::OrientedImage.
>>>
>>> It seems that OrientedImage performs as expected, and that Image does not,
>>> which suggests a possible solution -- rename itk::OrientedImage as
>>> itk::Image, and make itk::OrientedImage simply a derived class of itk::Image
>>> with no new behavior, for backwards compatibility.
>>>
>>> Would this break any existing code -- more to the point, is there code that
>>> depends on itk::Image behaving in an apparently incorrect manner?
>>>
>>>
>>> On 8/6/08 12:47 PM, "Rupert Brooks" <rupe.brooks at gmail.com> wrote:
>>>
>>>> Hi Simon,
>>>>
>>>> I would be very interested in the test you mention.   Maybe the wiki
>>>> is the right place to post it?
>>>>
>>>> Due to the problems with gradients on non-axis-aligned Oriented
>>>> images, i created my own class, FastOrientedImage.  Its in the insight
>>>> Journal somewhere.   I was not aware of oriented images having
>>>> problems in 2D and I thought I had used them successfully in the past.
>>>>  I've been planning to switch back to the more mainstream ITK approach
>>>> and retire my custom classes - thus - I'd be very interested in this
>>>> bug.
>>>>
>>>> Thanks
>>>> Rupert
>>>>
>>>
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
>
>
> --
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - Chapel Hill Office
> http://www.kitware.com
> (518) 371-3971 x300
>