[Insight-users] Re: WrapITK issues and article review

Tue Jul 18 08:38:29 EDT 2006

On Tue, 11 Jul 2006 07:19:06 +0200, Dan Mueller <d.mueller at qut.edu.au>  
wrote:

> Hi Geatan,
>
> I am in the process of reviewing your Insight Journal article "WrapITK".
>
> While compiling and installing WrapITK I have come across a number of
> issues. For your information my system details are as follows:
>
>     * Operating System=Windows XP SP2
>     * CMake=CMake 2.4.2
>     * Compiler=Microsoft.NET 2003 (7.1.3088)
>     * ITK=InsightToolkit-2.8.1
>     * CableSwig=CVS checkout on 10th July 2006, 9:30AM (GMT+10:00)
>     * WrapITK=Nightly archive from
>       http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/WrapITK.tar.gz
>       downloaded on 10th July 2006, 8:45AM (GMT+10:00)
>     * Python=Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32
>       bit (Intel)] on win32
>
>
> *1. Error accessing __FUNCSIG__:*
> ...

Charl sent a patch to fix that, so it should be ok now :-)

>
> *2. Object file format limit exceeded:*
> During my first attempt to configure/compile WrapITK I used the default
> settings, EXCEPT that I set WRAP_unsigned_short=ON.

I suppose you want to say WRAP_unsigned_char=ON - WRAP_unsigned_short is  
ON by default

>
> Doing this caused the follow error during compilation of _BasePython:
> c:\dan\tools\itk\src\insighttoolkit-2.8.1\code\common\itksmartpointer.h(55)
> : fatal error C1128: object file format limit exceeded : more than
> 65,279 sections
>
> The Microsoft documentation says the following about C1128:
> An .obj file exceeded the number of allowable sections, a COFF object
> file format limitation.
> Reaching this section limitation can be the result of using /Gy and a
> debug build; /Gy causes functions to go into their own COMDAT sections.
> In a debug build, there is a debug info section for each COMDAT function.
> C1128 can also be caused when there are too many inline functions.
> To correct this error, divide your source file into multiple source code
> files.
>
> I reset the project to use the default CMake settings (ie.
> WRAP_unsigned_short=OFF) and this error went away. Perhaps when wrapping
> with lots of types (eg. default types + 1) I am reaching the object file
> limitations?? Maybe breaking _BasePython into 2 or more projects would
> solve the issue (if possible)?

It should be possible to break it into several modules, but it wouldn't be  
very nice: Base contains the most common things required by the others  
modules. Splitting it would make the dependencies more complex :-/

>
> *3. **Ambiguous call to overloaded function 'sqrt':*
> While compiling _DistanceMapPython I encountered the following error:
> wrap_itkSignedMaurerDistanceMapImageFilterPython.cxx
> c:\Dan\Tools\ITK\src\InsightToolkit-2.8.1\Code\BasicFilters\itkSignedMaurerDistanceMapImageFilter.txx(241)
> : error C2668: 'sqrt' : ambiguous call to overloaded function
>         C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\math.h(626): could be 'long double sqrt(long double)'
>         C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\math.h(578): or       'float sqrt(float)'
>         C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\math.h(200): or       'double sqrt(double)'
>         while trying to match the argument list '(unsigned short)'
>         C:\Program Files\Microsoft Visual Studio .NET
> 2003\Vc7\include\xmemory(156) : while compiling class-template member
> function 'void
> itk::SignedMaurerDistanceMapImageFilter<TInputImage,TOutputImage>::GenerateData(void)'
>         with
>         [
>             TInputImage=itk::Image<short,3>,
>             TOutputImage=itk::Image<short,3>
>         ]
>         wrap_itkSignedMaurerDistanceMapImageFilterPython.cxx(10865) :
> see reference to class template instantiation
> 'itk::SignedMaurerDistanceMapImageFilter<TInputImage,TOutputImage>'
> being compiled
>         with
>         [
>             TInputImage=itk::Image<short,3>,
>             TOutputImage=itk::Image<short,3>
>         ]
>
> I fixed this by editing itkSignedMaurerDistanceMapImageFilter.txx to
> explicitly casting to double before the call to sqrt.

This one looks like a ITK bug. Can you file a bug report ?

>
> *4. C**annot access protected member **EnlargeOutputRequestedRegion:*
> While compiling _SegmentationAndThresholdPython I encountered the
> following error:
> wrap_itkScalarConnectedComponentImageFilterPython.cxx(11151) : error
> C2248:
> 'itk::ConnectedComponentImageFilter<TInputImage,TOutputImage,TMaskImage>::EnlargeOutputRequestedRegion'
> : cannot access protected member declared in class
> 'itk::ConnectedComponentImageFilter<TInputImage,TOutputImage,TMaskImage>'
>         with
>         [
>             TInputImage=itk::Image<short,2>,
>             TOutputImage=itk::Image<short,2>,
>             TMaskImage=itk::Image<short,2>
>         ]
>         and
>         [
>             TInputImage=itk::Image<short,2>,
>             TOutputImage=itk::Image<short,2>,
>             TMaskImage=itk::Image<short,2>
>         ]
> c:\Dan\Tools\ITK\src\InsightToolkit-2.8.1\Code\BasicFilters\itkConnectedComponentImageFilter.h(149)
> : see declaration of
> 'itk::ConnectedComponentImageFilter<TInputImage,TOutputImage,TMaskImage>::EnlargeOutputRequestedRegion'
>         with
>         [
>             TInputImage=itk::Image<short,2>,
>             TOutputImage=itk::Image<short,2>,
>             TMaskImage=itk::Image<short,2>
>         ]
>
> To temporarily fix this and continue with the compile I renamed
> wrap_itkScalarConnectedComponentImageFilter.cmake to ensure it was not
> included. After re-configuring with CMake this project compiled  
> correctly.

That's odd !
The EnlargeOutputRequestedRegion() method is protected in several filters,  
and it does seem to be a problem. I don't have any idea about this problem

>
> *5. Python installation:*
> When I install WrapITK (ie. build the INSTALL project) it copies the
> created files to the CMAKE_INSTALL_PREFIX / WRAP_ITK_INSTALL_PREFIX
> folder (in my case C:/Program
> Files/WrapITK/lib/InsightToolkit/WrapITK/Python).
>
> However, the Python site-packages WrapITK.pth file does not contain the
> correct paths for usage. The generated WrapITK.pth file is:
> # Python pth file to add WrapITK's path to sys.path.
> C:/Program Files/WrapITK//lib/InsightToolkit/WrapITK/Python
> which does not allow Python access to all the files. I manually changed
> WrapITK.pth to:
> # Python pth file to add WrapITK's path to sys.path.
> C:/Program Files/WrapITK/lib/InsightToolkit/WrapITK/Python
> C:/Program Files/WrapITK/lib/InsightToolkit/WrapITK/lib
> to make it work correctly.

this should not be necessary because the path ending with lib is added at  
runtime.
Can you send me the file itkConfig.py, so I can check that the generated  
path are correct ?

>
> Also, the SwigRuntimePython.dll file is copied to the C:/Program
> Files/WrapITK/bin folder and is not accessible to Python. I had to
> manually copy this file to C:/Program
> Files/WrapITK/lib/InsightToolkit/WrapITK/Python to ensure Python finds  
> it.
>
> Finally, some required Python files (itk.py, itkBase.py, itkTemplate.py,
> itktesting.py, and itkTypes.py) were not copied to the installation
> folder. I manually copied these in order for Python to automatically
> detect WrapITK.

Installation work for me both with and without cmake's configurations  
since 5th july  
(http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=filediff;h=20060705192143-2fc9d-8c0ba68963b1da05a1e5cc48bb187da64d13f6d4.gz;f=CreateWrapperLibrary.cmake  
and  
http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=commit;h=20060704165851-2fc9d-687d5f0402c0f8fc84273ce1edeaeaf99f4ca2c4.gz),  
and Charl has also reported that it works on windows since this date.
Are you sure the WrapITK tarball was downloaded on 10th July 2006 ?

>
> *6. String formatting:*
> It seems the formatting for the itkExtras function auto_progress(bool)
> is not correct. I'm not a Python guru, so perhaps it's something at my
> end? The follow results don't look very nice to me:
>  >>> imagetype = itk.Image[itk.UC, 2]
>  >>> reader =
> itk.ImageFileReader[imagetype].New(FileName="c:/temp/input.png")
>  >>> itk.auto_progress(True)
>  >>> filter = itk.GradientMagnitudeImageFilter[imagetype,
> imagetype].New(Input=reader.GetOutput())
>  >>> filter.Update()
>  ?[2000D?[KitkGradientMagnitudeImageFilterIUC2IUC2: 0.000000
> ?[2000D?[KitkGradie
> ntMagnitudeImageFilterIUC2IUC2: 0.009979
> ?[2000D?[KitkGradientMagnitudeImageFilt
> erIUC2IUC2: 0.019958 ?[2000D?[KitkGradientMagnitudeImageFilterIUC2IUC2:
> 0.029938
>  ?[2000D?[KitkGradientMagnitudeImageFilterIUC2IUC2: 0.039917
> ?[2000D?[KitkGradie
> ntMagnitudeImageFilterIUC2IUC2: 0.049896
> ?[2000D?[KitkGradientMagnitudeImageFilt
> erIUC2IUC2: 0.059875 ?[2000D?[KitkGradientMagnitudeImageFilterIUC2IUC2:
> 0.069855
>  ?[2000D?[KitkGradientMagnitudeImageFilterIUC2IUC2: 0.079834
> ?[2000D?[KitkGradie
> ...
>

I'm using a character sequence to erase the line wich seems to not be  
supported by windows. Any help on that point is welcome - I'm still not a  
windows developer :-)

> Also, the output of the below example is not correct:
>  >>> print itk.size(reader)
> ÓýB?e [256, 256]>
>
> The above example should be:
>  >>> print itk.size(reader)
> <Size [256, 256]>
>
> Perhaps I have the wrong string encoding specified? Or perhaps print
> does not work on Python win32? Any thoughts/help?
>

this is a know problem  
(http://voxel.jouy.inra.fr/roundup/wrapitk/issue14), but I failed to fix  
it for now.
I also noticed that I haven't pushed the patch which fix that for  
LightObject class (and subclasses) - I will do that today

>
> Geatan, please feel free to contact me if you require any further
> clarification on the issues described above.
>
> Besides these minor issues, WrapITK is fantastic - thanks for the nice
> addition to ITK! I'll be posting my review to the article soon.

Thanks for your feedbacks :-)

Gaetan

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr