How to generate operations list hash from URL?

[antbrown]

Hi,

A bit of background: We have a client with thousands of ~1GB tiled images they want to make available through an IIIF viewer (Open SeaDragon), however it takes a fairly long time to generate images on the fly for first time visitors.

We have implemented a rough way of generating a list of tile urls (using https://iiif.io/api/image/2.1/#a-implementation-notes as a guide) and we make an http request for each of the tiles before the item is published, thus hopefully warming up the cache.

Unfortunately this doesn't always go to plan, sometimes half the tiles are generated, sometimes none at all, we suspect it is the load we're putting Cantaloupe under. We would like a way to inspect on disk (under /var/cache/cantaloupe/image) which tiles have been generated for each of our tiffs. We can do the first part fine, turn the identifier of the image into a hash (I learned that from #399), but I still don't know how to turn the remaining part of the url (the operations list) into a hash that matches what is on disk.

Is it possible to do, or is it a hash of the internal Java object and we wouldn't be able to reverse engineer it?

This is kind of related to the discussion at #508, but is more a specific question about operation list hashes, so I thought I'd keep it separate.

Many thanks for your time.

[adolski]

Hi @antbrown,

The operation list hash isn't really easy to figure out, so I wouldn't try to go down that road. Instead I would look into, first, whether it is possible to avoid pre-warming the cache (are the source images encoded in an ideal format for Cantaloupe to deliver?) and second, why are only half or none of the derivatives getting generated? That doesn't sound right. If your pre-warming tool is requesting 10 tiles, and getting 10 tiles back from the image server, but <10 tiles end up in the cache, that is definitely not right. More information would be needed as to what is going on there.

[antbrown]

Hi @adolski thanks for your reply.

That certainly clears up whether we should proceed down the road of trying to reverse engineer the operations list hashes, sounds difficult.

I think we're hitting limits on the server making the requests rather than it being a Cantaloupe issue generating tiles, we will need to batch the requests more efficiently I suspect.

In regards to ensuring the source images are encoded in an ideal format, is it possible to convert tiffs after they've been created, or do we need to go back to the client and ask that they create them in a different format? Unsure if you can tell anything from the following tiffinfo output, but this is an example of what we're dealing with.

TIFF Directory at offset 0x8 (8)
  Subfile Type: (0 = 0x0)
  Image Width: 16554 Image Length: 5130
  Resolution: 1437.01, 1437.01 pixels/cm
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 3
  Rows/Strip: 5130
  Planar Configuration: single image plane
  ImageDescription: Make: Lanovia. Model: C-550.

Cheers,
Ant

[adolski]

The rows/strip line indicates that this is a striped TIFF, which is going to perform very terribly in Cantaloupe. There is some information about this in the manual.

It is certainly possible to convert a TIFF into another TIFF, and the conversion should be lossless as long as the source TIFF uses no or lossless compression. See for example: https://iipimage.sourceforge.io/documentation/images/

[antbrown]

Perfect thank you, sorry for my late reply.