[Insight-developers] ConceptCheck & Wrapping : ITK 3.4 Update

Stephen Aylward Stephen.Aylward at Kitware.com
Thu Sep 20 18:54:27 EDT 2007 

As another option - default to no concept checking and throw a warning
in cmake if concept checking is disabled - warning will state that itk
will not check to ensure that input images will produce valid results.

When they enable concept checking in cmake throw another warning that
says that old code may produce a compilation error and give a hint on
how the error would look.

In that manner the user can choose his/her poison :)

stephen

On 9/20/07, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Luis,
>
> I wish I could have made the t-con (but I was playing golf). I suggest we
> back out the changes and look for a solution after the release that handles
> the problem more gracefully and diplomatically. At a minimum, a warning
> message that tells users what they need to do is a good interim solution for
> the release.
>
> Bill
>
>
> On 9/20/07, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> >
> >
> > Hi Bill,
> >
> > Yeap, we struggle with this item durnig the bug triage tcon...
> >
> > The issue at the base is that filters deriving from the
> > FiniteDifferenceImageFilter generate incorrect output when
> > they are instantiated on output image whose pixel is not of
> > real type.
> >
> > Users who are currently using this filters are obtaining
> > incorrect outputs.
> >
> > The compromised found here was that concept checking will
> > provide a compilation error message so that users know
> > that the usage of the filter is incorrect. Users can still
> > force the compilation by disabling the concept checking
> > option in CMake. [we added this option as a note in the
> > bug tracker discussion]
> >
> > Refactoring the internal implementation of the filters is
> > certainly another option, but requires a wider modification
> > of the code.
> >
> > Adding a run-time warning is also an option....
> >
> > In the meantime:
> > We could simply backup the concept check added to the
> > Laplacian and FiniteDifference image filters, and postpone
> > dealing with the long term solution until after we are done
> > with the relase of ITK 3.4.
> >
> > I have replaced the instantiations of the class in the
> > wrapping and vtkITK because even if we make them compile
> > they will be are producing incorrect outputs.
> >
> > ...
> >
> >
> >
> >    Luis
> >
> >
> >
> > --------------------
> > Bill Lorensen wrote:
> > > Luis,
> > >
> > > Below is the error condition generated by Visual Studio while
> > > compiling InsightApplications/vtkITK. PIcture yourself as a new employee
> > > or a graduate student who is given the task of installing the latest ITK
> > > and build an application that has compiled for years. You did not write
> > > the application, you have not changed your employer's code, you only
> > > updated to the latest and greatest ITK release. I imagine that other
> > > compilers produce similar errors.
> > >
> > > I am all in favor of concept checking. And we are stuck with the error
> > > messages that the compilers produce. So a developer writing a new
> > > application will have to figure out how to fix the problem,. But we
> > > should not be breaking code that compiled with an earlier ITK release
> > > unless there is no other work around. The burden is on us, the ITK
> > > developers that failed to use concept checking in these filters when we
> > > first introduced concept checking. We should bear the pain, not ITK
> > > customers.
> > >
> > > Maybe we should look at a solution that warns the developer at run-time
> > > and gives explicit instructions (in human readable form) on how to
> > > correct the problem. We could also internally create a floating point
> > > type image but still warn the developer.
> > >
> > > Bill
> > >
> > >
> > > c:\lorensen\Projects\Insight\Code\Common\itkConceptChecking.h(726) :
> > > error C2440: 'initializing' : cannot convert from
> > > 'itk::Concept::Detail::UniqueType_bool<__formal>' to
> > > 'itk::Concept::IsFloatingPoint<T>::Constraints::IntegralT'
> > >
> > > with
> > >
> > > [
> > >
> > > __formal=false
> > >
> > > ]
> > >
> > > and
> > >
> > > [
> > >
> > >
> >
> T=itk::FiniteDifferenceImageFilter<vtkITKImageToImageFilterSS::InputImageType,vtkITKImageToImageFilterSS::OutputImageType>::OutputPixelValueType
> > >
> > > ]
> > >
> > > No constructor could take the source type, or constructor overload
> > > resolution was ambiguous
> > >
> > > c:\lorensen\Projects\Insight\Code\Common\itkConceptChecking.h(725) :
> > > while compiling class-template member function 'void
> > > itk::Concept::IsFloatingPoint<T>::Constraints::constraints(void)'
> > >
> > > with
> > >
> > > [
> > >
> > >
> >
> T=itk::FiniteDifferenceImageFilter<vtkITKImageToImageFilterSS::InputImageType,vtkITKImageToImageFilterSS::OutputImageType>::OutputPixelValueType
> > >
> > > ]
> > >
> > >
> >
> c:\lorensen\Projects\Insight\Code\Common\itkFiniteDifferenceImageFilter.h(219)
> > > : see reference to class template instantiation
> > > 'itk::Concept::IsFloatingPoint<T>' being compiled
> > >
> > > with
> > >
> > > [
> > >
> > >
> >
> T=itk::FiniteDifferenceImageFilter<vtkITKImageToImageFilterSS::InputImageType,vtkITKImageToImageFilterSS::OutputImageType>::OutputPixelValueType
> > >
> > > ]
> > >
> > >
> >
> c:\lorensen\Projects\Insight\Code\Common\itkDenseFiniteDifferenceImageFilter.h(68)
> > > : see reference to class template instantiation
> > > 'itk::FiniteDifferenceImageFilter<TInputImage,TOutputImage>' being
> > compiled
> > >
> > > with
> > >
> > > [
> > >
> > > TInputImage=vtkITKImageToImageFilterSS::InputImageType,
> > >
> > > TOutputImage=vtkITKImageToImageFilterSS::OutputImageType
> > >
> > > ]
> > >
> > >
> >
> c:\lorensen\Projects\Insight\Code\BasicFilters\itkAnisotropicDiffusionImageFilter.h(74)
> > > : see reference to class template instantiation
> > > 'itk::DenseFiniteDifferenceImageFilter<TInputImage,TOutputImage>' being
> > > compiled
> > >
> > > with
> > >
> > > [
> > >
> > > TInputImage=vtkITKImageToImageFilterSS::InputImageType,
> > >
> > > TOutputImage=vtkITKImageToImageFilterSS::OutputImageType
> > >
> > > ]
> > >
> > >
> >
> C:\lorensen\Projects\Insight\Code\BasicFilters\itkCurvatureAnisotropicDiffusionImageFilter.h(57)
> > > : see reference to class template instantiation
> > > 'itk::AnisotropicDiffusionImageFilter<TInputImage,TOutputImage>' being
> > > compiled
> > >
> > > with
> > >
> > > [
> > >
> > > TInputImage=vtkITKImageToImageFilterSS::InputImageType,
> > >
> > > TOutputImage=vtkITKImageToImageFilterSS::OutputImageType
> > >
> > > ]
> > >
> > >
> >
> C:\lorensen\Projects\InsightApplications\vtkITK\Common\vtkITKCurvatureAnisotropicDiffusionImageFilterSS.h(30)
> > > : see reference to class template instantiation
> > >
> > 'itk::CurvatureAnisotropicDiffusionImageFilter<TInputImage,TOutputImage>'
> > > being compiled
> > >
> > > with
> > >
> > > [
> > >
> > > TInputImage=vtkITKImageToImageFilterSS::InputImageType,
> > >
> > > TOutputImage=vtkITKImageToImageFilterSS::OutputImageType
> > >
> > > ]
> > >
> > > c:\lorensen\Projects\Insight\Code\Common\itkConceptChecking.h(727) :
> > > error C2440: 'initializing' : cannot convert from
> > > 'itk::Concept::Detail::UniqueType_bool<__formal>' to
> > > 'itk::Concept::IsFloatingPoint<T>::Constraints::ExactT'
> > >
> > > with
> > >
> > > [
> > >
> > > __formal=false
> > >
> > > ]
> > >
> > > and
> > >
> > > [
> > >
> > >
> >
> T=itk::FiniteDifferenceImageFilter<vtkITKImageToImageFilterSS::InputImageType,vtkITKImageToImageFilterSS::OutputImageType>::OutputPixelValueType
> > >
> > > ]
> > >
> > > No constructor could take the source type, or constructor overload
> > > resolution was ambiguous
> > >
> > >
> > >
> > >
> > > On 9/20/07, *Bill Lorensen* <bill.lorensen at gmail.com
> > > <mailto:bill.lorensen at gmail.com>> wrote:
> > >
> > >     Since vtkITK is breaking, it seems that we have broken the ITK API.
> > >     Maybe we should look for an alternative fix that does not break the
> > API.
> > >
> > >     Bill
> > >
> > >
> > >     On 9/20/07, *Luis Ibanez* <luis.ibanez at kitware.com
> > >     <mailto:luis.ibanez at kitware.com>> wrote:
> > >
> > >
> > >         In order to fix bug 221
> > >         http://public.kitware.com/Bug/view.php?id=221
> > >         <http://public.kitware.com/Bug/view.php?id=221>
> > >
> > >         We agreed on introducing a ConceptCheck to ensure that
> > >         instantiations
> > >         of filters deriving from the FiniteDifferenceImageFilter, will
> > >         use an
> > >         output image type with pixel type float or double.
> > >
> > >
> >
> http://www.itk.org/Insight/Doxygen/html/classitk_1_1FiniteDifferenceImageFilter.html
> > >         <
> >
> http://www.itk.org/Insight/Doxygen/html/classitk_1_1FiniteDifferenceImageFilter.html
> > >
> > >
> > >         The reason is that this filter performs computations using that
> > >         type,
> > >         and therefore an instantiation that uses anything different from
> > >         float
> > >         and double will result in erroneous results.
> > >
> > >         This modification has the effect of breaking the following
> > >
> > >           a) Wrapping instantiations using non-real pixel types in
> > >         output image
> > >           b) InsightApplications/vtkITK classes using non-real pixel
> > type.
> > >
> > >
> > >         The course of action is then to remove these non-real
> > >         instantiation and
> > >         only leave the ones where the output image type is of pixel type
> > >         float
> > >         or double. In practice it will come down to float, since we
> > don't
> > >         include "double" as pixel type in the wrapping.
> > >
> > >
> > >         Please let us know if you have any concerns,
> > >
> > >
> > >            Thanks
> > >
> > >
> > >                Luis
> > >
> > >         _______________________________________________
> > >         Insight-developers mailing list
> > >         Insight-developers at itk.org <mailto:Insight-developers at itk.org>
> > >         http://www.itk.org/mailman/listinfo/insight-developers
> > >         <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

More information about the Insight-developers mailing list