[Insight-developers] Code to dis-allow instantiation of itk::Image

Bill Lorensen bill.lorensen at gmail.com
Fri Sep 5 13:37:58 EDT 2008


I suggest we wait until everyone is back from their trips.

On Fri, Sep 5, 2008 at 12:04 PM, Stephen Aylward
<Stephen.Aylward at kitware.com> wrote:
> Great idea!!!
>
> s
>
> On Fri, Sep 5, 2008 at 11:58 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>>
>> Hi Hans,
>>
>> Thanks a lot for looking at this problem and taking the initiative in
>> a way forward.
>>
>>
>>
>>       I have no objection to committing the changes.
>>
>>
>> However, you may want to warn the lists regarding the fact that the
>> Dashboard will be red for the following days.
>>
>> I'll be out at MICCAI tomorrow, but will be able to help clean up the
>> Dashboard starting on Monday. If we all chip in a bit, it shouldn't
>> take too long to take the Dashboard back to green.
>>
>>
>>   Thanks
>>
>>
>>      Luis
>>
>>
>>
>> -------------------
>> Hans Johnson wrote:
>>>
>>> Luis,
>>>
>>> As discussed on the TCON over the past few weeks, there is a need to be
>>> able to disallow instantiation of itk::Image in order to identify places in
>>> the code that will implicitly downcast the itkOrientedImage to an itkImage.
>>>  This will be particularly important for three cases:
>>>
>>>   1. Identify places in the current library where filters are creating
>>>      internal temporary images that downcast itk::OrientedImage image
>>>      to itk::Image
>>>   2. Identify problems that will occur when itk::Image takes on the
>>>      behavior that is currently relegated to itk::OrientedImage (i.e.
>>>      In ITK 4.0) and itkOriented image becomes an empty shell
>>>   3. Allow a safe path for application developers transition to
>>>      itk::OrientedImage by allowing the compiler to verify that all
>>>      instances of itk::Image have been properly converted to
>>>      itk::OrientedImage
>>>
>>>
>>> Please review the patch at the bottom of this file.  I will commit this
>>> patch this afternoon if I do not receive any objections.
>>> =============================================
>>> NOTE:  If ITK_DISABLE_UNORIENTED_IMAGE=ON, then the first compiler error
>>> that occurs is:
>>>
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkImage.h:
>>> In static member function 'static itk::SmartPointer<itk::Image<TPixel,
>>> VImageDimension> > itk::Image<TPixel, VImageDimension>::New() [with TPixel =
>>> double, unsigned int VImageDimension = 2u]':
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkBSplineDeformableTransform.txx:64:
>>>  instantiated from 'itk::BSplineDeformableTransform<TScalarType,
>>> NDimensions, VSplineOrder>::BSplineDeformableTransform() [with TScalarType =
>>> double, unsigned int NDimensions = 2u, unsigned int VSplineOrder = 2u]'
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkBSplineDeformableTransform.h:122:
>>>  instantiated from 'static
>>> itk::SmartPointer<itk::BSplineDeformableTransform<TScalarType, NDimensions,
>>> VSplineOrder> > itk::BSplineDeformableTransform<TScalarType, NDimensions,
>>> VSplineOrder>::New() [with TScalarType = double, unsigned int NDimensions =
>>> 2u, unsigned int VSplineOrder = 2u]'
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkTransformFactory.h:37:
>>>  instantiated from 'static void
>>> itk::TransformFactory<T>::RegisterTransform() [with T =
>>> itk::BSplineDeformableTransform<double, 2u, 2u>]'
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkTransformFactoryBase.cxx:67:
>>>  instantiated from here
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkImage.h:93:
>>> error: cannot allocate an object of abstract type 'itk::Image<double, 2u>'
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkImage.h:83:
>>> note:   because the following virtual functions are pure within
>>> 'itk::Image<double, 2u>':
>>>
>>> /Users/hjohnson/src/brains2/iplFreeware/unpackdir/Insight/Code/Common/itkImage.h:290:
>>> note:     void itk::Image<TPixel,
>>> VImageDimension>::RespectsImageOrientationImplicitly() const [with TPixel =
>>> double, unsigned int VImageDimension = 2u]
>>>
>>> =============
>>>
>>>      61   // Initialize coeffient images
>>>      62   for ( unsigned int j = 0; j < SpaceDimension; j++ )
>>>      63     {
>>> ** 64     m_WrappedImage[j] = ImageType::New();
>>>      65     m_WrappedImage[j]->SetRegions( m_GridRegion );
>>>
>>> =============
>>> This does add a new CMAKE variable option, but that option should be
>>> temporary until itk::Image behaves like itk::OrientedImage in ITK v4.0.
>>>
>>> Thanks,
>>> Hans
>>>
>>> --
>>> Hans J. Johnson, Ph.D.
>>> Hans-johnson at uiowa.edu
>>>
>>> 278 GH
>>> The University of Iowa
>>> Iowa City, IA 52241
>>> (319) 353 8587
>>>
>>>
>>>
>>> Index: CMakeLists.txt
>>> ===================================================================
>>> RCS file: /cvsroot/Insight/Insight/CMakeLists.txt,v
>>> retrieving revision 1.311
>>> diff -r1.311 CMakeLists.txt
>>> 215a216,221
>>>>
>>>>  # TURN OFF itk::Image as a valid type to ensure that itkOrientedImages
>>>
>>> can be used everywhere
>>>>
>>>>  MARK_AS_ADVANCED(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>  OPTION(ITK_DISABLE_UNORIENTED_IMAGE "Disallow instantiation of
>>>
>>> itk::Image to determine where itk::OrientedImage is not properly
>>> implemented" OFF)
>>>>
>>>>  IF( ITK_DISABLE_UNORIENTED_IMAGE )
>>>>           ADD_DEFINITIONS( -DITK_DISABLE_UNORIENTED_IMAGE )
>>>>  ENDIF( ITK_DISABLE_UNORIENTED_IMAGE )
>>>
>>> Index: Code/Common/itkImage.h
>>> ===================================================================
>>> RCS file: /cvsroot/Insight/Insight/Code/Common/itkImage.h,v
>>> retrieving revision 1.143
>>> diff -r1.143 itkImage.h
>>> 6c6
>>> <   Date:      $Date: 2008-02-04 12:34:11 $
>>> ---
>>>>
>>>>   Date:      $Date: 2008/02/04 12:34:11 $
>>>
>>> 284a285,291
>>>>
>>>>  //The following template functions are invalid if ImageOrientation is
>>>
>>> forced to be
>>>>
>>>>  //respected and defined as in the OrientedImage case.
>>>>  #if defined(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>   //This is a pure abstract member function that is only defined in
>>>
>>> itkOrientedImage.
>>>>
>>>>   //  It is here to force a compiler error when trying to instantiate
>>>
>>> an itkImage.
>>>>
>>>>   virtual void RespectsImageOrientationImplicitly(void) const =0;
>>>>  #endif
>>>
>>> 293a301,303
>>>>
>>>>  #if defined(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>     this->RespectsImageOrientationImplicitly();  //This does nothing,
>>>
>>> and will hopefully be compiled away.
>>>>
>>>>  #endif
>>>
>>> 315a326,328
>>>>
>>>>  #if defined(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>     this->RespectsImageOrientationImplicitly();  //This does nothing,
>>>
>>> and will hopefully be compiled away.
>>>>
>>>>  #endif
>>>
>>> 337a351,353
>>>>
>>>>  #if defined(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>     this->RespectsImageOrientationImplicitly();  //This does nothing,
>>>
>>> and will hopefully be compiled away.
>>>>
>>>>  #endif
>>>
>>> 353a370,372
>>>>
>>>>  #if defined(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>     this->RespectsImageOrientationImplicitly();  //This does nothing,
>>>
>>> and will hopefully be compiled away.
>>>>
>>>>  #endif
>>>
>>> 377a397,399
>>>>
>>>>  #if defined(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>     this->RespectsImageOrientationImplicitly();  //This does nothing,
>>>
>>> and will hopefully be compiled away.
>>>>
>>>>  #endif
>>>
>>> Index: Code/Common/itkOrientedImage.h
>>> ===================================================================
>>> RCS file: /cvsroot/Insight/Insight/Code/Common/itkOrientedImage.h,v
>>> retrieving revision 1.22
>>> diff -r1.22 itkOrientedImage.h
>>> 135a136,140
>>>>
>>>>  #if defined(ITK_DISABLE_UNORIENTED_IMAGE)
>>>>   //This is a pure abstract member function that is only defined in
>>>
>>> itkOrientedImage.
>>>>
>>>>   //  It is here to force a compiler error when trying to instantiate
>>>
>>> an itkImage.
>>>>
>>>>   virtual void RespectsImageOrientationImplicitly(void) const { return; }
>>>>  #endif
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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