Appearance
The short answer: static image tiles are pre-generated files served straight from storage, while a dynamic IIIF server computes any region, size and rotation on demand from a master. Choose static tiles for stable collections where you want minimal infrastructure and predictable cost; choose a dynamic server when your collection changes often or you need arbitrary crops and rotations. Both can be IIIF-compliant, so this is an architecture choice, not a standards choice.
What does "tiling" even mean?
A high-resolution scan might be 400 megapixels. No browser downloads that to show you a thumbnail. Instead the image is sliced into a pyramid: the top level is a tiny overview, each level below doubles the resolution, and every level is cut into small squares (tiles) of, say, 256 by 256 pixels. When you zoom and pan, the viewer fetches only the handful of tiles covering your current view at your current zoom. Both approaches use tiling; they differ in who makes the tiles and when.
Static tiles versus a dynamic server: the plain version
With static tiles you generate the entire pyramid once and save every tile as a file. The viewer reads tiles directly from a CDN or bucket. Nothing runs server-side. With a dynamic IIIF server, you store only the master image and the server cuts whatever tile is asked for, in real time.
| Aspect | Static tiles | Dynamic IIIF server |
|---|---|---|
| When tiles are made | Once, ahead of time | On demand, per request |
| Infrastructure | Files on a CDN/bucket | A running server to operate |
| Arbitrary regions/rotation | No, only pre-baked sizes | Yes, anything the API allows |
| Storage | Whole pyramid stored | Just the masters |
| Cost profile | Cheap at rest, costly to store | Compute cost, cheaper storage |
| Updating content | Re-generate the pyramid | Drop in a new master |
A small worked example
Say you have one 30,000 by 20,000 pixel map and you want it zoomable on a static site. Generate a tile pyramid with libvips:
bash
# Produce a DeepZoom (DZI) tile pyramid as plain files
vips dzsave big-map.tif big-map --tile-size 256 --overlap 1 --suffix .jpg[Q=85]That writes a big-map_files/ directory of tiles plus a big-map.dzi descriptor. Upload the folder to your CDN, point a viewer at the descriptor, done, no server. To make it IIIF instead, you would run Cantaloupe over big-map.tif and let it generate tiles live.
When should a beginner choose static tiles?
Pick static tiles when:
- The collection is finished and rarely changes.
- You want the least infrastructure to maintain and patch.
- You only need standard zoom, not arbitrary crops or rotations.
- You are publishing to a static-site host or plain object storage.
A fixed set of historical photographs on a CDN is the textbook case: cheap, fast, nothing to babysit.
When is the dynamic server worth it?
Choose a dynamic IIIF server when:
- Items are added or replaced frequently (re-baking a whole pyramid each time is painful).
- You need arbitrary regions, sizes and rotations, for annotation, research or comparison tools.
- Total pyramid storage would be prohibitive but masters are manageable.
- You want full Image API flexibility for downstream reuse.
The flexibility costs you a server to run, monitor and secure.
Can you have both?
Yes, and many institutions do. A common pattern is a dynamic server for the working collection plus a CDN cache in front, so frequently requested derivatives become effectively static after first request. You can also pre-bake static IIIF-compliant tiles for a stable, high-traffic showcase while running a dynamic server for the long tail. The decision is rarely all-or-nothing.
Key Takeaways
- Both approaches use tile pyramids; they differ in who generates tiles and when.
- Static tiles are pre-baked files on a CDN: cheap and low-maintenance, but inflexible.
- A dynamic IIIF server computes any region/size/rotation on demand but must be operated.
- Static tiles can still be IIIF-compliant with an info.json.
- Choose static for stable collections and minimal ops; dynamic for changing collections and arbitrary derivatives.
- A CDN in front of a dynamic server gives you much of both worlds.
Frequently Asked Questions
What are static image tiles?
Pre-generated pyramids of small image squares (often DZI or a fixed-level IIIF tile set) saved as plain files. A viewer requests the right tiles directly from storage; no running image server computes anything.
What is the core difference from a dynamic IIIF server?
A dynamic IIIF server computes any region, size and rotation on demand from a master image. Static tiles only offer the exact derivatives you pre-baked, so arbitrary crops and rotations are not available.
Which is cheaper to run?
Static tiles are usually cheaper at rest because they are just files on a CDN or object store with no server to patch or scale. The cost moves to one-time generation and storage of the tile pyramid.
Can static tiles still be IIIF-compliant?
Yes. You can pre-generate tiles that satisfy a fixed Image API level and ship an info.json, so IIIF viewers consume them like any other endpoint, just without dynamic flexibility.
When should a beginner choose static tiles?
When the collection is stable, you want minimal infrastructure, and you do not need arbitrary regions or on-the-fly rotation. A stable photo collection on a CDN is the classic case.
When is a dynamic server worth the extra effort?
When the collection grows or changes often, when you need arbitrary crops, rotations and sizes (for annotation or research tools), or when you cannot afford the storage of a full pre-baked pyramid.