Implementation of a CZI (Zeiss) driver

[Benjamin Gilbert]

On 06/12/2014 11:08 AM, BALBASTRE Yael 237482 Thésard wrote:
> A file contains several subblocks, each containing a subimage which
> can be compressed (jpeg or jpegXR mainly) or not, as well as metadata
> stored in the file as xml blocks.

Is JPEG XR often used in these files?  Are other image formats supported 
besides JPEG and JPEG XR?

> I am not comfortable with having all of it in a single
> openslide-zeiss-vendor.c source, especially since it would deal both
> with file stream reading (decoding of the hard
> directories/subblocks/attachments structure) and with more
> high-level, microscopy-related treatment (metadata, grid-building,
> subimages decoding...).

It's a valid concern.  OpenSlide tends to have fewer, large modules 
rather than many smaller ones, and this has benefits and drawbacks.  One 
benefit is that individual source files only expose symbols that are 
useful to the library as a whole [*], and not internal implementation 
details.  It does lead to cases like the Hamamatsu driver, which has 
support for three formats in a single source file.  (I've never been 
entirely comfortable with that, but they *are* all the same vendor, and 
they do share code.)

* Exceptions: openslide-tables, which is generated at build time, and 
openslide-jdatasrc, which is copied verbatim from libjpeg.

We may want to reconsider this layout at some point, but I don't think 
it's causing us real pain yet.  You can (and should) still create a 
clean internal API within the single source file.  (MIRAX does not do 
this.)  If we restructure the code later on, that will make it easy to 
move the container parsing into a separate file.

--Benjamin Gilbert