Zeiss ZVI file format support development for OpenSlide
bgilbert at cs.cmu.edu
Wed Jul 18 18:57:57 EDT 2012
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
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.
More information about the openslide-users