We’re about ready to start running all of the images into an IDA instance of the DLCS, so that they have IIIF endpoints and we can generate initial manifests for them.
One decision to make before we do this is the sizes of optimised thumbnail derivatives. When we build UI we can take advantage of the fact that the DLCS can provide some sizes more efficiently (i.e., quicker) than others.
You can see the effect of this here: http://tomcrane.github.io/wellcome-today/thumbs.html?manifest=http://library-uat.wellcomelibrary.org/iiif/b21978426/manifest This UI makes use of the fact that Wellcome’s material has 100, 200, 400 and 1024 pixel-bound derivatives available faster than an arbitrary sized derivative, so it works entirely off those sizes.
(If you have a play with this you will notice a bit of a delay in loading a new work – this is because either the UAT server has gone to sleep, or it’s taking a second or two generating a new manifest – the UAT server doesn’t have any manifests cached so most things are new to it).
I’m working on the assumption that some of the UI we develop for IDA will need to present large numbers of thumbnails quickly, to help people visually identify discrete documents within a mass of thinly described content. We can use our optimised thumbs to make the experience better. This UI assumption may be wrong, we can pick it apart next week – but for now I’m going to assume that having fast thumbnails is good and helpful to us.
(George – we didn’t have this feature when you were making alpha.wellcomelibrary.org, although I think it would be very simple to change your requested sizes to match the optimised ones).
I have no idea what the best sizes to choose are. The 200 at Wellcome was driven by policy (it was decided that archival material less than 100 years old could only be viewed up to 200 pixels before the user needed to accept terms – see example - http://tomcrane.github.io/wellcome-today/thumbs.html?manifest=http://library-uat.wellcomelibrary.org/iiif/b18182197/manifest). We don’t have that limitation for IDA, so we could pick any sizes. Or just one or two sizes and do some client side scaling. The 100, 200, 400 and 1024 seem useful – but maybe 150, 300 and 1500 would be better… Any suggestions? We can go and change them later, but it would be more efficient to do them on the initial run.
Adam, Matt and John – There is Python code in Waylon that talks to the DLCS for registering images. You probably don’t want to use my .NET code. They need to be registered from an origin, so you might want to start pushing the images into a temporary S3 bucket where the DLCS can get at them. If Matt provides metadata values on the images then we can use DLCS Named Queries (TM) to generate the initial manifest per reel, which is all we need for the workshop.