Photographic Carriers
§E1 The photographs as infrastructure
The 8 Museum is a collection of photographs of the numeral 8 found in the world. Its founding collection is the first 8,888 entries of the museum’s register, completed on 2 September 2026. The register continues; later entries are not carriers. The carrier files themselves have not yet been made — they are finished at the ceremony, when the shards they describe exist — and this page specifies what each will be.
Each founding photograph is paired with one shard of the vault and will carry, in the least significant bits of a thousand of its samples, an 88-byte record for that shard. The visible picture and the invisible record are two readings of one object. Nothing about the picture gives the record away, and nothing about the record is secret: the method is published here, the positions can be computed by anyone, and the record’s contents are public facts about public ciphertext. The photographs are hidden in plain sight — art that is also infrastructure — but what they hide from is the eye, not the analyst.
§E2 What a photograph carries — record AB-R1
| Bytes | Field |
|---|---|
| 0–3 | “AB8R” |
| 4 | profile version (1) |
| 5 | flags — bit 0: a sealed key is present; bit 1: rehearsal |
| 6–7 | photograph number, 1–8,888 |
| 8 | capsule number, 1–101 |
| 9 | shard number, 1–88 |
| 10–11 | reserved, zero |
| 12–51 | the capsule’s sealed key Wc (40 bytes), or zero |
| 52–83 | SHA-256 of the shard file |
| 84–87 | CRC-32 of bytes 0–83 |
That the record comes to exactly 88 bytes is a courtesy of the arithmetic. Photograph i is paired with capsule c = ((i − 1) mod 101) + 1 and shard s = ⌊(i − 1) / 101⌋ + 1.
The sealed key is the capsule’s content key wrapped under a key that does not exist until the lock yields (Sealing §S6). It is useless today and to anyone who cannot open the lock, which is why it can ride in a public photograph. It is also the single most loss-critical datum in the vault — without Wc an opened lock opens nothing — and so it is the datum replicated most widely: in every one of the capsule’s 88 shard headers, in the capsule inventory, and in 88 photographs spread evenly across the collection. The photographs are keys. Sealed ones.
Photographs paired with Remainder capsules carry no key, because there is none. Their records hold a digest and nothing else: a headstone rather than a key.
§E3 Protection
The record is extended to a 128-byte codeword by a Reed–Solomon code: GF(28) with polynomial 0x11D and α = 2; generator ∏i=0…39(x − αi); systematic, the 40 parity bytes following the record, with byte 0 of the record as the coefficient of the highest power. Any 20 damaged bytes among the 128 are corrected; the CRC catches what the code miscorrects. The codeword is 1,024 bits, embedded most significant bit first.
§E4 Canonical carriers
The museum’s website shows WebP images made for looking at. Those are exhibition derivatives and carry nothing. A carrier is a specific PNG file:
Canonicalisation is done once. The source photograph — HEIC or JPEG from the capturing phone — is decoded with its orientation applied, colour-managed into sRGB, reduced to 8 bits, and written as PNG. The tools and versions are recorded for provenance, but the conversion does not need to be reproducible and is not claimed to be: canonical means these bytes, fixed by their digest. The sources themselves are preserved inside the vault.
The two digests answer different questions. The file digest says whether this is the very file that was sealed. The pixel digest survives any lossless re-encoding — a different compressor, a future format — and says whether the picture, and therefore the record, is intact.
§E5 Embedding — profile AB-C1
Number the samples of a W × H image s = 3(yW + x) + channel, with red 0, green 1, blue 2, so that there are N = 3WH of them.
On average 512 samples change, each by one level. In a twelve-megapixel photograph that is one sample in seventy thousand, at an embedding rate below 0.00003 bits per sample. The reduction v mod N carries a bias smaller than 2−35 for any image under a hundred megapixels, which matters to nobody and is mentioned for completeness.
The positions depend only on the photograph’s number and dimensions, never on its pixels. That is the property that makes extraction exact: the reader computes the same positions from the same three numbers, whatever the writer did to the samples. Content-adaptive schemes — S-UNIWARD (Holub, Fridrich and Denemark, 2014) with syndrome-trellis coding (Filler, Judas and Fridrich, 2011) — are better at evading a steganalyst, and would be the right tool if the record were a secret. It is not. What the record needs is an extractor that a stranger can reimplement from one page of prose in an unknown century, and a hash function and a modulus meet that need where floating-point wavelet costs do not.
§E6 Extraction, and what survives what
To read a carrier: decode the PNG to 8-bit RGB with no colour management, compute the positions from the photograph’s number and dimensions, read one bit from each, Reed–Solomon decode, check the CRC.
| What happened to the file | Embedded record | iTXt copy |
|---|---|---|
| Copied byte for byte | survives | survives |
| Re-encoded losslessly, metadata kept | survives | survives |
| Re-encoded losslessly, metadata stripped | survives | lost |
| Retouched or cropped in place, saved as PNG with metadata | damaged or lost | often survives |
| Resized, colour-converted, or saved as JPEG or WebP | lost | usually lost |
The two copies fail under different insults, which is the reason for having both. And no photograph is a single point of failure: every record is also written out in the signed catalogue, its sealed key is in all 88 of the capsule’s shard headers, and its digest is in the capsule inventory. A photograph that has lost its record is still a photograph.
A record is protected against damage, not against forgery; anyone can compute a CRC. A record is believed because it agrees with the signed catalogue, or with many independent copies of itself — and a sealed key needs no vouching at all, since a false one simply fails to unwrap.
§E7 The carrier catalogue
The catalogue is a plain text table, one line per photograph: number, museum register identifier, capture date, dimensions, file digests, pixel digest, capsule, shard, and the 88-byte record in full. It is signed at the ceremony (Preservation §R7), travels with every replica, and is printed in the bootstrap kit. Together with the records inside the photographs it lets a future reader establish, from either direction, which pictures belong to the vault and whether they are intact.
§E8 Handling
- Move carriers as files, never as images. Verify the file digest at the destination.
- Never resize, rotate, crop, colour-correct, re-save or “optimise” a carrier. Make a derivative for that and keep the carrier.
- Never serve carriers through anything that processes images on the way: CDN optimisers, photo libraries, social platforms, messaging apps.
- Keep the catalogue beside the carriers.
- When in doubt, extract. It needs no key and harms nothing.
§E9 The rehearsal carrier
rehearsal-carrier.png is a synthetic 888 × 888 image — it is not a museum photograph — carrying a record for rehearsal capsule 1, under photograph number 0, which is reserved for rehearsal. Rehearsal capsules are not sharded, so the record’s digest field holds the SHA-256 of the capsule file, standing in for a shard.

python3 afterberry_ref.py carrier-extract rehearsal-carrier.png --index 0The sealed key in that record is the one in the rehearsal lock file, and opens with it. The tool reads and writes PNG itself, implements the Reed–Solomon decoder in full, and depends on nothing outside the Python standard library.