Thumbnail sizes

[Chris Wilkinson]

Hi all,

We're looking at adopting IIIF on elifesciences.org (currently just the Image API, though probably Presentation in the future). We'd quite like to use the image URI syntax everywhere as it allows our data sources to be nicely decoupled from their presentation (so our backends don't have to know that an image appears as 140x140 and 500x280 thumbnails, nor that these are double sized for retina screens).

It appears, though, that there's no way of getting such a thumbnail without explicitly requesting a region and size (we need to guarantee that size, so it's going to be a crop+scale of the image). This means that the client has to provided information about the image to be able to construct the request (we're just using a focal point so it uses the original width/height and focal point x/y to work out a region, but it could be derived from something more complicated like http://universalimages.github.io/rmd/). It seems like the 'square' region is close to what I'm after (it might be appropriate for the square to be smaller than both dimensions of the image if the requested size is quite small, but by just using focal points we probably won't achieve this), but is obviously restricted to squares. Thumbnails in the presentation API look possible (note I'm not hugely familiar with this spec yet), but would presumably have to be separate resources at specified aspect ratios (and so isn't as flexible and is more involved).

In ideal world I would be able to request something like  /abcd1234/thumb/500,280/0/default.jpg, which resolves as a thumbnail at a size of 500x280. As to what the real region used is up to the server (I suspect this might be considered out of scope for the Image API).

Is there a recommended approach for this? Are there any examples of anyone doing something similar?

This isn't a blocker for our work, as we can let the client compute a region to request at least for the moment. (We just have to allow for arbitrary region requests, and provide extra details about the image to our clients.)

Thanks,

Chris

[Adams, Chris]

Some prior art: some image servers like Thumbor try to avoid the need to pre-select crop boxes by using computer vision techniques like face or feature detection to center a crop on an area of the image which is likely to be interesting:

https://github.com/thumbor/thumbor/wiki/Detection-algorithms

Thumbor does not support IIIF (https://github.com/thumbor/thumbor/issues/684) but if memory serves you can actually use the REST API to identify a possible region of interest within an image and get a JSON response back rather than the actual cropped image.

It might be useful to have a separate service so you could keep the core interface using standard IIIF but have a service which could generate the IIIF URLs and cache them, with the possibility of human overrides where necessary. This approach works great for things like photographs but since things like newspapers don't really have much of interest there's an argument for a content type aware service which could simply have reasonable defaults for those items.

Chris

[David Newbury]

There's no way to do this explicitly within the  base IIIF Image API, but IIIF also says

To allow for extensions, this specification does not define the server behavior when it receives requests that do not match either the base URI or one of the described URI syntaxes below. 

- http://iiif.io/api/image/2.1/#uri-syntax

so you could just use your example URI and put custom logic in your server to do so. 

I also think this is a good place where a IIIF service might be useful—if you could define a JSON-LD structure that describes your preferred thumbnail, you could put that in the Related Services section, and then your clients, if they dereference that info.json, could know what the preferred thumbnail might be.  I've played with this for palettes:  http://palette.davidnewbury.com, but I could see it being cool for thumbnails, too—as Chris suggested, you could even just use the Thumbor syntax.

Thumbnails in the Presentation API are definitely a possibility, but I don't think they will resolve this, other than allowing you to save a default URI, but hardcoding that in might not be a great idea, because of Retina images and such.  But since I believe that you can can embed an Image API JSON-LD directly into the Presentation API, it could still use the IIIF service.

- David Newbury
-----------------------------------
p. (773) 547-2272
e. david....@gmail.com

Chris

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Casties]

You could of course get a distorted thumbnail with

/abcd1234/square/500,280/0/default.jpg :-)

I don't think that we should reinterpret the !-syntax to mean something
else in the case of square areas so that

/abcd1234/square/!500,280/0/default.jpg

would give you 500x280 and not 280x280...

So maybe we need a new character to mean that ;-)

I have just implemented a feature like that in our digilib server,
planning to use it for the IIIF 'square' feature. I was only thinking of
the square thumbnail usecase and not of non-square thumbnails but in the
(completely different) digilib API it would work like you wanted.

> Is there a recommended approach for this? Are there any examples of anyone
> doing something similar?

You could try to use the square thumbnail and pare it down via CSS or
use your own private region name as people have done before the square
thumbnail as witnessed in

https://github.com/IIIF/iiif.io/issues/425


Cheers
Robert

[David Beaudet]

Would it be possible to write some kind of simple but fast proxy service, e.g. Perl in an FCGI wrapper, to intercept the /thumb path which could fetch the info.json for the image from the IIIF server, perform the necessary calculations, then fetch and return the bits for the resized image from the IIIF service?  That would be completely transparent to the client without requiring client-side calculations.

[Chris Wilkinson]

Thanks all.

We've investigated various options; we liked the look of Thumbor, and it seems to produce good results (based on the small sample we tried), but requires a new extension to support the IIIF URI schema (and would need an URI extension to support /thumb). Instead, we're implementing Loris (at least for now), and we're going to take the simplest option and calculate a region in the client based on the image width/height and focal point x/y (as we're looking to go live with this shortly).

I also like the idea of a /thumb path generally, but would rather not invent something just for ourselves (defaults the purpose of using IIIF a bit!). Assuming this isn't considered for the Image API spec, I wonder if a 'community extension' is possible, where a syntax could be agreed with any others interested in such functionality (the URI is one half, the other is possible information on how to crop (eg focal point details in the info.json), if it's not automatic).

Chris