[Insight-developers] orientation

[Bill Lorensen]

Rather than branch, we can wait until we decide when the 4.0 release
will occur. Then we can use the development version as the precursor
to 4.0.

On Wed, Aug 6, 2008 at 10:35 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> 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
>>
>