[Insight-users] ITK for fluorescence microscopy - BioImageXD
Lassi Paavolainen
lopaavol at jyu.fi
Tue May 12 09:11:45 EDT 2009
Hi,
On Tue, 12 May 2009, alex gouaillard wrote:
> hi,
>
> We are also monitoring Qt 4.5 with Cocoa for the same reason. our latest test
> last week shows that it is not yet working well enough, but it is almost
> there. We think it's going to work within weeks and not months. Mac is the
> only platform under which we cannot make a 64bits build as of today. We had
> been working with wxWindow, and KWWidgets before that, it was not as feature
> extensive and professional looking as QT is. Moving Qt to LGPL was a great
> move from Nokia :D
Nice to hear about your tests. QT 4.5 surely looks promising and LGPL was
a really nice handout from Nokia.
> It is surely a naive question , as I don't know how you work internally, but
> is there a specific reason why you would go from python to Java instead of
> C++? As you are already using VTK and ITK as your core, why going through the
> extra wrapping step when you could do it all in C++? Then, you would be able
> to handle maintenance using CMake / CTest / CPack / CDash.
>
> Again, I'm sure you have your own reasons, andthat it is a naive question.
> I'm just curious.
No, that's a good question. Doing everything in C++ or using Java and
wrapped VTK/ITK/QT have both positive sides. We are looking into Java
rather than C++ mainly for the same reasons as with Python. It has safer
typing system than C++ and a garbage collector (well I as a
old-fashioned guy like to destroy my objects myself) that both help us to
reduce the amount of bugs and the time we spend on fixing bugs.
Other reasons are that Java is more "modern", platform independent and a
little faster to write than C++. Also interfacing other Java libraries
like Bio-Formats and maybe ImageJ classes is easier from Java.
You already mentioned the good parts of doing everything in C++ and I
fully agree with you. It would be nice to do everything without having to
be concerned about wrapping code (props to Gaetan for doing great work
here) not only for VTK/ITK but probably for QT too. Of course if we would
do everything in C++ then we would have a problem with Java libraries like
Bio-Formats :) and we would have more problems when looking for new
developers. I've learned C++ in my youth but unfortunately almost
everything is taught nowadays in Java in universities (at least in
Finland) so it is a lot easier to find Java developer than C++ (or Python)
developer these days.
Lassi
> On May 12, 2009, at 7:50 AM, Lassi Paavolainen wrote:
>
>> Hi Alex and Dan,
>>
>> On Tue, 12 May 2009, alex gouaillard wrote:
>>
>>> On May 12, 2009, at 4:24 AM, Daniel James White wrote:
>>>
>>>> BXD might well move to java wrapped VTK/ITK from python in the
>>>> future, primarily for platform independence reasons: No 64 Bit Carbon
>>>> on OSX.
>>>> That would also allow a direct interface with Fiji-ImageJ , which
>>>> would be very cool.
>>>
>>> Why not using Cocoa instead of carbon if you want 64 bits?
>>> Java rapping is interesting on hits own, of course, for other reasons.
>>
>> I'm no Mac expert but the reason is that wxPython cannot be compiled in 64
>> bits in Cocoa if I remember correctly. We are looking into QT 4.5 for that
>> reason also.
>>
>> Actually that is not the primarily reason to investigate using Java but
>> only one. There are also other reasons mainly focusing on software
>> development process (new architecture, handling of 50k+ LOC, testing,
>> documentation, work force) and other future plans like 64 bitness and
>> networking.
>>
>> Of course Python has its own benefits including dynamic type system and
>> already well working wrapping of ITK. By the way, is Java wrapping of ITK
>> already as well working as is Python wrapping?
>>
>> Lassi
>>
>> --
>> Lassi Paavolainen, M.Sc.
>> Software Engineer
>> BioImageXD (http://www.bioimagexd.net)
>> lopaavol at jyu.fi
>
--
Lassi Paavolainen, M.Sc.
Software Engineer
BioImageXD (http://www.bioimagexd.net)
lopaavol at jyu.fi
More information about the Insight-users
mailing list