Use explicit thumbnail resource when specified

[tomcrane]

The UV currently generates thumbnails from the first image resource on a canvas, even if the canvas has a thumbnail property.

The UV should evaluate thumbnail services where available and use them in preference. There is still some work to be done on defining the "best possible thumbnail" algorithm, given a canvas and a required size and hints as to how keen you are to avoid using the main image service.

See https://gist.github.com/tomcrane/8b5ba6049dc86a722632

This gets significantly more complex when authorisation is added.

[tomcrane]

var thumbUri = canvas.getThumbnail(preferredSize);

...something to bake into Manifesto

[tomcrane]

NB You need explicit thumbnail assertions on Wellcome manifests to properly test this, currently we only have a static thumbnail assertion which is not enough. I'll create a task for me to do that.

[edsilv]

Notes: Prefer thumbnail service to image service if supplied and if the thumbnail service can provide a satisfactory size +/- x pixels.

[edsilv]

Christy and Jenn would like to know how custom thumbnails can be selected. Here's an example of a page of fairly uninteresting thumbnails:

http://thing.whatsinthelibrary.com/subjects?subject=Paralysis

[tomcrane]

@fractos - we need to add an example of a manifest that provides a level0 profile thumbnail service. Ideally this could be the new DLCS but I will try to simulate this in current manifests.

@jennpb - we could do a number of things to assert a better thumbnail, but all of them involve recording that assertion somewhere. We could add something to the METS which is currently the authority for the digitised bits of the work but that's very hard for you to get at and modify, and would need a re-run through Goobi, so not ideal. This is part of a wider need to have somewhere to make ad hoc additional assertions about a work that will be picked up in manifest generation - the LOD pipeline visits METS, CALM, MARC data from Sierra, OCLC and then this additional store to see whether anyone has said anything else interesting about it. Most things will have had nothing additional said about them. But little by little you'll enrich the material - providing a better thumbnail here, some additional metadata there, some additional structure (e.g., chapters) over here.

@edsilv, @jennpb - "Prefer thumbnail service to image service if supplied and if the thumbnail service can provide a satisfactory size +/- x pixels" - I'd say "STRONGLY prefer" and be prepared to compromise on the size for the sake of enhanced speed and user perception (as per https://gist.github.com/tomcrane/8b5ba6049dc86a722632). They are thumbnails after all. I think the open thumbnail panel of the UV could use the 400px-bounded image proposed in my example always (and as the only thumbnail loaded).

[tomcrane]

...and capturing the thumbnail selection algorithm in manifesto means it can be improved over time, or provide more than one strategy depending on need.

[jennpb]

@tomcrane Speed is a top priority, so the 400px max thumbnail is fine by me.

In our use case where we want to display a wall of thumbnails outside the viewer, we want to be able to show all title pages, for example. Are you saying that this would need to be done, and recorded in a data store, on a one-by-one basis? I'm fine with editorial selection, but it would also be good to be able to do this programmatically.

[tomcrane]

We could do this programmatically as we have the information already (in the METS). We just need somewhere to store the information for quick access when generating collections.

[tomcrane]

Proposed thumbnail flow (first draft)
https://gist.github.com/tomcrane/093c6281d74b3bc8f59d#file-thumbnail-selection-md

[azaroth42]

We ran into this with the thumbnail pane, now that we have our multi-image content available as IIIF. We only have level 0 implementation at the moment, and thus can't respond to the 90, size request. We specify a static thumbnail in the thumbnail property for the canvas, and the profile of level0.json for the image service.

[tomcrane]

I now have an implementation of getThumbnail as described above which the UV could adopt, but it's not quite finished; it's optimised for inline level 0 thumbnail services like [1]. I will try to get that finished this weekend.

One thing that came up is the degree to which the manifest can help the client pick the best thumbnail for its UI purposes while avoiding service dereferences. [1] is the best case scenario for a client I think. The client uses:

function getThumbnail(preferred, min, max)...

where preferred, min, max are either integers (indicating a square bounding box) or sizes { width, height }, and preferred <= 0 means "I don't care".

@azaroth42 - For your case of "thumbnail" : "http://example.org/thumb.jpg", I could only return the raw url if we don't care how big it is (which is fine, but sometimes the client will care). This gets more into best practices (I'll write this up fully later), but do you have the info to emit this?

"thumbnail" : {
   "@id": "http://example.org/thumb.jpg",
   "@type": "dctypes:Image",
   "width": 200,
   "height": 300
}

If so the client could decide whether to use the supplied thumbnail, or go to the image service for one.

Will follow this up, been on my TODO list for too long.

[1]

{
    "@id": "http://wellcomelibrary.org/iiif/b21299237/canvas/c6",
    "@type": "sc:Canvas",
    "label": " - ",
    "thumbnail": {
        "@id": "https://dlcs.io/thumbs/wellcome/1/9cf1d592-c63e-4e66-a11e-60a34642d7c8/full/61,100/0/default.jpg",
        "@type": "dctypes:Image",
        "service": {
            "@context": "http://iiif.io/api/image/2/context.json",
            "@id": "https://dlcs.io/thumbs/wellcome/1/9cf1d592-c63e-4e66-a11e-60a34642d7c8",
            "protocol": "http://iiif.io/api/image",
            "height": 1024,
            "width": 626,
            "sizes": [
                { "width": 61, "height": 100 },
                { "width": 122, "height": 200 },
                { "width": 244, "height": 400 },
                { "width": 626, "height": 1024 }
            ],
            "profile": [ "http://iiif.io/api/image/2/level0.json" ]
        }
    },
    "height": 3133,
    "width": 1914,
    "images": [
        {
            "@id": "http://wellcomelibrary.org/iiif/b21299237/imageanno/9cf1d592-c63e-4e66-a11e-60a34642d7c8",
            "@type": "oa:Annotation",
            "motivation": "sc:painting",
            "resource": {
            "@id": "https://dlcs.io/iiif-img/wellcome/1/9cf1d592-c63e-4e66-a11e-60a34642d7c8/full/!1024,1024/0/default.jpg",
            "@type": "dctypes:Image",
            "format": "image/jpeg",
            "height": 1024,
            "width": 626,
            "service": {
                "@context": "http://iiif.io/api/image/2/context.json",
                "@id": "https://dlcs.io/iiif-img/wellcome/1/9cf1d592-c63e-4e66-a11e-60a34642d7c8",
                "profile": "http://iiif.io/api/image/2/level1.json"
            }
            },
            "on": "http://wellcomelibrary.org/iiif/b21299237/canvas/c6"
        }
    ]
},

[tomcrane]

This isn't finished yet, and needs more testing, but comments welcome:

http://tomcrane.github.io/iiif-expts/getthumbnail/

[azaroth42]

What about prefH, prefW, minH, minW, ... ? For example, if you have a set height in the UI for bottom pane filmstrip of thumbnails (ala Mirador), then you would want to fix height and allow width to be anything. If you had a side panel (ala UV), then probably you want to fix width and allow height to be anything.

[tomcrane]

Yes, I intend to allow any of (preferred, min, max) to take a size { width: .., height: ..} as well as integers. Wanted to get the logic right for a square box first. UV would need something like 90,200 - fixing the width but allowing the height to be anything makes for some interesting effects when images of the spine are included... :)

[LlGC-szw]

All issues will be triaged for further investigation or closure by the 28 September 2023. If your issue is still relevant and would like for it be investigated further please comment by 14 September 2023.

[tomcrane]

Has this been superseded through adoption of libraries that pick appropriate thumbs?
It's still an important issue for user experience - thumbs load fast if you use advertised sizes - and it encourages a virtuous circle - if UV notices and uses published sizes then more publishers might include them in IIIF Image API.