The S3 key of any given file, minus the extension, is its IIIF ID. For example, if you want to access the image manifest for the file at abcdef.tif, you would get https://.../iiif/2/abcdef/info.json. If your key contains slashes, they must be URL-encoded: e.g., ab/cd/ef/gh.tif would be at https://.../iiif/2/ab%2Fcd%2Fef%2Fgh/info.json. (This limitation could easily be fixed by encoding only the necessary slashes in the incoming URL before handing it off to the IIIF processor, but that's beyond the scope of the demo.)
iiif-processor can use any image format natively supported by libvips (opens in a new tab), including JPEG 2000 (.jp2), but best results will come from using tiled, multi-resolution TIFFs. The Lambda Function wrapper included in this application assumes a .tif extension unless you change it at deploy-time using the ResolverTemplate parameter.
Alpha Channels
Some versions of libvips and libjpeg have an issue with JPEG-compressed pyramidal TIFF images that include more than 3 channels (e.g.,
alpha channels). If you find that serverless-iiif returns an error for an image request or isn't rendering as you'd expect, try removing any additional channels beyond red, green, and blue.