A portable OpenSlide viewer for Windows: Smart Zoom Viewer

[jcupitt at gmail.com]

On 17 November 2015 at 03:33, rBenjamin Gilbert via openslide-users
<openslide-users at lists.andrew.cmu.edu> wrote:
> On 2015-11-12 12:49, John Cupitt via openslide-users wrote:
>> It's just deepzoom in an uncompressed zip container. The idea is that
>> deepzoom is great, because it can be served extremely quickly, but
>> also very annoying, since each 256x256 tile is a separate JPEG file.
>> If your slide is 100,000 x 100,000 pixels, your highest-resolution
>> directory will contain 150,000 files.
>
> So SZI is intended to hold a single pyramidal image with no metadata, rather
> than an entire slide?

There's a flag to dump all the metadata vips has into the zip as a
simple xml file, so it should have everything that's in the openslide
file.

> What advantages does this format have over pyramidal tiled TIFF?  I'm seeing
> a couple disadvantages:

I think the main advantages would be:

- More metadata, as much as openslide

Though I guess it would be missing the associated images. It would be
simple to add them as a subdirectory.

- Very simple interoperability with deepzoom

You can losslessly convert szi to and from deepzoom with a single
command using standard tools.

- Much smaller, simpler, faster server component

A szi tile server is as fast or faster than serving static files from
the filesystem. It's so simple to serve you can easily do it in php or
c#, there's no need for a C/C++ server add-on (important in a Windows
environment). I think there are even standard server add-ons you can
use to serve from a zip container.

A tiff tile server can get very slow, relatively, if you want to
support things like deepzoom overlaps. You will have to decompress and
recompress tiles, which will have a horrific effect on performance.

- More control over jpeg encoding

libtiff gives very few controls, just Q I think, whereas if you encode
the jpg yourself you can adjust things like chrominance subsampling.

> - File size.  I used VIPS d88304a2 to make an SZI file and a TIFF file like
> this:
> TIFF:
>   869.7 MB - Total size
> ZIP:
>  1093.8 MB - Total size

That's a good analysis. You can knock the size of the zip down a bit
if you don't attach exif metadata to each tile, but you're right, the
zip will probably be about 20% larger. That's still much smaller than
a conventional deepzoom directory tree.

> - From an interoperability perspective, ZIP is not ideal.  The spec is
> large, occasionally ambiguous, and has many optional features.  For SZI to
> be well-defined, a profile of ZIP would need to be specified.  (E.g., is

I agree, it would be good to nail down some details like this.

John