It works fine with the Wrap_ITK option. except that I cant set the <br>tkRecursiveMultiResolutionPyramidImageFilterIF3IF3_Pointer to a <br>itkMultiResolutionImageRegistrationMethodIF3IF3_Pointer object<br><br>The registration object expects a SWIGTYPE object where as with the cswig_java build API I can set the output of the pyramid to
<br>registrator.setFixedPyramid(...<br><br>Like I said, it's not a big deal, just a slight performance issue and thank you very much for the response. I will post something if I find a way to get the MultiResPyramid class working with the bindings.
<br><br>-blair<br><br><div><span class="gmail_quote">On 2/1/07, <b class="gmail_sendername">Gaëtan Lehmann</b> <<a href="mailto:gaetan.lehmann@jouy.inra.fr">gaetan.lehmann@jouy.inra.fr</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Le Thu, 01 Feb 2007 21:02:26 +0100, Blair Cruz <<a href="mailto:blair.cruz@gmail.com">blair.cruz@gmail.com</a>> a<br>écrit:<br><br>> Quick question. I noticed that when I build ITK with the cswig_java<br>> option
<br>> I get a jar that has a different api then when I use the wrap_itk<br>> option. I<br>> particular, the class names change, an example is:<br>><br>> itkMutualInformationImageToImageMetricIF3IF3_Pointer is generated with
<br>> the<br>> wrap_itk option in cmake, and:<br>> itkMutualInformationImageToImageMetricF3F3_Pointer is generated with the<br>> cswig_java option in cmake.<br>><br>> There are a few other differences in the API as well, for instance, with
<br>> the<br>> wrap_itk option I cant set a<br>> itkRecursiveMultiResolutionPyramidImageFilterIF3IF3_Pointer object to a<br>> itkMultiResolutionImageRegistrationMethodIF3IF3_Pointer object.<br><br>The name of the template instantiations have been changed to be more
<br>consistent in all the instantiations, and more descriptive.<br><br>> I can get<br>> by without this but I do notice a performance difference.<br><br>I doubt you can see any difference: cswig and WrapITK both use the same
<br>system (cable swig), and wrap the same code (ITK).<br><br>> There is also a<br>> very noticeable size difference in the compiled libraries (~60mb).<br><br>WrapITK produce huge binaries because it instantiate a lot of templated
<br>classes. On one side you get a lot much classes, but on the other side,<br>you have bigger binaries.<br>Note that you can easily customize your WrapITK to fit your needs, by<br>removing the wrap_*.cmake files of the class you don't use, or by turning
<br>to OFF the WRAP_ options of the modules or the types you don't use. All<br>those methods will highly impact the size of the binary.<br>You may also want to build WrapITK in MinSizeRel mode, and to turn on<br>explicit instantiations in cmake.
<br><br>> I would<br>> use the cswig_java option however it wont build with this on os x.<br><br>cswig has open the way, but should be replaced by WrapITK in the next<br>releases. I don't think cswig has ever worked properly out of the box with
<br>java on mac os x.<br><br>><br>> This is not an issue right now but in the future I will have to address<br>> some<br>> performance issues and I would like to know why this is happening.<br>><br><br>I hope to have replied above. Please let us know if you have any problem,
<br>or if you think to things which could be enhanced.<br><br>Regards,<br><br>Gaetan<br><br><br><br>--<br>Gaëtan Lehmann<br>Biologie du Développement et de la Reproduction<br>INRA de Jouy-en-Josas (France)<br>tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
<br><a href="http://voxel.jouy.inra.fr">http://voxel.jouy.inra.fr</a><br></blockquote></div><br>