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

[Bill Lorensen]

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>
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20070920/45461909/attachment-0001.html