Cached Image Dimensions

For /manifest and by extension the transcription interface, we are going to process IIIF Image API `/full/full` images special. In the cases where the back end has to `getUncachedImageStream` (when it needs Dimensions for Canvases and Images in the Manifest that are not cached in the SQL, happens when the front end triggers JSONLDExporter.java for a project for the first time) we are going to ask for those dimensions using /full/,200. Why? Because it takes _10 minutes_ to do /full/full for 220 Canvases. It takes _45 seconds_ to do` /full/,150` for the same Manifest.

As a consequence, the images natural size will be cached as` x, 150` in relation to the Canvases `w, 1000`. This means all interfaces that receive this Canvas object will be expected to attempt to render the larger image. The transcription and parsing interfaces do this already. If other interfaces don't, interoperability scenarios will be using a low res image.

We want eliminate this scenario entirely.

- If the image dimensions were cached during `createProjectFromManifest` users wouldn't experience the lag when they load the manifest.

- Perhaps a background script or thread to go through the cached dimensions in SQL, detect this IIIF Image scenario, and update the size or a patch in JSONLDExporter that detects it and automatically updates the URL to /full/,2000 or better and figures the Canvas and Image dimensions on the spot (it won't need to resolve the image to do this so the delay is eliminated) before sending the Manifest object forward.

- Let the transcription interface detect this scenario after it loads the Manifest and Image, and let it update the cached dimensions per folio.