Cannot create compliant info.json for single static image unless it is jpg

[azaroth42]

From slack, @mradamcox brought up that you cannot create an info.json for a static image that is only available as png and not as jpg, as jpg is a required format in all levels.

An edge case, as info.json wrappers around single static files aren't a great pattern ... but worth considering if this should be allowed in a future version.

[mradamcox]

For a little context, the desire for wrapping info.json around a generic static image (not necessarily a jpg) comes from working on an app that will feed endpoints into a IIIF client, but wanting to make the installation of an actual backend IIIF server optional (reasons include the desire to reduce the tech stack in cases where small images are used, etc.).

In other words, I've written endpoints for manifest and info.json which redirect to the IIIF server outputs if one is installed, but I was thinking could still return valid objects based on static images if a IIIF server is not installed. A valid manifest can be created quite easily from any static image, and I believe this is enough for my own use case--I don't think I'll need the info.json at all. For example, one client I was considering passing the info.json to is OpenLayers, but in that case I should just swap to passing an ol ImageStatic source based on the static file instead.

[jpstroop]

Isn't part of the level 0 use case that, from a client perspective, one should be able to construct an image request without examining the info.json? If so, then jpg has to be reliably available as full/max/0/default.jpg should always work. It would be strange to make something optional at level >0 but required at level 0 as features only accumulate at higher compliance levels.

A possible but ugly workaround: We say "A format value that is unsupported SHOULD result in a 400" (not MUST), and we don't explicitly say that a request for a jpg has to return a JPEG file, so I suppose *.jpg could be configured to redirect to *.png and for most use cases everything would be fine.

[mradamcox]

I don't know enough about the theory behind IIIF to really respond to your first point, but I do understand what you're getting at. Again, for me it was more about streamlining the front-end to work with a flexible backend: if a client can consume an info.json that points to a static image, I initially expected that any old image could be put in there, not just JPG... more to do with my limited understanding of the spec, I think.

I did consider the workaround you describe, but luckily in this case there are less ugly alternatives that I can pursue.