[Insight-developers] ConceptCheck & Wrapping : ITK 3.4 Update
Luis Ibanez
luis.ibanez at kitware.com
Thu Sep 20 19:00:55 EDT 2007
Hi Bill,
Yeap, sounds good.
I have now put the new concept check inside:
#ifdef ITK_USE_STRICT_CONCEPT_CHECKING
#endif
CVS diff:
http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkFiniteDifferenceImageFilter.h?root=Insight&sortby=date&r2=1.35&r1=1.34
so most users will not be exposed to it, but we
can still enabled this advanced CMake option in
some Dashboard machines. The option is set to
OFF by default:
http://www.itk.org/cgi-bin/viewcvs.cgi/CMakeLists.txt?root=Insight&sortby=date&r2=1.267&r1=1.266
http://www.itk.org/cgi-bin/viewcvs.cgi/itkConfigure.h.in?root=Insight&sortby=date&r2=1.19&r1=1.18
This is a temporary compromise that will allow us to
expand the use of concept checking without breaking
backward compatibility.
We will then revisit this issue after we cut the
release of ITK 3.4. BTW: We anticipate to tag and
branch this Saturday (conditioned to the state of
the Dashboard).
Luis
--------------------------------------------------
Bill Lorensen 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
> <mailto: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>
> > <mailto: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>
> > <mailto: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>
> <mailto: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>
> >
> >
> >
>
>
More information about the Insight-developers
mailing list