[Insight-developers] CMake Flag to make itk::Image behave like itk::OrientedImage

[Bill Lorensen]

Stephen,

I agree that a hierarchy of some sort would help. Now, we just use the
ADVANCED mechanism of cmake.

Bill

On Sun, Sep 14, 2008 at 4:45 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Stephen,
>
> I agree with you in that the additional CMake variables are a burden.
>
> Any alternative suggestions that allows us to improve ITK and at the
> same time maintain backward compatibility are welcome.
>
>
>   Luis
>
>
> ---------------------------
> Stephen Aylward wrote:
>>
>> Another cmake variable?!?!?
>>
>> We now have 26 boolean cmake variables that begin with ITK_ and turn
>> on/off an option.  That means that there are 2^26 = 67,108,864
>> different possible combinations of ITK configurations that we should
>> be testing and supporting.
>>
>> Even worse, that means that users now have 26 different decisions to
>> make when installing ITK.
>>
>> What a wonderful example of feature creep degrading a package...
>>
>> s
>>
>> On Sun, Sep 14, 2008 at 12:52 PM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>>
>>> Luis,
>>>
>>> They may all boil down to a few issues. For example, the OrientedImage
>>> constructor set two matrices to Identity. This is not done in Image.
>>> I'm fixing that now.
>>>
>>> Bill
>>>
>>> On Sun, Sep 14, 2008 at 12:24 PM, Luis Ibanez <luis.ibanez at kitware.com>
>>> wrote:
>>>
>>>> Hi Hans,
>>>>
>>>> As we agreed during the ITK Tcon 2.0 on Friday:
>>>>
>>>>   http://www.itk.org/Wiki/Minutes_091208
>>>>
>>>> a CMake flag has now been added to the top CMakeLists.txt
>>>> file with the purpose of optionally changing the itk::Image
>>>> to behave like the itk::OrientedImage.
>>>>
>>>> You can now turn this option on by going to the CMake Advanced
>>>> flags and changing:
>>>>
>>>>
>>>>      ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE
>>>>
>>>> The code from
>>>>
>>>>
>>>>  SetSpacing
>>>>  SetDirection
>>>>  TransformPhysicalPointToIndex
>>>>  TransformIndexToPhysicalPoint
>>>>  TransformPhysicalPointToContinuousIndex
>>>>  TransformContinuousIndexToPhysicalPoint
>>>>
>>>>
>>>> was copied from the itk::OrientedImage into the itk::Image.
>>>>
>>>> The new code is only used if the ITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE
>>>> flag is ON.
>>>>
>>>> Once the dust settles we can prevent the code duplication by moving
>>>> this into specific methods that the itk::OrientedImage can inherit
>>>> from the itk::Image.
>>>>
>>>> After fixing code in a couple of places, this complies with the flag
>>>> ON (at least under Linux with Gcc 4.1).
>>>>
>>>> However, as you predicted, a large number of test fail when the flag
>>>> is ON. An Experimental build with the flag ON was submitted yesterday
>>>> from zion. You will find the failing tests of this build at:
>>>>
>>>> http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=171151
>>>>
>>>> There are 106 failing tests.
>>>> They broadly fall in the following categories:
>>>>
>>>> 1) ImageIO
>>>>   - Analyze
>>>>   - Nrrd
>>>>
>>>> 2) Mathematical Morphology
>>>>
>>>> 3) Image Registration
>>>>   - normal framework and
>>>>   - deformable registration
>>>>
>>>> 4) Resampling
>>>>
>>>>
>>>> My suggestion is to split these groups among several developers.
>>>>
>>>> I'll be happy to look at the Image registration problems.
>>>>
>>>> Hopefully, as Ken pointed out, after fixing a couple of them
>>>> we will find a pattern to follow.
>>>>
>>>>
>>>> Please let us know if this makes sense,
>>>>
>>>>
>>>>    Thanks
>>>>
>>>>
>>>>      Luis
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>>
>