Precipoint VMIC driver and DeepZoom

[Benjamin Gilbert]

On Mon, Jun 27, 2016 at 03:16:49PM +0200, Markus Pöpping via openslide-users wrote:
> I have written a driver for the Precipoint VMIC slide format, which
> already does a fairly good job in processing any existing VMIC files.
> [...]
> The driver is a single file for testing purposes; before committing it
> is planned to move all functions, which are good for common use, to
> openslide-decode-xxx

Hi Markus,

Thanks for working on this!  You probably already plan to do this, but
before submitting the driver, please try to make it as readable as possible:
fix up indentation and function ordering to match the other drivers, fix the
brace style and line lengths, remove commented code, use commented-out
g_debug() calls for debug messages, etc.

> 1. DeepZoom: VMIC is very closely related to DeepZoom. Therefore I
> believe it makes sense to implement "Generic DeepZoom in a zip archive"
> (such as SZI, DZZ) and "Generic DeepZoom in a directory tree", together
> with this. Is there any interest in the community for me to write the
> generic driver, too ?

Thus far, OpenSlide has only supported file formats which are actually
produced by slide scanners.  For example, we support generic TIFF images and
would like to support generic JPEG 2000, but we haven't added support for
Deep Zoom, Google Maps images, or Zoomify.  I'd be inclined to continue that
policy in order to limit the scope of the library (since whole-slide images
may have different requirements than other types of zoomable images), but
could possibly be convinced otherwise.

> Can anyone who uses such files point me to some examples ?

A lot of folks produce such files with VIPS (e.g. "vips dzsave").

> 2. libcairo: Can someone who is experienced with libcairo please check
> the code from line 933 to 949 ?

The Cairo surface is pre-filled with transparent pixels.  If there's nothing
to paint, you don't need to paint anything; you can just return early.

Lines 939-949 are fine.

> 3. zip: Are there known other slide formats that use ZIP containers ?

I'm not aware of any.

> I found, libzip is fast and easy to use, and though it's generally not
> thread-safe, a mutex can fix this.

The existing drivers re-open their data files on every
openslide_read_region().  That avoids this kind of thread-safety issue
(provided that libzip doesn't have any global state) and also prevents an
idle openslide_t from consuming file handles.  If creating a ZIP handle is
expensive, you can use a handle cache + your own zip_source, similar to the
approach used by _openslide_tiffcache.

> So far, I have not worked with libgsf.  Can it handle nested zip archives,
> too ?

It doesn't appear to.

> From my PoV, the only reason for switching to libgsf I can think of is
> that libgsf capabilities other than "zip" are needed by future openslide
> drivers.  Also, the binary of libgsf is much larger.  Any educated input
> on this ?

libgsf would be useful for Zeiss ZVI, but I don't think ZVI support is a
priority.  Given the need for nested ZIPs, libzip seems reasonable.

> Overlaps other than "0" are untested yet.  These specs are enough for
> VMIC, they are always jpeg and don't overlap.

I'd prefer not to add unused functionality.  If we don't end up supporting
generic Deep Zoom, and if there are Deep Zoom features which are not used by
VMIC, you can just check for unsupported parameters and fail if present. 
(Would that allow you to switch to the simple grid?)

> DeepZoom pyramids are cut off below the largest level that consist of a
> single tile, so the list of levels doesn't get unnecessary long.

On balance, I think that's the right approach.

> Detection:
> 
>   The file is a ZIP.
>   Among the first 20 entries, there exists a file which either starts
> with "Image" or ends with ".vmici", AND is a zip archive.
>   [To make this fast, at this point detection is flagged "positive" as
> soon as the inner Image/.vmici container has been found and has the
> magic bytes "PK34". The inner container is not opened or checked,
> because it would take very long.]

What are VMIC's exact rules on the name of the inner archive?  All three
sample files use a filename of exactly "Image.vmici".  If the name check
could be restricted further (in particular, if the .vmici extension is
always present), it might be reasonable to drop the check for the inner ZIP
magic number.

--Benjamin Gilbert