[Insight-users] Bio-Formats in ITK (was: Re: ITK for fluorescence microscopy - BioImageXD)

Curtis Rueden ctrueden at wisc.edu
Tue May 12 18:14:33 EDT 2009 

Message bounced due to "too many recipients" -- sending to one mailing list
at a time. :-)

---------- Forwarded message ----------
From: Curtis Rueden <ctrueden at wisc.edu>
Date: Tue, May 12, 2009 at 5:01 PM
Subject: Bio-Formats in ITK (was: Re: [Insight-users] ITK for fluorescence
microscopy - BioImageXD)
To: Lassi Paavolainen <lopaavol at jyu.fi>, alex gouaillard <
Alexandre_Gouaillard at hms.harvard.edu>, BioImageXD devel <
bioimagexd-devel at lists.sourceforge.net>, Mikolaj Olszewski <
Mikolaj.Olszewski at abo.fi>, ITK <insight-users at itk.org>, Joacim Päivärinne <
jopaivar at abo.fi>, Daniel James White <white at mpi-cbg.de>
Cc: Bio-Formats <bioformats at loci.wisc.edu>, Jason Swedlow <
jason at lifesci.dundee.ac.uk>, Josh Moore <josh at glencoesoftware.com>, Chris
Allan <callan at glencoesoftware.com>, Jean-Marie Burel <j.burel at dundee.ac.uk>


Hi everyone,

Quite a crowd we've got here. :-)

You guys have covered a lot of ground so I divided my comments into several
topics.

----------
BIO-FORMATS IN ITK

On Tue, May 12, 2009 at 6:38 AM, alex gouaillard <
Alexandre_Gouaillard at hms.harvard.edu> wrote:

> curtis any news on the wrapping (in C++) and using the IO mechanism in ITK?
> More specifically, anything we could do to help you?
>

Yes!

The C++ bindings are completely functional on Windows (with Visual C++), and
Mac OS X and Linux (with gcc).

The ITK plugin is functional on Mac OS X and Linux, but I hit a roadblock on
Windows.

For the past month or so I have been swamped with other projects and have
not had time to investigate further. If anyone on this list wants to try the
C++ bindings and the ITK plugin themselves, I would be extremely
appreciative.
  * If you are a scientist who needs to access life sciences data within
ITK, the plugin is likely to be useful as-is.
  * If you are a C++ software developer, I come from a primarily Java
background and have no prior experience with CMake, so I would highly value
any improvements or "best practices" fixes to my build system.

You can check out the code from our SVN repository:
  https://skyking.microscopy.wisc.edu/svn/java/trunk/

The Bio-Formats C++ bindings are located in the components/native/bf-cpp
subtree.

The Bio-Formats ITK plugin is located in the components/native/itk-plugin
subtree.

You can find my directions for building these components in the respective
readme files, available online at:

https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme.txt

https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-windows.txt

https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-macosx.txt

https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-linux.txt

https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/itk-plugin/readme.txt

Please do not hesitate to contact me with any questions or problems. I need
your help to finish up this project!

On Tue, May 12, 2009 at 7:40 AM, alex gouaillard <
Alexandre_Gouaillard at hms.harvard.edu> wrote:

> I agree that writing and maintaining readers is hard. I agree that we
> should collaborate as much as possible in that matter, and in both our
> cases, (well in any case that involves microscopy datasets i guess) using
> bio formats makes a lot of sense.
>

Agreed, of course. But I might be a little biased. ;-)

As bio format is written in Java, we made it difficult for us to leverage
> it. We ended up in a situation where most of the image processing algorithms
> we were interested in are in ITK (C++), most of the visualization is in VTK
> (C++), and most of the readers in Bio-formats (java).
>

Hopefully my recent work will make collaboration easier.

On Tue, May 12, 2009 at 5:31 AM, Badri Roysam <roysam at ecse.rpi.edu> wrote:

> The LOCI Bio-Formats library that you mentioned has been wrapped
> for Python access and is being interfaced with ITK by LOCI. They are part
> of the
> farsight project team, by the way.
>

There are three separate layers of integration being talked about here:

1) What Badri mentioned is a Python interface to some of the Bio-Formats
command line tools. Essentially, this is Python making system calls to shell
scripts (batch files on Windows) to perform some common tasks. I believe
this work was done by Isaac Abbott of Badri's team, and demoed recently at
the Janelia Farm BioImage Informatics conference.

2) What I have been working on is a full set of C++ bindings into the
Bio-Formats API. (This is the "bf-cpp" module mentioned above.) This allows
developers to write C++ code calling Bio-Formats nearly identically to how
it would be done in Java. E.g.:

      ImageReader reader;
      reader.setId(id);
      int w = reader.getSizeX();
      int h = reader.getSizeY();
      cout << "Image planes are " << w << " x " << h << endl;
      reader.openBytes(0);
      //etc.

3) I have also leveraged the bindings from #2 to create an ITK ImageIO
plugin for reading life sciences file formats into ITK image structures.
(This is the "itk-plugin" module mentioned above.)

----------
OME-TIFF FILE FORMAT

On Tue, May 12, 2009 at 7:49 AM, Badri Roysam <roysam at ecse.rpi.edu> wrote:

> While we are on this topic, there is an aspect of BioFormats & OME that is
> worth thinking
> about. This is the OME-TIFF format. Basically, all the microscope metadata
> is saved in
> a microscope-independent format as a XML file within the TIFF file's text
> field. I
> believe this to be a valuable capability, since we often need to access
> metadata. At the
> very least, we need voxel size along x, y, and z axes.
>

I agree with Badri that adding support for OME-TIFF where possible will
foster interoperability. Hopefully the Bio-Formats ITK support will enable
further use of OME-TIFF, though there is still work to be done on data
export, and metadata integration.

----------
PYTHON VERSUS JAVA VERSUS C++

On Tue, May 12, 2009 at 7:07 AM, Daniel James White <white at mpi-cbg.de>wrote:

> wxPython  (for out GUI) only works with Carbon on OSX,
> and the native wxAqua port of wxWindows/Widgets is nowhere near production
> ready...
>
> so with wxPython on OSX we are stuck with 32 bit,
> unless we make the effort to bring wxAqua up to scratch,
> and thats a big job.
>
> Switching to java might be easier and also have other long term benefits,
> as you allude to.


I was unaware wxPython is such a problem across multiple platforms. My
impression has been that Python is slowly going to replace Java, as it is
somewhat higher level, and higher-level languages have tended to replace
lower-level ones over time.

That said, Java is a fine choice, with many advantages. Combined with
WrapITK, Bio-Formats and ImageJ, you've got a lot of nice tools at your
disposal.

2009/5/12 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>

> In my opinion, java is better for applications like BXD.
> Python is better for quick development and prototyping, but for middle to
> big applications, I'd choose java, at least because it's possible to catch
> many mistakes at build time.
>

Replies the scripting languages devotee: "That's what unit tests are for."

Compiled languages versus scripting languages -- the eternal struggle! :-)

On Tue, May 12, 2009 at 8:11 AM, Lassi Paavolainen <lopaavol at jyu.fi> wrote:

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

At the risk of receiving a lot of hate from some of you, I find C++ far
harder to use productively than Java. To be fair, much of that is that I
have been writing Java software for 12 years now. But C++:

  * has the annoying Visual C++/gcc compiler dichotomy
  * generally has more cryptic error and warning messages
  * lacks "write once, run anywhere" so you have to recompile stuff in more
situations
  * lacks many standard library features (Boost is awesome, but it's still
no Java standard library)

As one small example among many, I got burned by the need to explicitly
export symbols with Windows DLLs (whereas it exports everything by default
with gcc). Completely subjectively, I think Java has fewer weird gotchas
like that.

All of that said, a lot of stuff makes the most sense to do in C++ because
ITK/VTK/QT/etc. are fully established in C++. It would be crazy to language
translate all that infrastructure without a very good reason. And WrapITK
solves most such use cases anyway.

----------
GPL LICENSING

On Mon, May 11, 2009 at 9:40 AM, alex gouaillard <
Alexandre_Gouaillard at hms.harvard.edu> wrote:

> Let's say I want to distribute my code under BSD. We could find many
> reasons for that, first to give complete freedom to anybody to use it the
> way they want. Second if one day we want to make compony on too of it (just
> like 100ximaging is doing now with their original project), or for
> transferring to ITK / VTK later.
>

As long as you retain the copyright on your own code, you can start a
company later using it as a foundation, regardless of your prior license.
That is, releasing your code under a particular license in no way restricts
your own rights to your software.

In addition, many companies (e.g., ZeroC -- see
http://zeroc.com/licensing.html) have found that GPL lends itself very well
to corporate use. It allows the company's code to be free with respect to
open source, academia, etc., while requiring companies with closed source
products to pay for the ability to leverage the software, since the GPL
forbids distribution of your code with closed source products. With BSD,
other companies could incorporate your code without paying you anything,
leaving you with a purely support-based business model.

If I read GPL code and then write a code (anytime in the future) that does
> the equivalent work, I can never claim to be 100% independent  of /
> uninspired by the GPL code, and thus, the contamination process start, my
> code must be GPL. two comments here, of course, this is only the case if
> someone sue you, but you never know. Also it would legal for one individual
> to read the GPL code, write down the algorithm on a sheet of paper, then
> pass it over to another individual that never read the code and would
> implement the algorithm from the drawing / diagram on the paper. This is
> legal, but a lot of work.
>
> So I could read the code, but then, I woudl make my life seriously more
> complicated :-)
>

I think this attitude is a bit paranoid. There is always a risk of being
sued, even if you just see a GPL program's output -- or even if you never
do. Under current U.S. patent law, if you reimplement a patented algorithm,
even if you had the idea completely independently, you can still be in legal
trouble. As you say, it really boils down to who is going to sue you for
what.

----------
OME USERS MEETING IN PARIS

2009/5/12 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>

> And I'll be in OME user meeting next week. A small world…
>

Great, I look forward to seeing you there!

On Tue, May 12, 2009 at 6:38 AM, alex gouaillard <
Alexandre_Gouaillard at hms.harvard.edu> wrote:

> I'm also leaving tonight for Paris, and should see gaethan all day
> wednesday. We have scheduled to work on supporting more classes in the
> wrapping process. Even though we are not using wrapping ourselves, it's a
> nice way to catch problems, and to improve quality of the class wrapped.
>

Are you also attending the OME users meeting, Alex?

-Curtis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090512/9d54e467/attachment-0001.htm>

More information about the Insight-users mailing list