Message bounced due to "too many recipients" -- sending to one mailing list at a time. :-)<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Curtis Rueden</b> <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu">ctrueden@wisc.edu</a>></span><br>
Date: Tue, May 12, 2009 at 5:01 PM<br>Subject: Bio-Formats in ITK (was: Re: [Insight-users] ITK for fluorescence microscopy - BioImageXD)<br>To: Lassi Paavolainen <<a href="mailto:lopaavol@jyu.fi">lopaavol@jyu.fi</a>>, alex gouaillard <<a href="mailto:Alexandre_Gouaillard@hms.harvard.edu">Alexandre_Gouaillard@hms.harvard.edu</a>>, BioImageXD devel <<a href="mailto:bioimagexd-devel@lists.sourceforge.net">bioimagexd-devel@lists.sourceforge.net</a>>, Mikolaj Olszewski <<a href="mailto:Mikolaj.Olszewski@abo.fi">Mikolaj.Olszewski@abo.fi</a>>, ITK <<a href="mailto:insight-users@itk.org">insight-users@itk.org</a>>, Joacim Päivärinne <<a href="mailto:jopaivar@abo.fi">jopaivar@abo.fi</a>>, Daniel James White <<a href="mailto:white@mpi-cbg.de">white@mpi-cbg.de</a>><br>
Cc: Bio-Formats <<a href="mailto:bioformats@loci.wisc.edu">bioformats@loci.wisc.edu</a>>, Jason Swedlow <<a href="mailto:jason@lifesci.dundee.ac.uk">jason@lifesci.dundee.ac.uk</a>>, Josh Moore <<a href="mailto:josh@glencoesoftware.com">josh@glencoesoftware.com</a>>, Chris Allan <<a href="mailto:callan@glencoesoftware.com">callan@glencoesoftware.com</a>>, Jean-Marie Burel <<a href="mailto:j.burel@dundee.ac.uk">j.burel@dundee.ac.uk</a>><br>
<br><br>Hi everyone,<br>
<br>Quite a crowd we've got here. :-)<br><br>You guys have covered a lot of ground so I divided my comments into several topics.<br><br>----------<br>BIO-FORMATS IN ITK<br><br><div class="gmail_quote">On Tue, May 12, 2009 at 6:38 AM, alex gouaillard <span dir="ltr"><<a href="mailto:Alexandre_Gouaillard@hms.harvard.edu" target="_blank">Alexandre_Gouaillard@hms.harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">curtis any news on the wrapping (in
C++) and using the IO mechanism in ITK? More specifically, anything we
could do to help you?<br>
</blockquote><div><br>Yes!<br><br>The C++ bindings are completely functional on Windows (with Visual C++), and Mac OS X and Linux (with gcc).<br><br>The ITK plugin is functional on Mac OS X and Linux, but I hit a roadblock on Windows.<br>
<br>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.<br>
* If you are a scientist who needs to access life sciences data within ITK, the plugin is likely to be useful as-is.<br> * 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.<br>
<br>You can check out the code from our SVN repository:<br> <a href="https://skyking.microscopy.wisc.edu/svn/java/trunk/" target="_blank">https://skyking.microscopy.wisc.edu/svn/java/trunk/</a><br><br>The Bio-Formats C++ bindings are located in the components/native/bf-cpp subtree.<br>
<br>The Bio-Formats ITK plugin is located in the components/native/itk-plugin subtree.<br><br>You can find my directions for building these components in the respective readme files, available online at:<br> <a href="https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme.txt" target="_blank">https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme.txt</a><br>
<a href="https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-windows.txt" target="_blank">https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-windows.txt</a><br>
<a href="https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-macosx.txt" target="_blank">https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-macosx.txt</a><br>
<a href="https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-linux.txt" target="_blank">https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/bf-cpp/readme-linux.txt</a><br>
<a href="https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/itk-plugin/readme.txt" target="_blank">https://skyking.microscopy.wisc.edu/trac/java/browser/trunk/components/native/itk-plugin/readme.txt</a><br>
<br>Please do not hesitate to contact me with any questions or problems. I need your help to finish up this project!<br><br></div></div><div class="gmail_quote">On Tue, May 12, 2009 at 7:40 AM, alex gouaillard <span dir="ltr"><<a href="mailto:Alexandre_Gouaillard@hms.harvard.edu" target="_blank">Alexandre_Gouaillard@hms.harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote><div><br>Agreed, of course. But I might be a little biased. ;-)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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).<br>
</blockquote></div><br>
Hopefully my recent work will make collaboration easier.<br>
<br><div class="gmail_quote">On Tue, May 12, 2009 at 5:31 AM, Badri Roysam <span dir="ltr"><<a href="mailto:roysam@ecse.rpi.edu" target="_blank">roysam@ecse.rpi.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The LOCI Bio-Formats library that you mentioned has been wrapped<br>
for Python access and is being interfaced with ITK by LOCI. They are part of the<br>
farsight project team, by the way.<br></blockquote></div>
<br>
There are three separate layers of integration being talked about here:<br><br>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.<br>
<br>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.:<br>
<br> ImageReader reader;<br> reader.setId(id);<br> int w = reader.getSizeX();<br> int h = reader.getSizeY();<br> cout << "Image planes are " << w << " x " << h << endl;<br>
reader.openBytes(0);<br> //etc.<br><br>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.)<br>
<br>----------<br>OME-TIFF FILE FORMAT<br>
<br>
<div class="gmail_quote">On Tue, May 12, 2009 at 7:49 AM, Badri Roysam <span dir="ltr"><<a href="mailto:roysam@ecse.rpi.edu" target="_blank">roysam@ecse.rpi.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
While we are on this topic, there is an aspect of BioFormats & OME that is worth thinking<br>
about. This is the OME-TIFF format. Basically, all the microscope metadata is saved in<br>
a microscope-independent format as a XML file within the TIFF file's text field. I<br>
believe this to be a valuable capability, since we often need to access metadata. At the<br>
very least, we need voxel size along x, y, and z axes.<br></blockquote></div>
<br>
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.<br>
<br>----------<br>PYTHON VERSUS JAVA VERSUS C++<br><br>On Tue, May 12, 2009 at 7:07 AM, Daniel James White <span dir="ltr"><<a href="mailto:white@mpi-cbg.de" target="_blank">white@mpi-cbg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
wxPython (for out GUI) only works with Carbon on OSX,<br>
and the native wxAqua port of wxWindows/Widgets is nowhere near production ready...<br>
<br>
so with wxPython on OSX we are stuck with 32 bit,<br>
unless we make the effort to bring wxAqua up to scratch,<br>
and thats a big job.<br>
<br>
Switching to java might be easier and also have other long term benefits,<br>
as you allude to.</blockquote><div><br><div>
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.<br>
<br>
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.<br>
</div><br></div>
<div class="gmail_quote">2009/5/12 Gaëtan Lehmann <span dir="ltr"><<a href="mailto:gaetan.lehmann@jouy.inra.fr" target="_blank">gaetan.lehmann@jouy.inra.fr</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In my opinion, java is better for applications like BXD.<br>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.<br>
</blockquote></div>
<br>Replies the scripting languages devotee: "That's what unit tests are for."<br>
<br>Compiled languages versus scripting languages -- the eternal struggle! :-)<br>
<br><div class="gmail_quote">On Tue, May 12, 2009 at 8:11 AM, Lassi Paavolainen <span dir="ltr"><<a href="mailto:lopaavol@jyu.fi" target="_blank">lopaavol@jyu.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
Again, I'm sure you have your own reasons, andthat it is a naive question. I'm just curious.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
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.<br><font color="#888888">
</font></blockquote></div><br>
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++:<br><br> * has the annoying Visual C++/gcc compiler dichotomy<br>
* generally has more cryptic error and warning messages<br> * lacks "write once, run anywhere" so you have to recompile stuff in more situations<br> * lacks many standard library features (Boost is awesome, but it's still no Java standard library)<br>
<br>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.<br>
<br>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.<br>
<br>----------<br>GPL LICENSING<br><br><div class="gmail_quote">On Mon, May 11, 2009 at 9:40 AM, alex gouaillard <span dir="ltr"><<a href="mailto:Alexandre_Gouaillard@hms.harvard.edu" target="_blank">Alexandre_Gouaillard@hms.harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
</blockquote><div><br>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.<br>
<br>In addition, many companies (e.g., ZeroC -- see <a href="http://zeroc.com/licensing.html" target="_blank">http://zeroc.com/licensing.html</a>) 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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
So I could read the code, but then, I woudl make my life seriously more complicated :-)<br></blockquote></div><br>
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.<br>
<br>----------<br>OME USERS MEETING IN PARIS<br>
<br>
<div class="gmail_quote">2009/5/12 Gaëtan Lehmann <span dir="ltr"><<a href="mailto:gaetan.lehmann@jouy.inra.fr" target="_blank">gaetan.lehmann@jouy.inra.fr</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And I'll be in OME user meeting next week. A small world…<br>
</blockquote></div>
<br>
Great, I look forward to seeing you there!<br>
<br>On Tue, May 12, 2009 at 6:38 AM, alex gouaillard <span dir="ltr"><<a href="mailto:Alexandre_Gouaillard@hms.harvard.edu" target="_blank">Alexandre_Gouaillard@hms.harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br><font color="#888888">
</font></blockquote>
<br>Are you also attending the OME users meeting, Alex?<br><font color="#888888"><br>-Curtis<br><br>
</font></div><br>