[Insight-users] posssible bug in ÎTK 3.18

[Luis Ibanez]

Surprise, surprise:

   Code that was not tested...  was Broken !

now that we are building the NonUniformBSpline class,
it fails to compile in several platforms.

http://public.kitware.com/dashboard.php?name=itk

with the error message:

*

/Utilities/vxl/core/vnl/algo/vnl_svd.h:193: error:
'vnl_svd<T>::vnl_svd(const vnl_svd<T>&) [with T = double]' is private

*
It has however, a curious pattern...

It fails in some Linux builds, but not all...

It fails in Mac builds,

and in some of the SunOS builds, but not all...

it seems to build on Windows (so far).

The problem seems to originate from line 313 of

Insight/Code/Common/itkNonUniformBSpline.txx:

  vnl_matrix<double> B = vnl_matrix_inverse<double>(N_matrix.transpose() *
N_matrix) * N_matrix.transpose() * data_matrix;


We will track the problem and clean it up...


     Luis


-------------------------------------------------------------------
On Wed, Apr 28, 2010 at 12:54 PM, Luis Ibanez <luis.ibanez at kitware.com>wrote:

>
> Hi Jochen,
>
> Thanks a lot for filing the bug report on this problem
>
>   http://public.kitware.com/Bug/view.php?id=10633
>
>
> We just committed a patch to fix the problem.
>
>
> It includes a unit test for the NonUniformBSpline class.
> The test still needs some work on verifying the
> correctness of its numerical outputs.
>
> The changes are:
>
>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkNonUniformBSpline.h?root=Insight&r1=1.6&r2=1.7&sortby=date[
> ^<http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkNonUniformBSpline.h?root=Insight&r1=1.6&r2=1.7&sortby=date>
> ]
>
>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkNonUniformBSpline.txx?root=Insight&r1=1.8&r2=1.9&sortby=date[
> ^<http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkNonUniformBSpline.txx?root=Insight&r1=1.8&r2=1.9&sortby=date>
> ]
>
>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/Common/itkCommonTests2.cxx?root=Insight&r1=1.30&r2=1.31&sortby=date[
> ^<http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/Common/itkCommonTests2.cxx?root=Insight&r1=1.30&r2=1.31&sortby=date>
> ]
>
>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/Common/CMakeLists.txt?root=Insight&r1=1.253&r2=1.254&sortby=date[
> ^<http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/Common/CMakeLists.txt?root=Insight&r1=1.253&r2=1.254&sortby=date>
> ]
>
> New File: Unit Test.
>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/Common/itkNonUniformBSplineTest.cxx?root=Insight&sortby=date&view=log[
> ^<http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/Common/itkNonUniformBSplineTest.cxx?root=Insight&sortby=date&view=log>
> ]
>
>
> We will wait to see tomorrow's Dashboard.
> If it is green we will commit the same patch to the ITK 3.18 branch.
>
>
>     Please let us know if you see any problems,
>
>
>            Thanks,
>
>
>                  Luis
>
>
>
>
> --------------------------------------------------------------------------------------
>
> On Wed, Apr 28, 2010 at 10:44 AM, Luis Ibanez <luis.ibanez at kitware.com>wrote:
>
>> Hi Jochem,
>>
>> Thanks a lot for pointing this out and for your detailed
>> analysis of the problem.
>>
>> As an immediate remedy,
>> Please apply the following patch to your checkout of ITK
>>
>> Index: itkNonUniformBSpline.h
>> ===================================================================
>> RCS file: /cvsroot/Insight/Insight/Code/Common/itkNonUniformBSpline.h,v
>> retrieving revision 1.6
>> diff -p -u -r1.6 itkNonUniformBSpline.h
>> --- itkNonUniformBSpline.h    25 Mar 2010 14:57:49 -0000    1.6
>> +++ itkNonUniformBSpline.h    28 Apr 2010 14:40:53 -0000
>> @@ -26,6 +26,7 @@
>>
>>  #include "itkPoint.h"
>>  #include "itkObject.h"
>> +#include "itkObjectFactory.h"
>>  #include "itkArray.h"
>>
>>  namespace itk {
>>
>> --------------------------------------------------------------------------
>>
>>
>> You make a good point that this class is to fitting the
>> quality standards of ITK.
>>
>> In particular, it has the comment:
>>
>>  *
>>  * CAUTION: THIS CLASS IS STILL UNDER DEVELOPMENT.
>>  *
>>  */
>>
>> and it doesn't have a unit test.
>>
>> I'm now adding a unit test for it....
>> and most likely we will find with it that some functionalities
>> of the class are not fully implemented.
>>
>>
>> I'll the put this patch in both ITK CVS HEAD
>> and the ITK 3.18 branch.
>>
>>
>>     Regards,
>>
>>
>>         Luis
>>
>>
>>
>>
>> ---------------------------------------------------------------------------------
>>
>> On Wed, Apr 28, 2010 at 10:34 AM, Neuhaus Jochen <
>> j.neuhaus at dkfz-heidelberg.de> wrote:
>>
>>> Hi List,
>>>
>>>
>>> I have a simple test program that produces compiler errors with ITK 3.18
>>> in Debug mode (on Visual Studio 2008), but was working with ITK 3.16:
>>>
>>> #include <itkNonUniformBSpline.h>
>>> int main(int /* argc */, char* /*argv*/[])
>>> {
>>>  typedef itk::NonUniformBSpline<3> SplineType;
>>>  SplineType::Pointer mySpline;
>>>  return 0;
>>> }
>>>
>>>
>>> itkNonUniformBSpline.h changed between 3.16 and 3.18 to use
>>> itkGetConstReferenceMacro instead of direct inline Get-methods (see bug
>>> http://public.kitware.com/Bug/view.php?id=10458). The problem is, that
>>> the type if the member that is returned is not an itk-type, but stl::vector.
>>> Inside itkGetConstReferenceMacro, in Debug mode, the stl vector is piped
>>> into an itk::OStringStream:
>>>
>>> itkDebugMacro("returning " << #name " of " << this->m_##name );
>>>
>>> <-- this produces an compiler error that there is no valid << operator.
>>>
>>> Unfortunately, there is no unit test for itkNonUniformBSpline and the
>>> class is not used anywhere in ITK, therefore it was probably never compiled
>>> by a dartclient. Another example that untested code is to be considered
>>> buggy code...
>>>
>>> However, we use this class in our MITK toolkit, which makes MITK
>>> incompatible with ITK 3.18.
>>>
>>> This bug is easy enough to fix (use itk::VectorContainer instead of
>>> stl::vector), but the question is, will there be a bugfix release of ITK for
>>> this in the not too distant future that we could wait for? Or should we try
>>> to circumvent this on the MITK side to establish compatibility with ITK
>>> 3.18?
>>>
>>>
>>> Best Regards,
>>>  Jochen
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100429/569ab675/attachment-0001.htm>