Precipoint VMIC driver and DeepZoom

[Markus Pöpping]

Dear Benjamin, dear OpenSlide community,

The VMIC driver appears to be ready for delivery.

Changes are: three new files
src/openslide-decode-zip.c
src/openslide-decode-zip.h
src/openslide-vendor-precipoint.c
Plus the necessary registration in openslide.c, openslide-private.h,
Makefile.am, configure.ac

Nothing else changed.

</now follows talk about coding details>

> 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.

Thanks for the checklist, it was indeed helpful for cleaning up the
code. I hope this is now good enough.

*) DeepZoom [...]

> [...]  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.
> 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?)

As for now, I have suspended work on generic DeepZoom. The notion to
move to a simple grid is valid. However, after very long pondering, I
left the strategic approach as is, first because it's been tested well,
and the performance is good enough. Secondly, I don't know if a simple
grid can be used because truncated tiles do appear in VMIC and general
DeepZoom on right and bottom borders. Thirdly, this also would require
specialized code paths for overlapping and non-overlapping DZ. I may
still consider simplifying this, but i just don't like delaying the
publishing any further.


*) zip

> 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.

The nefarious global GMutex has been removed, instead, the zip_t* handle
got wrapped by the _openslide_ziphandle structure, so we can have one
mutex for each instance of a zip archive. Also, there are now wrapper
functions for zip_open, zip_open_from_source, zip_close, zip_fopen and
zip_fclose. This is simpler than a handle cache and apparently enough to
allow multithreading. The only function of the GMutex
_openslide_ziphandle::lock is to prevent access to more than one file at
a time per zip archive. Reopening the zip for every image access would
of course be out of question. If libzip had any troublesome global
(non-archive-specific) state, -not that i spotted any - I believe this
would be a design flaw on their side and they ought to fix it.

The Windows build script has been extended to download and compile
libzip from the libzip home page http://www.nih.at/libzip

*) Title of Slide

The slide has a title, which can be found in vendor-specific property
"PreciPoint.ScanData.Name". As of now, the slide title is copied into
the "openslide.comment" tag. Is there a better place ? I cannot find any
property similar to "openslide.title" or "openslide.name".

*) Detection

> 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.

Basically, the inner archive is supposed to be named either
"Image.vmici", or, for older slides up to 2015, "Image".
Since we do want to support older slides, and the name "Image" is very
generic, I believe, dropping the check for the magic number is no good
idea, and I see no problem because the check is inexpensive.

Markus Pöpping

---------------------

Current detection rules for VMIC:

The file is a ZIP.
Inside the ZIP archive, a file named "Image" or "*.vmici" exists, AND is
a zip archive, tested via magic number.

--------------------