You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Orchestrator will use thumbnails to serve /full/ image requests where possible, in some instances sizing down existing thumbnails.
A further improvement to this handling would be to allow Thumbs service to crop existing thumbnails, in addition to resizing them. This would involve using the IIIF region and size parameters to crop the image on the fly using ImageSharp (which we use for resizing).
Thumbs handler is already capable of resizing images so it makes sense to add the handling to Thumbs rather than Orchestrator. Thumbs can be configured to enable/disable resizing - in a production deployment there would be Thumbs configurations running: the first is public and will never resize, the second is private and allows resizing. We can use the latter configuration to crop images in addition to resizing. Thumbs service only has access to the pregenerated thumbnail sizes, it doesn't know the size of the origin image so Orchestrator will need to pass this as part of the proxy request, either via http header or query param.
Outstanding question:
We don't want to crop existing thumbnails for all requests - what is the logic to work out when to apply this? Is it based on the Size parameter alone? Size parameter in relation to generated thumbs?
An example is 5532x4408 image where we have thumbnails of "!1024,1024", "!400,400", "!200,200". We could resize the !200,200 thumbnail if we receive a request for 10,10,5000,4000/177,/0/default.jpg
The text was updated successfully, but these errors were encountered:
Orchestrator will use thumbnails to serve
/full/
image requests where possible, in some instances sizing down existing thumbnails.A further improvement to this handling would be to allow Thumbs service to crop existing thumbnails, in addition to resizing them. This would involve using the IIIF region and size parameters to crop the image on the fly using ImageSharp (which we use for resizing).
Thumbs handler is already capable of resizing images so it makes sense to add the handling to Thumbs rather than Orchestrator. Thumbs can be configured to enable/disable resizing - in a production deployment there would be Thumbs configurations running: the first is public and will never resize, the second is private and allows resizing. We can use the latter configuration to crop images in addition to resizing. Thumbs service only has access to the pregenerated thumbnail sizes, it doesn't know the size of the origin image so Orchestrator will need to pass this as part of the proxy request, either via http header or query param.
Outstanding question:
An example is 5532x4408 image where we have thumbnails of
"!1024,1024", "!400,400", "!200,200"
. We could resize the!200,200
thumbnail if we receive a request for10,10,5000,4000/177,/0/default.jpg
The text was updated successfully, but these errors were encountered: