SpecialServer

[tomcrane]

Handles requests for /full/ images that Orchestrator hasn't matched to a thumb size.
May still forward on to image server cluster. Or might do some other image processing directly, possibly even from S3.
Avoid mixing /full/ load with tile load.

.NET Core service.

[tomcrane]

Have a good look at https://github.com/imazen/imageflow-dotnet-server

Consider contributing an IIIF handler to it.

[tomcrane]

Could Engine use SpecialServer to make thumbs? Instead of or as well as Appetiser?
And could it do them on demand, after the fact - e.g., if you added some extra sizes to the thumbnail policy for an image. The Thumbs service, just before it returns a 404 for a non existent thumb size, could check the policy and see if it is actually a supported size and create a new thumb on demand - either by reducing the next thumb size up using the above imageflow, or if the new size is bigger than any existing thumbs, by invoking imageflow on the source image?

NB imageflow does NOT support JP2 and has no plans to.
But SpecialServer might have its own personal Cantaloupe / IIP to call on, as well, maybe...

[tomcrane]

Further notes on this:

/full handling: https://github.com/dlcs/protagonist/blob/master/docs/architectural-considerations.md#dealing-with-full-image-requests
/full thumbnails: #39

[donaldgray]

Have a good look at https://github.com/imazen/imageflow-dotnet-server

Consider contributing an IIIF handler to it.

As imageflow doesn't support JP2 this doesn't seem like an option, instead use a custom Cantalopue with an s3 source

[donaldgray]

Implemented this via the Cantaloupe delegate system.

This will allow us to use an S3Source in Cantaloupe, with the image source being ImageLocation.S3. The delegate will parse this to get bucket + key.

Added this to the same Cantaloupe image that we are already using as the change is only adding a delegates.rb file to the image - the usage of it is then controlled via properties.