What's the point of this?

Flickr, Wikimedia Commons and many other large repositories of images have several sizes available for a given image - a "legacy image pyramid". If these repostories can:

• describe the sizes available for an image in an info.json for that image
• return the appropriate sized image in response to a request that conforms to the IIIF Image API

...then all their images are opened up to the IIIF Universe. This does not require an image server. It requires a shim to translate, proxying the IIIF requests on to the existing static images, and generating an info.json from the image metadata.

Of course, it would be great if everyone's images were available as Image API level 2 services, so that they could be tiled, cropped, stretched, resized, rotated and so on. This is much better for high performance zooming and panning, and it allows URLs that return the pixels of arbitrary regions. Tile-less IIIF isn't a good solution for gigapixel images! Wikimedia is in fact implementing tiled IIIF already. But support for legacy image pyramids brings some pretty significant benefits. The images can be used by anyone in Presentation API Manifests^[1], opening them up to annotation, mashups, and other possibilities. It means they are usable in Mirador, Universal Viewer, Diva, leaflet and every other IIIF viewer.^[2]

¹ You can do this already - the image resource that annotates a canvas doesn't HAVE to have an image service. However, many viewers expect it to.
² If powered by OpenSeadragon, you need this.