Moved creation of thumbnail urls from MediaRepresentation to ThumbnailManager.

[Daniel-KM]

To make media more generic, the creation of the thumbnail urls may be moved into the thumbnail manager. It will make creation of thumbnails more flexible, in particular for media iiif, where the image server can create thumbnail itself, but it will be for a next pr if this one is passed.

[Daniel-KM]

And it will fix https://forum.omeka.org/t/thumbnail-creation-with-iiif-image-media/18584 (thumbnails don't need to be stored locally by omeka, but created dynamically (or cached) by the image server.

[olivierghuzel]

This development would be very welcome!

Large loadings of IIIF media are extremely slowed down by the creation of thumbnails. But these are often superfluous.

The high definition version of the image is downloaded and then processed to create the thumbnails. In many cases, the IIIF server can provide the same service more efficiently, and with a saving in disk space.

I hope it can be done!

[zerocrates]

Can you give a preview or discussion of what the feature this is intended to enable will look like, code-wise?

Hoping to get a sense of why it's useful/necessary to move the URL code here.

[Daniel-KM]

The first idea is purely technical: to move everything related to thumbnail in the same place. Since all media are no more files like Omeka Classic, the thumbnails should be managed outside of the media representation.

This transparent refactorisation will make the creation of the url of the thumbnails overridable by modules. So the module may add a check for the media ingester iiif image in the method thumbnailUrl(), then get the url of the thumbnail provided by the image server to avoid to create static thumbnails, that are useless in big bases. This code can be implemented in the core anyway, since the format of the urls are standard in IIIF and iiif data of the image are available. And this change will open more possibilities too, for example to use more fallback thumbnails or to use webp instead of jpeg.

The code can be improved via delegators, or via an event, but the move avoids any side effects so it can be integrated for v4.1.

[zerocrates]

Just so I'm clear, from a purely functional standpoint, the benefit to moving the method here is that it's then in a service and you can more easily override a service than the representation?

[Daniel-KM]

Yes, representations are the core of omeka so it should not be overridden, but a thumbnail manager is something less essential.

Ideally, nothing should be overridden, but for now, it is not possible to modify the way the url of thumbnails are created without modifying the core. If you prefer something else, tell me.

[Daniel-KM]

So in thumbnailUrl() (or equivalent in MediaRepresentation):

if ($media->ingester() === 'iiif') {
    // To be done.
    return $this->getServiceLocator()->get('IiifImage')->thumbnailUrl($media, $type);
}
// else current code...

And the iiif ingester can maybe be set "has no thumbnail".

[zerocrates]

Right, OK, I see the general idea.

Let me think it over a bit and get back to you... thinking about the interaction of this, hasThumbnails, needing to skip the thumbnail generation in the first place, etc.

Some hesitancy for having the thumbnail manager have knowledge of the representation... thinking also if we should just loop in the ingester and/or renderer here.

[Daniel-KM]

Yes, and the idea is the same for a media youtube, where you can use a thumbnail from youtube instead to install ffmpeg on the server.