[Insight-users] WrapITK DemonsRegistration problem

Fri Aug 18 12:04:44 EDT 2006

Charl,

Have you used DemonsRegistration successfully? I am trying to use it
today, but I get the error: java.lang.UnsatisfiedLinkError:
itkDemonsRegistrationFilterIF2IF2IVF22_itkDemonsRegistrationFilterIF2IF2IVF22_New

Then, when I look in itkDemonsRegistrationFilterJNI, the file is very
small, and it does not include the above function. Most of the other
registrationJNI files are much longer, and they include the New
function.

The small JNI file, which does not have the full declarations, is
common among those cmake files using POINTER_WITH_SUPERCLASS. Do I
need to create the superclass, itkPDEDeformationRegistrationFilter,
before I can successfully use the demons class?

thanks,
michael

On 7/26/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>
> Some registration files were added some days ago by Charl P. Botha.
> It can be a good starting point. See :
> http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=annotate_shade;h=20060720122257-2fc9d-767d4ccd51a2ea65ac456d70f55b94303c984eb2.gz;f=Modules/Registration/wrap_itkDemonsRegistrationFilter.cmake
> http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=annotate_shade;h=20060720122257-2fc9d-767d4ccd51a2ea65ac456d70f55b94303c984eb2.gz;f=Modules/Registration/wrap_itkLevelSetMotionRegistrationFilter.cmake
> http://voxel.jouy.inra.fr/darcsweb/darcsweb.cgi?r=WrapITK;a=annotate_shade;h=20060720122257-2fc9d-767d4ccd51a2ea65ac456d70f55b94303c984eb2.gz;f=Modules/Registration/wrap_itkSymmetricForcesDemonsRegistrationFilter.cmake
>
> The WrapITK article also contains some doc - I didn't get feedback about
> it yet, so I'm not sure it si good enough to write wrappers without help:
> http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/WrapITK_-_Enhanced_languages_support_for_the_Insight_Toolkit.pdf
>
> Gaetan
>
> Le Wed, 26 Jul 2006 18:29:36 +0200, Michael Bell <michael.bell at acm.org> a
> écrit:
>
> > Gaetan,
> >
> > It is the registration tools that I am interested in, so this should
> > be perfect. I will look into things and come back with questions.
> >
> > thanks,
> > michael
> >
> >
> > On 7/26/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
> >> On Wed, 26 Jul 2006 16:18:52 +0200, Michael Bell <michael.bell at acm.org>
> >> wrote:
> >>
> >> > Gaetan,
> >> >
> >> > The only issue for me will be the classes that are not wrapped. Why
> >> > are particular classes not wrapped? Can I help remedy the situation?
> >> >
> >>
> >> I have tried to wrap as much classes as possible (63% of the filters are
> >> wrapped at this time). However, ITK is a large toolkit, and I don't
> >> always
> >> have the needed knowledge to choose the revelant template parameters.
> >> That's the case for example for the registration part which I have never
> >> used (and do not plan to use).
> >> So yes you can help, just by creating the new wrappers with the revelant
> >> template parameters.
> >> The syntax has been made to be easy to use, and I would be pleased to
> >> help
> >> to do that.
> >>
> >> Let me know if you are interested in adding some new classes
> >>
> >> Gaetan
> >>
> >>
> >> > thanks,
> >> > michael
> >> >
> >> > On 7/26/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
> >> >> On Wed, 26 Jul 2006 15:59:55 +0200, Michael Bell
> >> <michael.bell at acm.org>
> >> >> wrote:
> >> >>
> >> >> > Gaetan,
> >> >> >
> >> >> > I am using ext3 on linux, which has a maximum filesize of 255
> >> >> > characters. I see that Brad has addressed possible solutions to
> >> this.
> >> >> >
> >> >> > I commented out the MetaDataDictionary, and the rest of the compile
> >> >> > finished without errors. Things seem to run well.
> >> >>
> >> >> Great !
> >> >> I'll try to fix that issue when I get some free time.
> >> >>
> >> >> > I noticed that some
> >> >> > classes are named differently than the straight itk wrapping. For
> >> >> > example: itkImageMetricIF3 instead of itkImageMetricF3. Does the I
> >> >> > stand for Image?
> >> >>
> >> >> That's it
> >> >> Several changes were made in the naming policy, to make it more
> >> >> expressive, for example, the I for an Image, VI for a VectorImage,
> >> ...
> >> >>
> >> >> Let me know if you found other problems
> >> >>
> >> >> Gaetan
> >> >>
> >> >> >
> >> >> > Thanks for your help,
> >> >> > michael
> >> >> >
> >> >> > On 7/25/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> I also have the same file with a very long name in my build tree,
> >> >> but I
> >> >> >> don't have any problem to access it. I thought this kind of
> >> problem
> >> >> was
> >> >> >> limited to windows (I say that but André didn't report any problem
> >> >> like
> >> >> >> that). What is you file system ?
> >> >> >> This kind of problem is already know and has been fixed for string
> >> >> lists
> >> >> >> and vectors in files Module/Base/*SwigExtras*.
> >> >> >> However, this workaround is inherited from the current ITK
> >> wrappers,
> >> >> and
> >> >> >> has not been modified in WrapITK - I'm not sure how it can be
> >> used to
> >> >> >> fix
> >> >> >> your problem.
> >> >> >>
> >> >> >> Brad, can you help on that point ?
> >> >> >>
> >> >> >> As a quick fix, I think you should disable the class which use
> >> this
> >> >> >> type:
> >> >> >> MetaDataDictionary.
> >> >> >> To do that, just comment the line
> >> >> >>
> >> >> >>    WRAP_NON_TEMPLATE_CLASS("itk::MetaDataDictionary")
> >> >> >>
> >> >> >> in the file Modules/Base/wrap_ITKCommonBase.cmake
> >> >> >> Taht being said, I think you will have the same problem with other
> >> >> types
> >> >> >> used in more useful classes :-/
> >> >> >> Let me now if it still fail (or if it work !)
> >> >> >>
> >> >> >> Gaetan
> >> >> >>
> >> >> >>
> >> >> >> Le Tue, 25 Jul 2006 15:55:29 +0200, Michael Bell
> >> >> <michael.bell at acm.org>
> >> >> >> a
> >> >> >> écrit:
> >> >> >>
> >> >> >> > Gaetan,
> >> >> >> >
> >> >> >> > I am trying wrapitk on linux while waiting to receive VS2003. I
> >> >> really
> >> >> >> > like the setup, especially being able to choose what is wrapped.
> >> >> >> >
> >> >> >> > I am getting the following error while compiling (ITK&CableSwig
> >> >> 2.8):
> >> >> >> > Generating wrap_ITKCommonBaseJava.cxx
> >> >> >> > Unable to open
> >> >> >> >
> >> >> >>
> >> >>
> >> /data/WrapITK/Build_Linux/Java/InsightToolkit/SWIGTYPE_p_std___Rb_tree_iteratorTstd__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_t_std__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_tR_std__pairTconst_std__basic_stringTchar_std__char_traitsTchar_t_std__allocatorTchar_t_t_itk__SmartPointerTitk__MetaDataObjectBase_t_tp_t.java
> >> >> >> >
> >> >> >> > The file name is too long. Any ideas on how to correct this?
> >> >> >> >
> >> >> >> > thanks,
> >> >> >> > michael
> >> >> >> >
> >> >> >> > On 7/19/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
> >> >> >> >>
> >> >> >> >> Michael,
> >> >> >> >>
> >> >> >> >> André Bongers reported to be able to build WrapITK with the
> >> .NET
> >> >> 2003
> >> >> >> >> c++.
> >> >> >> >> WrapITK surely still have some bugs on windows plateform, but
> >> if
> >> >> you
> >> >> >> >> want
> >> >> >> >> to try it, I will surely be more reactive that official ITK
> >> >> >> developers.
> >> >> >> >> WrapITK can be downloaded at
> >> >> >> >>
> >> >> >> >>
> >> >> http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/WrapITK.tar.gz
> >> >> >> >>
> >> >> >> >> or directly with darcs
> >> >> >> >>
> >> >> >> >>    darcs get --partial
> >> >> >> >> http://voxel.jouy.inra.fr/darcs/contrib-itk/WrapITK/
> >> >> >> >>
> >> >> >> >> and requires ITK 2.8.1
> >> >> >> >>
> >> >> >> >> Gaetan
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Le Wed, 19 Jul 2006 22:10:55 +0200, Michael Bell
> >> >> >> <michael.bell at acm.org>
> >> >> >> >> a
> >> >> >> >> écrit:
> >> >> >> >>
> >> >> >> >> > SwigInc.txt is being generated from SwigInc.txt.in, which has
> >> >> the
> >> >> >> >> > extra carriage return character. I suspect this is a problem
> >> >> >> because I
> >> >> >> >> > am using the cygwin recommended unix files, but this file is
> >> a
> >> >> dos
> >> >> >> >> > file. If I dos2unix SwigInc.txt.in and make, this error goes
> >> >> away,
> >> >> >> and
> >> >> >> >> > all of the SwigIn.txt files are correct. If I run dos2unix on
> >> >> the
> >> >> >> >> > entire Wrapping directory, many problems are fixed.
> >> >> >> >> >
> >> >> >> >> > Which shows the next issue:
> >> >> >> >> > javac does not understand cygwin paths. This issue can be
> >> fixed
> >> >> >> using
> >> >> >> >> > cygpath.
> >> >> >> >> >
> >> >> >> >> > Which shows the next problem:
> >> >> >> >> > javac VXLNumericsJava.java
> >> >> >> >> > cannot resolve symbol itkbase
> >> >> >> >> >
> >> >> >> >> > I haven't solved that problem, but I am certain it would
> >> reveal
> >> >> >> more.
> >> >> >> >> >
> >> >> >> >> > It's pretty clear that no one is maintaining the wrappers
> >> with
> >> >> >> cygwin.
> >> >> >> >> > Please make this clear somewhere in the documentation so the
> >> >> next
> >> >> >> >> > person does not waste weeks on this, as I have.
> >> >> >> >> >
> >> >> >> >> > So, we know that VS8 does not work. Cygwin does not work.
> >> What
> >> >> does
> >> >> >> >> > work on Windows? I can change compilers, but I can't spend
> >> time
> >> >> >> >> > hunting for a platform that does work. Please advise.
> >> >> >> >> >
> >> >> >> >> > thanks,
> >> >> >> >> > michael
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > On 7/17/06, Michael Bell <michael.bell at acm.org> wrote:
> >> >> >> >> >> ITK people,
> >> >> >> >> >>
> >> >> >> >> >> I have made some progress tracking down this error:
> >> >> >> >> >> wrap_vnl_matrix.xml from gccxml_cc1plus:
> >> >> >> >> >>  error: too many filenames given.  Type gccxml_cc1plus
> >> --help
> >> >> for
> >> >> >> >> usage
> >> >> >> >> >> make[2]: ***
> >> [Wrapping/CSwig/VXLNumerics/wrap_vnl_matrix.xml]
> >> >> >> Error 1
> >> >> >> >> >>
> >> >> >> >> >> This is the operation that fails (paths shortened for
> >> >> >> readability):
> >> >> >> >> >> gccxml -fxml-start=_cable_ -fxml=wrap_vnl_matrix.xml
> >> >> >> >> >> --gccxml-gcc-options SwigInc.txt -DCSWIG
> >> -DCABLE_CONFIGURATION
> >> >> >> >> >> wrap_vnl_matrix.cxx
> >> >> >> >> >>
> >> >> >> >> >> SwigInc.txt contains a list of include paths:
> >> >> >> >> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Build_Cygwin
> >> >> >> >> >>
> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/Algorithms
> >> >> >> >> >> ...
> >> >> >> >> >>
> >> >> -I/cygdrive/d/Applications/InsightToolkit-2.8.1/Code/BasicFilters
> >> >> >> >> >> ^M
> >> >> >> >> >>
> >> >> >> >> >> Then, it has the ^M character at the end. If I remove this
> >> >> >> character,
> >> >> >> >> >> the xml file appears to be created correctly. Does anyone
> >> know
> >> >> >> where
> >> >> >> >> >> this is being created, or why, or how I can prevent it? Is
> >> >> this an
> >> >> >> >> ITK
> >> >> >> >> >> problem, or a CableSwig problem?
> >> >> >> >> >>
> >> >> >> >> >> Please, I'm obviously willing to do the leg work, but it
> >> will
> >> >> >> take me
> >> >> >> >> >> 10 times as long to figure this out than if an ITK developer
> >> >> would
> >> >> >> >> >> step up and help. I've already shown that I was not the
> >> first
> >> >> >> person
> >> >> >> >> >> to deal with this problem, and there are likely others who
> >> have
> >> >> >> not
> >> >> >> >> >> said anything.
> >> >> >> >> >>
> >> >> >> >> >> thanks,
> >> >> >> >> >> michael
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> michael.bell at acm.org
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Utilisant le client e-mail révolutionnaire d'Opera :
> >> >> >> >> http://www.opera.com/mail/
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Utilisant le client e-mail révolutionnaire d'Opera :
> >> >> >> http://www.opera.com/mail/
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> 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
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> 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
> >>
> >
> >
>
>
>
> --
> Utilisant le client e-mail révolutionnaire d'Opera :
> http://www.opera.com/mail/
>

-- 
michael.bell at acm.org