[Insight-users] Cswig_java/Wrap_ITK generate different java APIs

[Gaëtan Lehmann]

Can you send a small example that I can try to build ?

Thanks,

Gaetan


Le Fri, 02 Feb 2007 04:37:21 +0100, Blair Cruz <blair.cruz at gmail.com> a  
écrit:

> It works fine with the Wrap_ITK option. except that I cant set the
> tkRecursiveMultiResolutionPyramidImageFilterIF3IF3_Pointer to a
> itkMultiResolutionImageRegistrationMethodIF3IF3_Pointer object
>
> The registration object expects a SWIGTYPE object where as with the
> cswig_java build API I can set the output of the pyramid to
> registrator.setFixedPyramid(...
>
> 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.
>
> -blair
>
> On 2/1/07, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
>>
>> Le Thu, 01 Feb 2007 21:02:26 +0100, Blair Cruz <blair.cruz at gmail.com> a
>> écrit:
>>
>> > Quick question.  I noticed that when I build ITK with the cswig_java
>> > option
>> > I get a jar that has a different api then when I use the wrap_itk
>> > option.  I
>> > particular, the class names change, an example is:
>> >
>> > itkMutualInformationImageToImageMetricIF3IF3_Pointer is generated with
>> > the
>> > wrap_itk option in cmake, and:
>> > itkMutualInformationImageToImageMetricF3F3_Pointer is generated with  
>> the
>> > cswig_java option in cmake.
>> >
>> > There are a few other differences in the API as well, for instance,  
>> with
>> > the
>> > wrap_itk option I cant set a
>> > itkRecursiveMultiResolutionPyramidImageFilterIF3IF3_Pointer object to  
>> a
>> > itkMultiResolutionImageRegistrationMethodIF3IF3_Pointer object.
>>
>> The name of the template instantiations have been changed to be more
>> consistent in all the instantiations, and more descriptive.
>>
>> > I can get
>> > by without this but I do notice a performance difference.
>>
>> I doubt you can see any difference: cswig and WrapITK both use the same
>> system (cable swig), and wrap the same code (ITK).
>>
>> > There is also a
>> > very noticeable size difference in the compiled libraries (~60mb).
>>
>> WrapITK produce huge binaries because it instantiate a lot of templated
>> classes. On one side you get a lot much classes, but on the other side,
>> you have bigger binaries.
>> Note that you can easily customize your WrapITK to fit your needs, by
>> removing the wrap_*.cmake files of the class you don't use, or by  
>> turning
>> to OFF the WRAP_ options of the modules or the types you don't use. All
>> those methods will highly impact the size of the binary.
>> You may also want to build WrapITK in MinSizeRel mode, and to turn on
>> explicit instantiations in cmake.
>>
>> >  I would
>> > use the cswig_java option however it wont build with this on os x.
>>
>> cswig has open the way, but should be replaced by WrapITK in the next
>> releases. I don't think cswig has ever worked properly out of the box  
>> with
>> java on mac os x.
>>
>> >
>> > This is not an issue right now but in the future I will have to  
>> address
>> > some
>> > performance issues and I would like to know why this is happening.
>> >
>>
>> I hope to have replied above. Please let us know if you have any  
>> problem,
>> or if you think to things which could be enhanced.
>>
>> Regards,
>>
>> 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
>>



-- 
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