-
Notifications
You must be signed in to change notification settings - Fork 2
Description
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
createProjectFromManifestusers 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.