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

[Stephen Aylward]

Hmm, I guess I see the advanced mechanism as only making things worse
- for example, right now the ITK_USE_CONSOLIDATED_MORPH... operator
(how many new ITK users will know what this refers to) isn't in
advanced, that is, it is a standard cmake var.   Yet that option is
probably relevant to a much smaller audience of users than some vars
in advanced, e.g., ITK_USE_REVIEW.   In that manner, we're forcing
novice users to turn on advanced to get access to some common options
and at the same time, with advanced turned-off we are presenting them
with options that they are not likely to use.

Not certain we can solve this easily via email.   We should probably
just schedule this for a tcon.

Stephen


On Sun, Sep 14, 2008 at 4:50 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> 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
>>>>
>>>
>>>
>>>
>>>
>>
>



-- 
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(518) 371-3971 x300