[Insight-users] Rotations missing in
CenteredVersorTransformInitializer
Luis Ibanez
luis.ibanez at kitware.com
Wed Aug 2 07:06:40 EDT 2006
Hi Michael
Thanks for logging the bug entry.
We will have to discuss the API among developers,
because there is a backward compatibility issue here.
The right thing to do would be to simply add the
rotation to the initialization, but then code that
was previously working in a certain manner will change
its behavior.
We probably will add a boolean flag and expose it in
the CenteredVersorTransformInitializer API so that you
can choose to include rotations in the initialization.
Initialy this flag will be false, and maybe over several
releases we will switch it to true by default.
Regards,
Luis
--------------------
Michael Bell wrote:
> Luis,
>
> I've entered a bug. I assume this must be fixed in
> CenteredVersorTransformInitializer, and that I can not call
> GetPrincipalAxesToPhysicalAxesTransform externally?
>
>
> thanks,
> michael
>
> On 7/29/06, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
>>
>>
>> Hi Michael,
>>
>> There is code around that can be used to fix this deficiency of
>> the CenteredVersorTransformInitializer class.
>>
>>
>> Could you please add a bug entry to the bug tracker so we make
>> sure of taking care of this issue before the next release ?
>>
>> http://public.kitware.com/Bug/index.php
>>
>>
>> We just need to invoke the new method of the ImageMomentsCalculator
>>
>> GetPrincipalAxesToPhysicalAxesTransform()
>>
>> from the CenteredVersorTransformInitializer.
>>
>> An example on how to fix this class can be seen in the application:
>>
>> InsightApplications/
>> LandmarkInitializedMutualInformationRegistration
>> MomentsRegistrator.txx
>>
>>
>> in line 91.
>>
>>
>>
>> Regards,
>>
>>
>> Luis
>>
>>
>>
>> ----------------------
>> Michael Bell wrote:
>> > Simon,
>> >
>> > Thanks for the advice. The CenteredVersorTransformInitializer seems
>> > like the correct class to use. If I understand correctly, you are
>> > saying that the rotation is not initialized correctly, but the
>> > translation is. I think I can live with that for now.
>> >
>> > thanks,
>> > michael
>> >
>> > On 7/28/06, Simon Warfield <warfield at crl.med.harvard.edu> wrote:
>> >
>> >> Michael Bell wrote:
>> >> > Gaetan,
>> >> >
>> >> > I wrapped itkVersorRigid3DTransformOptimizer. No problem, amazingly
>> >> easy.
>> >> > Now I need to wrap CenteredTransformInitializer. It has three
>> template
>> >> > classes:
>> >> > Tansform,Image,Image. How do I do the transformType? (In this
>> case it
>> >> > is VersorRigid3DTransform).
>> >>
>> >> You might want to use the CenteredVersorTransformInitializer which is
>> >> designed to initialize for a VersorRigid3DTransform:
>> >>
>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredVersorTransformInitializer.html
>>
>> >>
>> >>
>> >> However, be aware the class has a bug. The implementation initializes
>> >> the center of rotation and the translation, and computes the principal
>> >> axes of the two data sets to be aligned but does not then use the
>> >> difference in the axes to initialize the rotation.
>> >> Instead an identity rotation transform is used.
>> >>
>> >> --
>> >> Simon
>> >>
>> >> >
>> >> > thanks,
>> >> > michael
>> >> >
>> >> > On 7/27/06, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>> >> >>
>> >> >> I forgot to say that darcs works with http, if you don't need to
>> >> have a
>> >> >> write access to the repository. The patches can be sent by email
>> >> (darcs
>> >> >> send), or pushed to the repository through ssh.
>> >> >> Most of the time, the firewalls are not a problem.
>> >> >>
>> >> >> Thanks again
>> >> >>
>> >> >> Gaetan
>> >> >>
>> >> >>
>> >> >>
>> >> >> Le Thu, 27 Jul 2006 20:29:38 +0200, Michael Bell
>> >> >> <michael.bell at acm.org> a
>> >> >> écrit:
>> >> >>
>> >> >> > Gaetan,
>> >> >> >
>> >> >> > Unfortunately, I am behind a firewall, and I can not use darcs or
>> >> cvs.
>> >> >> >
>> >> >> > The attached patch has grammar and spelling fixes, but no content
>> >> >> > changes. The document is well written, and I will try to add my
>> >> first
>> >> >> > class today or tomorrow.
>> >> >> >
>> >> >> > thanks,
>> >> >> > michael
>> >> >> >
>> >> >> > On 7/27/06, Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>> >> >> >> On Thu, 27 Jul 2006 17:51:28 +0200, Michael Bell
>> >> >> <michael.bell at acm.org>
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >> > Gaetan,
>> >> >> >> >
>> >> >> >> > I'm reading through the pdf now, and it is very helpful. As a
>> >> >> native
>> >> >> >> > English speaker, may I be of assistance in editing some
>> spelling
>> >> >> and
>> >> >> >> > grammar? Is the document available for changing?
>> >> >> >>
>> >> >> >> sure ! any help is welcome :-)
>> >> >> >> The article is available in article/Article.tex . The best
>> way to
>> >> >> record
>> >> >> >> the changes is to use darcs (usage is partially explained in the
>> >> >> >> article),
>> >> >> >> but if don't want to use it, a simple patch would be ok :-)
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >>
>> >> >> >> Gaetan
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> > 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/
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> 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/
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Simon K. Warfield, Ph.D. warfield at crl.med.harvard.edu
>> >> Phone: 617-732-7090 FAX: 617-582-6033
>> >> Associate Professor of Radiology, Harvard Medical School
>> >> Director, Computational Radiology Laboratory
>> >> Departments of Radiology at Children's Hospital and
>> >> Brigham and Women's Hospital,
>> >> Thorn 329, Dept Radiology, Brigham and Women's Hospital
>> >> 75 Francis St, Boston, MA, 02115
>> >> MA 280, Dept Radiology, Children's Hospital Phone: 617-355-4566
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
More information about the Insight-users
mailing list