Deepzoom with non-pyramidal tiled TIFF

[MyleneSimon]

Using the Deepzoom protocol with a tiled TIFF (non-pyramidal) seems to result in incorrect tiles being sent by IIP. Same requests to a pyramidal version of the same image result in correct tiles.

For example, request collections/stitched_c02t089-tiled.ome.tif&CNT=-1&DeepZoom=collections/stitched_c02t089-tiled.ome.tif_files/10/0_0.jpg will return the following (tiled TIFF - incorrect result):

Request collections/stitched_c02t089-tiled-pyr.ome.tif&CNT=-1&DeepZoom=collections/stitched_c02t089-tiled-pyr.ome.tif_files/10/0_0.jpg will return the following (pyramidal tiled TIFF - correct result):

We don't see this issue if we use IIIF, only with Deepzoom (but we want to be able to use the contrast adjustment and are using OpenSeadragon, so Deepzoom seemed like a good option).

[ruven]

Your TIFFs really need to be in multi-resolution pyramid form for use with IIPImage. Is there any reason why your images are not in pyramid form? I notice that your images have "ome" in their names: the latest IIPImage release supports the tiled pyramid OME-TIFF format if you want to use that.

So, why does it work for IIIF and not for Deepzoom. The Deepzoom syntax has requests that can be directly mapped to the underlying pyramid tiled structure and that's exactly what IIPImage does. If you ask for a resolution that doesn't exist, the server will "correct" your request and give you tiles from the nearest existing resolution. OpenSeaDragon's Deepzoom implementation doesn't check whether all the resolutions are in fact available and so makes requests for non-existent levels, thereby giving a garbled view.

The IIIF syntax doesn't distinguish between tile and arbitrary region requests, so if the tile doesn't exist, IIPImage treats these as arbitrary regions and resizes the requests for you. This will, however, be very slow if your images are large.

So, you're best option is to transcode your images to tiled pyramid TIFF or OME-tiff. However, if you really want to use tiled images without multi-resolution pyramids, you can continue to use IIIF, but with the contrast adjustment "hack" you used for Deepzoom. Give a path like this to OpenSeaDragon's IIIF constructor:

/fcgi-bin/iipsrv.fcgi?FIF=collections/stitched_c02t089-tiled-pyr.ome.tif&CNT=-1&IIIF=collections/stitched_c02t089-tiled-pyr.ome.tif

PS: CNT=-1 does contrast stretching on the image

[MyleneSimon]

Thank you for the explanation, I understand the issue with DeepZoom in that case (although I am not sure how OpenSeadragon can know about the non-existant resolutions, since the dzi file generated is the same in both cases, maybe the server could have the option of returning 404 for non existing resolutions?).

Regarding image format, we are actually switching to tiled pyramid OME TIFF for new datasets (and recently upgraded our test IIP instance to the latest version - working great!), but we have existing data (tiled OME TIFF) that we may not be able to convert for a variety of reasons, even if that means slower renderings.

Thanks for the IIIF tip, I had not realized we could use the IIP parameters like that in combination with the IIIF API, and that is actually exactly what we needed (a quick test with collections/stitched_c02t089-tiled.ome.tif&CNT=-1&IIIF=collections/stitched_c02t089-tiled.ome.tif/info.json in OpenSeadragon worked perfectly).

[ruven]

I am not sure how OpenSeadragon can know about the non-existant resolutions, since the dzi file generated is the same in both cases

The Deepzoom API requires a fixed number of resolutions - .the dzi metadata doesn't have any fields for specifying this. IIPImage could return 404 for non-existent resolutions rather than trying to "correct" your request - I'll look into it. Maybe it's indeed better to do this, though that wouldn't help in your particular case.

I had not realized we could use the IIP parameters like that

I didn't realize this worked for Deepzoom either! Normally you should just use
/fcgi-bin/iipsrv.fcgi?Deepzoom=image.tif without any FIF= prefix

[MyleneSimon]

I am not sure how OpenSeadragon can know about the non-existant resolutions, since the dzi file generated is the same in both cases

The Deepzoom API requires a fixed number of resolutions - .the dzi metadata doesn't have any fields for specifying this. IIPImage could return 404 for non-existent resolutions rather than trying to "correct" your request - I'll look into it. Maybe it's indeed better to do this, though that wouldn't help in your particular case.

I think 404 errors and/or a warning about that use case in the documentation would clarify that Deepzoom will not work properly without pyramids.

I had not realized we could use the IIP parameters like that

I didn't realize this worked for Deepzoom either! Normally you should just use /fcgi-bin/iipsrv.fcgi?Deepzoom=image.tif without any FIF= prefix

We played a bit with paths while testing out different clean URLs options (prefix => IIP) and Nginx prefix configurations, some of the combinations would not work properly for /prefix?Deepzoom=image.tif so we starting experimenting with /prefix/image.tif&Deepzoom=image.tif.dzi which then allowed for the IIP parameters to be added.

Now that we can use this workaround for adjusting contrast with IIIF, we will probably use that instead of Deepzoom, and that would take care of both our legacy tiled tiffs and new pyramidal tiffs.