A portable OpenSlide viewer for Windows: Smart Zoom Viewer
bgilbert at cs.cmu.edu
Sun Dec 6 22:15:02 EST 2015
On Wed, Nov 18, 2015 at 08:44:48AM +0000, John Cupitt via openslide-users wrote:
> I agree, if you are doing server-side image processing then pyramidal
> tiff is a good storage format. As you say, szi is really for serving
> static images.
So SZI isn't intended as a primary storage/interchange format for
whole-slide images, then, but solely as a preprocessed format for Deep Zoom
tile servers? That makes a lot more sense: since any given installation is
a closed system (one writer producing data for one reader) the format can be
fairly ad-hoc, and it makes sense to reuse existing formats (Deep Zoom,
Zoomify, ZIP, OpenSlide properties). With those requirements I'd probably
choose a similar design.
On Tue, Nov 17, 2015 at 09:13:28AM +0000, John Cupitt via openslide-users wrote:
> 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.
True, I hadn't thought about overlaps. If overlaps were omitted you'd still
be able to serve tiles directly from the TIFF, and if you built an index
equivalent to your SZD it'd be equally cheap.
> libtiff gives very few controls, just Q I think, whereas if you encode
> the jpg yourself you can adjust things like chrominance subsampling.
AFAICT you could still do the encoding yourself and use TIFFWriteRawTile().
More information about the openslide-users