Index image dimensions from IIIF info.json

[ddeboer]

Problem

Frontends need image dimensions before an image loads: layout stability (CLS, skeleton loaders with the right aspect ratio), justified/masonry galleries, correct srcset ceilings, and lightboxes such as PhotoSwipe all require the intrinsic width × height. IIIF’s size grammar (!w,h, ^, max) makes requesting images dimension-free, but layout and variant selection are irreducibly dimension-dependent – and requesting a size beyond the intrinsic one even errors on IIIF Image 3.0 servers without upscaling support.

The dimensions are available in each image’s info.json, but fetching those from the presentation layer is an N+1 problem: 20–50 extra async requests per search-results page. That lookup belongs in the data layer, at ingest time.

Context: netwerk-digitaal-erfgoed/prototypes-data-layers#14.

Proposal

Enrich indexed images with their intrinsic width and height:

• Add optional width/height fields for image objects to the search schema and index documents. This stays within schema.org, which already defines both on MediaObject.
• Use dimensions when the source data provides them; otherwise fetch the IIIF info.json during ingest.
• Cache dimensions persistently, keyed by image URL: a IIIF identifier’s dimensions are immutable, so only images new to the index cost a request on re-ingest.
• Make enrichment non-blocking: index the record without dimensions when the fetch fails (dead link, timeout), record the failure, and retry with backoff. Bound concurrency per host.

Two integers per image give consumers everything derived: aspect ratio for layout, and the size ceiling for srcset generation, zoom depth, and safe IIIF URL rewriting.

[ddeboer]

Superseded, after a design review that changed two premises.

LDE must not know about images or IIIF. packages/search/CONTEXT.md states that
LDE ships capabilities and names no domain, and a Deployment supplies every domain
semantic. Adding width and height for image objects to the search schema would have
made this the first domain LDE names, and @lde/iiif-validator – the one
domain-named package, still without a consumer – is a caution rather than a
precedent. Everything IIIF-shaped moves out.

Dimensions cannot land in RDF. The indexer reads publisher-provided data live per
dataset, or an ephemeral per-dataset QLever. There is no LDE-owned store to write
enrichment into, and ADR 16
rules out the shape that would create one. So the enrichment attaches to the projected
record, and the dimensions live in a store keyed by image identifier.

Split into three:

• Add a per-record enrichment seam after projection #675 – a per-record enrichment seam after projection, plus promoting
  the host-limited concurrent map out of distribution-probe. Domain-free.
• Serve inline references as nested output #674 – inline references served as nested output, so a record’s images
  arrive grouped per image instead of as parallel arrays. Closes a gap
  ADR 11
  and CONTEXT.md already promise. Domain-free, and worth doing on its own merits.
• Index image dimensions from IIIF netwerk-digitaal-erfgoed/stack#1 – the IIIF half: manifest-first resolution, the
  fact-and-alias store, per-host bounds and thresholds.

Other things the review changed, recorded there rather than here: dimensions are read
manifest-first rather than from info.json per image (SCHEMA-AP-NDE declares the
manifest in associatedMedia, and one fetch covers every canvas); the store is keyed
on the image service identifier with aliases for observed URLs, because manifests are
mutable and image identifiers are not; and the persistent cache is not a cache but the
only place the fact lives.

Recommend closing in favour of the three above.