Compliance with the IIIF Image API 2.0

[reinink]

As per @alexbilbie's suggestion, it may be worth investigating adding IIIF Image API 2.0 compliance to Glide. Their URI spec is as follows:

{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}

• identifier - source file
• region - crop area
• size - target size
• rotation - orientation
• quality - basically effects (color, grayscale or black/white)
• format - jpg, tif, png, gif, jp2, pdf, webp

The biggest challenge I see is that this limits Glide quite a bit, as the original intent of this spec wasn't for image manipulation:

This API was conceived of to facilitate systematic reuse of image resources in digital image repositories maintained by cultural heritage organizations. It could be adopted by any image repository or service, and can be used to retrieve static images in response to a properly constructed URI.

However, Glide could still offer compliance, albeit with only a subset of the overall feature set. We could offer a URI parser to do this work. Something like:

$glide = Glide\Factory::server([
    'source' => 'images',
    'cache' => 'cache',
]);

$parser = new Glide\UriParser\IIIF($request);

$glide->outputImage(
    $parser->filename(),
    $parser->params()
);

[alexbilbie]

So during presentation I saw from the guys who wrote the spec they demonstrated their use-case which was sharing pages from digitised historical manuscripts between academic institutions. They were focussing on the sharing aspect but in essence what their API does (IMO) is facilitate image manipulation.

Perhaps IIIF compliance is actually something that can be solved through a StackPHP middleware instead of the core library

[reinink]

I've posted a message on the IIIF mailing list, but it's not approved yet. Once it has been I'll add it to this ticket.

Perhaps IIIF compliance is actually something that can be solved through a StackPHP middleware instead of the core library

Love it!

[reinink]

You can follow the discussion with the IIIF here. Sounds like this is doable, although we will need to add JSON information responses, which sounds like a good idea anyway.

[reinink]

I'm going to close this issue for now. Not because I don't want to do this, but because I just don't have the capacity right now. It's something we can revisit in the future