[vtkusers] Bio-Formats integration with VTK/ITK

[Dan White]

Dear Curtis,

After wishing you a happy new year,
may I next applaud you for reinvigorating this discussion with your
well thought through message to the relevant lists.

Allow me to interject below where I have something constructive to say.

Begin forwarded message:
>
>
>
> * Support for these formats in BioImageXD (http:// 
> www.bioimagexd.net/),
> which I understand also uses ITK to read images.
>

Kalle and Lassi can correct me here, but I think we use VTK primarily,
then send data through the pipeline to ITK functions as required.
But the point is that it would be very cool if both ITK and VTK
could use bio-formats to read microscopy etc data.

>
> PRIOR DISCUSSION
>
> Back in July, Dan White briefly discussed a possible Bio-Formats  
> integration
> with VTK/ITK on the VTK mailing list:
>
> http://www.vtk.org/pipermail/vtkusers/2008-July/096253.html
> http://www.vtk.org/pipermail/vtkusers/2008-July/096255.html
> http://www.vtk.org/pipermail/vtkusers/2008-July/096276.html
> http://www.vtk.org/pipermail/vtkusers/2008-July/096278.html
> http://www.vtk.org/pipermail/vtkusers/2008-July/096280.html
> http://www.vtk.org/pipermail/vtkusers/2008-July/096286.html
> http://www.vtk.org/pipermail/vtkusers/2008-July/096287.html
> http://www.vtk.org/pipermail/vtkusers/2008-July/096291.html
>

Thanks for inspiring me to look back at what was said earlier.
I still agree with the points myself and others raised there,
and feel the these is still very relevant.

> ---
> LICENSING
>
> First, I want to address the licensing concern raised by Karthik  
> Krishnan
> regarding use of Bio-Formats within ITK/VTK: Bio-Formats is GPL,  
> while ITK
> and VTK are BSD. Unfortunately, this means that a combined ITK/VTK +
> Bio-Formats work becomes GPL -- in other words, Bio-Formats cannot be
> distributed with ITK/VTK under the BSD license.
>
> To be clear, LOCI and Glencoe Software strongly support open source
> software, including BSD-licensed software. Ideally, our wish is for
> Bio-Formats to be freely available for use with other open source  
> projects
> regardless of license. My concern is that a linking exception allowing
> Bio-Formats to be distributed with VTK/ITK (e.g., using the LGPL  
> instead of
> the GPL) would also allow a combined work to be expropriated for use  
> within
> proprietary software, sidestepping the GPL.
>
> One solution might be for ITK/VTK to provide a plugin infrastructure  
> for use
> by a Bio-Formats plugin module, which the end user would install  
> separately
> into ITK/VTK. We currently use this approach to provide a Bio- 
> Formats plugin
> for ImageJ even though ImageJ itself is public domain software.
>
> This approach is a somewhat gray area; see:
> http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
>
> The difference in this situation is that ITK/VTK is not a non-free  
> program,
> so the combined work would not violate the GPL, but it might be  
> "infected"
> by it.
>
> If anyone with a better understanding of open source licensing has  
> further
> thoughts or corrections on this issue, I would greatly appreciate it.
>

This issue needs to be dealt with sensibly, and by people who know  
what they are talking about (ire not Me!)
We have lawyers at the university of Turku that have helped us already  
(its their job)
and I assume kitware also have lawyers, as do, I imagine, Glencoe.

... but as I understand it, a plugin mechanism, or as we use in  
BioImageXD  an
"External VTK / ITK kit"
for the LSM reader we wrote and some other stuff,
would allow the project to progress unhindered by license problems,
as the GPL'd kit would not taint VTK / ITK with GPL ?
Or is that totally wrong.
Feel free to shout me down. I am no expert.


> ---
> METADATA
>
> Also discussed in the prior thread are issues of metadata  
> conversion, which
> I am willing to discuss but frankly would prefer to postpone until an
> initial integration is completed. Any C++ bindings for Bio-Formats  
> would
> include full access to its MetadataStore API, which would allow C++
> applications to manipulate OME-XML metadata.
>
> In response to the questions about OME-XML: the goal of the OME-XML  
> schema
> is to fully encapsulate the acquisition metadata from all supported
> microscopy formats, with regular (at least 2/year) releases to  
> continuously
> improve and update the schema. *The primary goal of Bio-Formats is to
> standardize proprietary metadata into this common data model.* So I  
> strongly
> agree with Dan that we want to preserve that standard whenever  
> possible. It
> would likely be possible to express the OME-XML schema as part of  
> the ITK
> metadata dictionary, though to be sure I would need to understand  
> more about
> how ITK models metadata.

Expressing the OME-XML schema as part of the ITK meta data dictionary  
sounds very sensible.
Reuse / mirroring  of the existing OME meta data handling work  in ITK  
sounds efficient.
(I am no programmer, so I barely understand what a dictionary is,
I only used them in python so far, so please excuse me if i sound like  
i have no idea about the practical details,
I don't)

>
>
> ---
> PERFORMANCE
>
> I have done a lot of research on time and space performance of Java  
> versus
> C++, as well as performance when integrating Java code with C++  
> through
> various means. Much of those results fall outside the scope of this  
> email,
> but suffice to say that Java's I/O performance is comparable to C++,  
> and
> Bio-Formats is mostly I/O-bound. Any observed speed difference in the
> Bio-Formats library compared to other implementations (e.g., Dan  
> points out
> that BioImageXD's LSM support is faster than reading an LSM file  
> into ImageJ
> using Bio-Formats) is most likely due to algorithm inefficiency in the
> Bio-Formats code rather than a relative deficiency in the language  
> itself.

The java folks around here (MPI-CBG) tell me that there are very few  
significant speed difference between the java VM and
native C++ code running the same kind of operations, so I suspect you  
are right on here.
So the point is to also work on bio-formats itself to improve  
performance,
and learn from other implementations for reading certain file types  
that seem fast.
>
>
> Regardless, I think our best bet is to interface the Bio-Formats  
> Java API
> with C++ in the most performant way available. Any solution more  
> involved
> than that, such as language translating Bio-Formats into C++, has  
> its own
> serious pitfalls, would require months of effort at best, and would be
> prohibitive for us to maintain. And less sophisticated solutions,  
> such as
> conversion of life sciences formats into the open OME-TIFF standard,  
> then
> reading the result into ITK, are not performant enough for many
> applications.


.... bearing in mind that many folks use VTK / ITK via wrappings for  
other languages.
Many use Java... so could use bio-formats easily on its own.
Others, like BioImageXD use python, or tcl...
so somehow the use of bio-formats would still need to work from
eg python wrapped VTK / ITK.
I dont understand the practical details of that, or even if it would  
be an issue at all...
again , please excuse my ignorance.

>
>
> ---
> QUESTIONS AND DISCUSSION
>
> My goal with this email is to kickstart some discussion about  
> integrating
> Bio-Formats with VTK/ITK. Specifically, my questions for the  
> community are:
>
> 1) Do others agree that this form of integration is a good idea? Or  
> is there
> a better way to accomplish the bulleted goals above?

yes, yes and thrice YES, it is a good idea.
I see no better way to accomplish the above.

>
>
> 2) I don't know much about ITK or VTK yet. Where is the right  
> integration
> point? Within ITK, accessible using ImageIOBase/ImageIOFactory? Or
> elsewhere? Does VTK/ITK have an appropriate plugin infrastructure?

External kits (see the bxdVTK kit in the BioImageXD source code) ???
>
>
> 3) Does anyone have experience using Jace cross-platform? Or does  
> anyone
> know an open source solution other than Jace for accessing Java API  
> from
> C++? Unfortunately, WrapITK & CableSwig go the other way -- wrapping  
> C++
> code for access from Java -- which is not what we want here.
>
> 4) Any thoughts on the GPL/BSD licensing issue?

see above.... I thin it should be possible, just need to be careful,  
and get the lawyers in early.
>
>
> This project is currently my top priority, but I am not a C++ expert  
> and I
> would greatly appreciate help from anyone in these various  
> communities.
> Thanks in advance for any comments and replies!
>

If I can help in any way I am able then I will!

cheers

Dan


Dr. Daniel James White BSc. (Hons.) PhD
Senior Microscopist / Image Processing and Analysis
Light Microscopy Facility
Max Planck Institute of Molecular Cell Biology and Genetics
Pfotenhauerstrasse 108
01307 DRESDEN
Germany


New Mobile Number!!!

+49 (0)15114966933 (German Mobile)
+49  (0)351 210 2627 (Work phone at MPI-CBG)
+49  (0)351 210 1078 (Fax MPI-CBG LMF)

http://www.bioimagexd.net
http://www.chalkie.org.uk
dan at chalkie.org.uk
( white at mpi-cbg.de )