Zeiss ZVI file format support development for OpenSlide

[Benjamin Gilbert]

On 07/18/2012 03:29 AM, Alexandre Kharlamov wrote:
> Sure, I can try libgsf if you add it (or show me how to add it)
> to dependencies. I'm not very fluent with autoconf scripts yet.

Sure.  The Autotools changes are in the libgsf branch of 
<https://github.com/bgilbert/openslide>.  I have not updated CMake.

> Btw, can you please explain in detail, what functions I need to
> add (and what files) so that bitmap files can be converted to ARGB?

Detailed specifications are rare in open-source projects.  The typical 
procedure for contributing a new module goes something like this:

1.  Find the smallest existing module that's similar to what you're 
trying to do, and read it.

2.  Implement a module based on what you discover, consulting other 
existing code as needed.

3.  As soon as you have something that barely works, post it publicly 
for comment.  This is where you learn about all of the requirements you 
missed and the existing code you misunderstood.

4.  Improve your code and go to step 3.

Since this is an iterative process, it's important to post your code 
early rather than waiting until it's "done".

But why can't we just write some documentation?

Every non-trivial slide format (and ZVI is one of those) imposes new 
requirements on OpenSlide which require us to modify its architecture. 
We can't give you a precise set of instructions for integrating with 
OpenSlide, because OpenSlide may not provide the functionality you need! 
  So, as you approach your changes, you should be thinking of the entire 
library as within your purview, not just one vendor driver.  If the core 
needs to be changed (and it will!), send patches.

> I'm looking to use libnsbmp linked statically for loading bmp.
> It's basically two files libnsbmp.c and libnsbmp.h
> That library is only for reading bitmap files, and, unlike many others,
> it supports Run-Length-Encoded bitmaps.

We should try to select widely-used libraries whenever possible. 
libnsbmp is not packaged on Fedora and not actively maintained on 
Debian/Ubuntu, so the additional dependency would be problematic for 
packagers.  And the packaging policies of various Linux distributions 
prohibit us from building the library in our own source tree and 
statically linking it.

I propose gdk-pixbuf.  It's in the Gtk suite of libraries that we 
already use, and it adds no new transitive dependencies.  It also 
appears to support RLE.

> l propose this approach that does not require changes in API:
> Every single image in the file gets a level id, unless it's a part of
> mosaic.

No.  That's a hack.

ZVI support is going to require effort on several levels:

1.  The vendor driver,
2.  An ops backend for BMP-formatted images,
3.  API and backend changes to support multiple channels/timepoints.

And: since the JPEG ops backend assumes that a JPEG can be represented 
by a single filename/offset/length tuple, which is not true in ZVI, even 
point 1 will require you to make changes to the existing backend code.

We're not going to accomplish all of this in one step.  You should start 
by submitting a driver that returns three-channel color in the first 
focal plane at the first timesample.  If possible, you should support 
only JPEG-compressed ZVIs using the JPEG backend.

"But that's not useful!", you say.

Code is communication.  The easier it is for me to see that your changes 
are correct, the easier it will be for me to merge your code.  Each 
commit should do one, defensible, thing.

After you have integrated basic support for reading ZVI files, we can 
consider the next step.  You will then be in a better position to 
discuss what you need from the OpenSlide external and internal APIs.

--Benjamin Gilbert