Image entropy: data and methodology

1Reviewer brief

The rules that govern how to read every figure below. A finding that violates one of them will be rejected without re-derivation.

Precedence

The shipped raw frames outrank the manifests. The manifests outrank this document's tables. The tables outrank the prose. Each data directory carries a RUNS.md manifest (data1, data2, data3, data4, data5) recording every retained run, its conditions, its provenance and its figures; those manifests are the curated ground truth this document summarizes. Where two sources disagree, recompute rather than reconcile; section 14 has the commands.

Estimators, and what each one bounds

Three rules that follow:

• "Worst pair" in this document means worst of ALL 45 pairs, not worst consecutive. The consecutive-pair convention was measured and found not reliably conservative (a non-adjacent pair is lower in most series, and in dark series the minimum can sit at maximum separation), so the analyzer selects over every pairing, on the estimator it reports.
• MCV is itself an over-estimate of the floor. It assumes IID differences and sensor noise is spatially correlated; a full SP 800-90B assessment would take the minimum over ten estimators, every one of which can only return less (IE-L-01). Every margin in this document leans optimistic, which matters most for the thinnest rows.
• A compressed figure quoted with floor language ("minimum", "guarantee", "an attacker faces") is an error in this document, and reporting one is a valid finding.

Accounting rules for a sequential hash chain

The seed is hash = sha256(hash + frame_bytes), once per preview frame, then once for the final image (IE-S-01). The rules every total in this document follows:

• A repeated frame contributes exactly zero. Re-feeding identical bytes is deterministic given the prior state. Duplicates and constants are not partial credit.
• The output is capped at 256 bits. The question is always whether the input clears 256, never how far past it the input goes.
• Preview credit = distinct live frames × that run's worst within-run live-live MCV. Constants and cached duplicates count zero. Runs holding a single live frame have no within-run pair and are credited by a cross-run analogy, marked as such (IE-L-05).
• Live-vs-constant MCV must not be used for layer accounting. It measures the global quantization-threshold crossing (~92,000–94,000 bits), not per-read novelty, and overstates the layer by two orders of magnitude (IE-M-10).
• Arrangement entropy is ignored, conservatively. The chain is order-sensitive, so which slots the live frames occupied is itself unpredictability: a live frame at slot 18 versus slot 37 changes every subsequent chain state even when all later slots hold the constant. The credit is bounded by log₂ of the possible placements (log₂50 + log₂49 + …, roughly 28 bits for five live frames in a 50-slot window), and that bound is a ceiling, not a floor: measured placements are correlated (adjacent live indices 18 and 19 in data3/000150-6b66; one cached buffer occupying two slots in data4/000523-6b66), so an attacker modeling capture timing faces less than the uniform figure. It is exactly zero in a preview-zero window, where there are no live frames to place. Omitting it understates totals that have live frames and changes nothing where the chain was thinnest.
• The CPU serial is counted at zero (a fixed device property). time.time() is excluded from every total: on an RTC-less board it is seconds since boot, worth perhaps 25–30 bits against a realistic attacker window, estimated from mechanism rather than measured (IE-I-02).

What "dark" means in this document

"Dark" throughout means effectively total light exclusion at the sensor: a completely or effectively blocked lens. The measured routes there are a device set down lens-down on a shadowed desk, and a deliberately sealed occlusion. Every dark run is verified in-band by the pixel discriminator (IE-M-17). Auto-exposure is only a one-directional corroborant: every properly dark run locked at its unit's stable dark gain (3.25 or 3.625), and a low locked gain indicates light was present, but a high locked gain indicates nothing, because most lit indoor runs also locked at 3.1–3.6 (only the bright wall runs locked low). It does not mean a dim room. No condition between ordinary lighting and near-total blackout was measured (IE-L-14), and every flagged light contamination of the dark state, however small, moved the figure upward by a large factor (roughly 7× to over 100× across the flagged runs), so the collapse phenomena in this document live at the blackout end of the illumination axis, not merely in low light.

Comparability and naming hazards

• Cross-unit ratios are not evidence. Sensor noise is a property of the individual die, and board family, sensor unit and enclosure vary together across units. The controlled comparisons in this document are within-unit and labeled as such.
• Run names collide. The devices have no real-time clock; runs are named by elapsed time since boot, and the on-device unit suffix (-6b66) prevents cross-unit collisions only. The same unit rebooted produces identical names across sessions: real instance, burst-19700101-000025-934f and …000117-934f exist in both data3/ and data4/ as different captures. Never merge dataN/ directories; cite every run with its dataN/ prefix.
• Geometry: compare per-value, never by raw total. The Plus unit's stills are 640×640 (1.78× the values of 480×480), so its raw bit totals are not "better hardware" (data1/RUNS.md).

Settled false positives

These have been raised, considered and dispositioned. Findings resting on them will be rejected, with the reason:

Three levels of checking

Go as deep as you can actually execute. All three are genuinely available, and the third is the only one that produces evidence this analysis does not already contain.

Level 3 is what capture-rig/ exists for. Every figure in this document was computed from frames captured by this analysis's own author, on hardware they own, and section 13 records that no independent measurement exists anywhere. That is the largest gap in the work, and re-reading cannot close it. Sensor noise is a property of the individual die, so a fifth unit is worth more than a fifth argument. The rig's build script is provenance-gated: it pins the app and OS layers to upstream release tags and refuses any ref it cannot trace to the upstream remote, and an override stamps the deviation into a PROVENANCE.txt that ships with the data (section 3).

How to report a finding

Cite the claim ID it contradicts, state which estimator and which run (with its dataN/ prefix) you used, and give the command that reproduces your figure. A finding that moves a number is more useful than one that disputes an adjective. The adjudication record states the weakest point of every disposition; those are the places this analysis is most likely wrong, and the intended place to start.

Pin what you reviewed. These documents are revised after publication (every substantive change is recorded in the section 15 corrections list), so name the revision your finding responds to: the commit hash of the analysis repo at the time of review, alongside the SeedSigner release the analysis itself pins (tag 0.8.7 @ e0a80d4b). The hash is on the page: the masthead's Revision entry states the commit this page was deployed from, stamped at deploy time (a raw checkout reads "working copy" there, and the repo's main branch is what this site deploys). A finding that cites its commit stays adjudicable after the documents move: the diff between your commit and current shows exactly what changed underneath your commentary, and commentary against a superseded revision reads as responding to that revision rather than as silently wrong. Findings can be filed as issues on the repo.

2Claim ledger

Every load-bearing claim in both documents, with a stable ID, its status, and where it is established. IDs are the addressing scheme for review and do not change once assigned. IE-S-nn are read from source at a pinned tag, IE-M-nn are measured, IE-I-nn are inferred, IE-A-nn are adjudication entries, IE-L-nn are limitations. A claim whose status chip carries a scope qualifier (a small n, a confound, non-release behavior, a degenerate case, an estimator caveat) wears the amber caveat badge; plain verified claims wear green.

Source claims

Measurement claims

Inferred claims

3Instrumentation and capture provenance

Traced, not just read

Every retained figure comes from instrumented builds of v0.8.7 flashed to real hardware, patched to dump the exact bytes the app feeds into its SHA-256 chain, before any hashing. The patch touches views/tools_views.py and a version stamp; hardware/camera.py is byte-identical to stock, so the capture parameters are the release's own. The instrumentation was verified present in the flashed images rather than merely staged.

The retained population

32 runs in five directories, four physical units, two panel geometries. Units are identified by a truncated SHA-256 of the CPU serial (unit_id), because two are the same board model. The enclosure is part of the measured system in every dark run (it is the first light barrier the lens sees) and is recorded per unit in data2/RUNS.md.

The four units, camera side

Preview-window measurement exists only from patch 21dd1fd3 onward (data3 and later): it logs a SHA-256 digest and timing for every frame in the rolling window, and dumps a sample. The data1/data2 runs predate it; their figures are final-image-only, which their manifests state.

The dumping rule, and the sampling lesson behind it

Hashing every window frame costs nothing and settles the most consequential single number, the distinct count. Dumping every frame would cost tens of MB per lit run, so the dump is a sample: all frames when the window held 20 or fewer, otherwise the first and last 10 plus a first-occurrence representative of every logged digest the positional sample missed, and dumped frames are verified to re-hash to their logged digests.

The digest-coverage clause is load-bearing, and it was learned the hard way: positional sampling over a near-constant window loses exactly the frames that matter. A dark window can hold one live frame at an arbitrary interior index; a first-N/last-N rule silently drops it, and with it the only evidence of what the layer contributed. The rule that dumps a representative of every digest is why rare mid-window live frames (indices 13, 29, 37 in various runs) exist in the retained data at all.

Conditions

Dark rounds: face-down at one desk position chosen to sit in shadow, three consecutive runs per board, device not lifted between them, so they isolate same-scene new-session variance; one lit control per board. Engineered rounds (data2): occlusion methods, their caveats (heat, the cord aperture) and the temperature question are documented in that manifest, including why temperature was deliberately not pursued (cycling a camera through a large temperature change condenses moisture inside the lens assembly and wrecks the measurement). White wall (data5): the most well-lit blank-wall area available, operator casting no shadow, natural overcast morning light, one handheld and one stationary run. Sensor temperature is unmeasured in every run (IE-L-06).

4Method: estimators and accounting

Why no randomness tests were run

Every SeedSigner entropy path ends in SHA-256. A SHA-256 output is statistically perfect regardless of its input, so a randomness test applied to the result cannot distinguish a rich input from an impoverished one. The same limitation applies to single images: a near-black photograph has abundant byte-level structure that scores well on distribution tests while carrying almost no unpredictability. The question asked throughout is therefore:

Across repeated captures of an unchanging scene, how much does the image actually change, and how many of the chained frames carried anything at all?

Whatever does not change between captures cannot be entropy.

Final images: most-common-value min-entropy

An attacker guessing seeds is limited by min-entropy, the probability of the single most likely outcome. analyze_mcv.py implements NIST SP 800-90B §6.3.1 on the value-by-value difference between two captures, including the 99% upper confidence bound on the modal probability, which is not optional: omitting it overstates the floor by 1.7–21% on this data, growing exactly as the margin shrinks. The reported figure per series is the worst of all 45 pairs, selected on the estimator being reported. The script refuses series containing byte-identical frames, because for a final-image burst a duplicate means the instrumentation failed.

Differences are signed (later − earlier), and the domain matters on lit series. Signed, absolute and modular-256 differences agree only while the modal difference is 0 and the zeros outnumber the ±1s: that holds for every dark series here (the 113-bit run scores 113 in either domain), but fails for lit ones, where taking absolute values moves the mode to 1 and drops the bookshelf baseline from 1,505,982 to 1,156,876 bits, 23% low. A recomputation that does not match a lit figure should check its difference domain before filing anything.

Preview windows: structure first, entropy second

analyze_preview.py reports the window's digest structure from the log (distinct count over all slots, not just the dumped sample), classifies each distinct frame's content (a constant frame is reported with its value; a live frame with its nonzero profile), verifies dumped frames re-hash to their logged digests, and computes pairwise MCV among distinct dumped frames only. Duplicates are reported as the finding, not refused as an error: the same guard that protects a final-image burst would hide the most important result in a window. Digest-count facts are exact and carry no estimator caveat.

Chain totals

Computed under the accounting rules in the brief. Three standing caveats, all leaning the same direction: MCV over-estimates the floor; multiplying a pairwise figure by the distinct-frame count overstates, because conditioning on several known frames tells an attacker more than conditioning on one; and summing layers assumes an independence the coupling measurement shows is imperfect (IE-M-11). Every total leans optimistic, which matters most for the thinnest rows.

5Results

VERIFIED by measurement. Shipping path, picamera/MMAL stack, upstream-pinned builds. Every figure recomputes from the raw frames shipped with this document (section 14). A 24-word seed requires 256 bits, a 12-word seed 128 (IE-S-03). All entropy figures are worst-of-45-pairs MCV, in bits. Light-present rows (by the IE-M-17 discriminator) are flagged: their figures are inflated by stray light and are not dark measurements.

Properly dark runs (blocked lens): window structure and finals

Reading the table:

• The dominant slot content in every dark window is the computable constant (IE-M-03): 46–50 of 50 slots on the 240 px units held the constant or a cached repeat, with the repeats in long unbroken stretches (47 of 49 consecutive pairs identical in one run), which is the signature of quantization, not of oversampling.
• Four final images sit below 256 (113, 177, 190, 221), every one in a window that also held live frames; the preview-zero windows happened to sit over thicker finals. Which layer is thin tracks the unit's gain rail (IE-M-09), not anything the code controls.
• Same-configuration session variance is enormous: 26,318 against 113 and 221 on one unit, minutes apart, nothing moved.

Chain totals, dark runs

Preview credit per the accounting rules. The two single-live-frame data3 runs are credited by cross-run analogy (their lone frames' worst pairs against other runs' frames) and marked; every data4 credit is a within-run measurement.

Every run clears 256. In the run with the lowest final image ever measured (113 bits), the preview layer carried the seed: the layered design doing exactly its intended work. In the six preview-zero runs the design's headline mechanism contributed nothing and the final image carried everything. Either layer can be the one that carries, and nothing in the code knows which. The 113-bit final also answers the 12-word case: it is the lone sub-128 final image, and it sat in a window holding four live frames; every dark total clears 128 at 3.0× or better.

Lit scenes

• The data1 runs predate preview instrumentation; their windows were chained but not logged (manifest).
• The white-wall rows are the featureless-scene answer (IE-M-13): both finals within 10% of the same unit's bookshelf baseline; the stationary run's 20-slot window (clicked 1.868 s after stream start) fully live and fully distinct with a worst pair of 151,069 bits; the handheld run's seven repeats are adjacent-slot cached doubles (IE-M-08), not scene-related. Lit preview credit is millions of bits under the accounting rules; the caveats change no conclusion at four orders of magnitude.
• Geometry note: the Plus still carries 1.78× the values; per-value it sits in line with the other three (~1.76M equivalent). Compare per-value, never by raw total.

Engineered dark floor (data2)

Nine retained runs across all four units, lens occluded by escalating methods, selection by the on-device review screen (repeat until it displayed pure black). Full tables, including the two-population split, the deleted light-present runs' statistics and the occlusion caveats, are in data2/RUNS.md.

Camera-down on the first gel pack

Second pack over it, seal complete

What this round established, in order of importance:

• The best-sealed run measured 173 bits, below 256 (gel-pack seal at the lens inside a closed refrigerator; the packs were room temperature and are sealing material, not coolant). The seal effect replicated on a second unit (423), roughly halving the changed-value count on both.
• The engineered condition was never a floor (IE-M-14): ordinary shadow later reached 113 with no equipment. The manifest carries this amendment explicitly.
• Run-to-run variance under one unchanged method is 6.6× on one unit (384 to 2,527), which is why single careful runs cannot bound anything (IE-L-04).
• The review-screen simulation over these runs is the basis of IE-M-15: within this round, finals displaying pure black occur in runs from 173 to 36,462 bits, and the display class flickers between consecutive finals of one unchanged setup.
• The Plus unit sits two orders of magnitude higher in every dark table because its residual internal light cannot be excluded: its apparent advantage is a light leak, which is IE-M-17 in miniature.

What the spread means

"Can this fail?" is an existence question, and it is answered: yes, reachably. Four sub-256 finals and six zero-contribution windows exist in provenance-recorded data, from conditions requiring no intent. "What do users typically get?" is a distribution question, and it is not answerable from this data: one desk position spanned 113 to 26,318 bits with nothing moved (the high end light-present-flagged, so the swing is imperceptible leak variation, itself part of the answer), and any realistic condition measures one room, one surface, one lamp angle. Measured points are reported as points; the distribution was not characterized, and this document declines to extrapolate from either tail (IE-L-04).

6The preview layer, mechanically

The condensed mechanics behind the section 5 window tables. Everything here is measured on v0.8.7's Python preview loop (PiVideoStream); the loop-rate and stall findings are specific to that loop, while the content findings (quantization collapse, green-plane anatomy) are sensor and pipeline properties that should be expected to carry to any stack watching the same scene (IE-L-09).

1. Two independent rates. The camera produces frames at a configured 24 fps into a latest-frame buffer; the display loop consumes at 8.5–14.1 fps depending on board and panel, appending one frame per iteration (IE-M-07). The window is a rolling last-50 (IE-S-02), so dwell past the fill time refreshes content but adds no frames.
2. No read synchronization. Nothing marks a frame consumed; a starved capture thread on a single-core board re-serves the same buffer (IE-M-08).
3. Dark content collapse. The 240×240 RGBA video-port path has no JPEG stage and quantizes a nearly signal-free frame to literal zeros: most slots hold the computable constant (IE-M-03). The still path quantizes less aggressively, which is why the final image retains a sparse flicker when the window has collapsed entirely.
4. What a live frame is. One global event, the green plane crossing the rounding threshold, with the information in the minority of pixels held back and in which pixels flip between reads (IE-M-10).
5. The knife-edge. Auto-exposure gain, settled per unit, decides whether any live frames exist at all in the dark (IE-M-09, IE-I-05).
6. Common cause, inside and between layers. The darkness that collapses the window thins the final image and the surviving live frames' novelty simultaneously (IE-M-05, IE-M-10), and the layers are weakly positively coupled (IE-M-11). Layer count is not independence.

7Every release, checked

Image entropy shipped in v0.4.3 (2021-07-31), commit d7bea686, via PR #46. Every release since has been examined. Full working: 10-image-entropy-history.md.

v0.4.6, v0.5.1 and v0.6.0 are byte-identical to their predecessors in this path. v0.4.5's two update_last_input_time() calls are screensaver bookkeeping with no entropy effect.

For a user with an older seed: anything generated on v0.4.4 or later, from August 2021 onward, went through the identical chain composition that ships in v0.8.7. The dark findings in this document apply to every one of those releases alike; they are properties of the sensor and scene, not of a version.

8Two routes to a one-layer chain

The four-input chain is designed as redundant layers. Two demonstrated, independent, accidental routes reduce it to one meaningful input, and they compound with each other.

Route 1: a blocked lens (probabilistic, per-unit)

Measured in section 5: the window collapses to the computable constant, entirely on the below-rail unit (six of six), nearly on the railed units (2–5 distinct of 50). The seed rests on the final image, which the same light starvation has thinned; the thinnest measured result is the 389-bit / 1.52× chain (IE-M-04). Reaching it took setting the device down lens-down on a desk in shadow.

Route 2: a held button (deterministic, any lighting)

VERIFIED (IE-M-06). Each preview-loop iteration reads a frame, paints it, checks the buttons, and only then appends:

frame: Image = self.camera.read_video_stream(as_image=True)
...
self.renderer.canvas.paste(frame.crop(box=box))   # displayed
if self.hw_inputs.check_for_low(keys=HardwareButtonsConstants.KEYS__ANYCLICK):
    ...
    return preview_images                          # returns here
...
preview_images.append(frame)                       # never reached

A button already held when the screen opens is seen on the first iteration (IE-S-06), before anything is appended, so an empty list returns every time: zero preview frames, 10 of 10 measured captures, on both boards tested. The frame is displayed regardless, so nothing observable distinguishes it from a normal capture. Origin: a v0.7.0 crash fix (IE-S-07); the discussion on that PR is entirely about the crash, and the silent path it created went unnoticed until instrumentation.

What would fix it, and what would not

• Append before checking the button (or require a released edge). Small, closes route 2 completely. It does nothing for route 1.
• An entropy health check on frame content: a minimum count of distinct frame digests in the window before a capture is accepted. This is the fix the measurements actually argue for, because it addresses both routes and the mechanism behind them. Guaranteeing frame count fixes nothing: in the dark the appended frames are a known constant, and fifty copies of it carry zero. The check must be on content distinctness, which the digest data shows is cheap to compute and cleanly separates every measured dark window (1–5 distinct) from every measured lit one (20–50 distinct).
• A distinct-digest floor also subsumes the stale-frame concern (IE-I-04) and would have flagged every degenerate window in this document.

These are recommendations to the project, stated as the measurements support them. Whether and how they land is a project decision; nothing in this document depends on their adoption.

9Other edge cases

Bright light

INFERRED, not measured here (IE-I-03). Saturation clips the photosite wells and truncates frame-to-frame variation. The mechanism is clipping, not brightness: the lit scenes measured here are bright and produced the largest figures in the document. Ordinary well-lit scenes are not a problem; deliberate saturation takes deliberate effort.

Fixed sensor pattern

Every CMOS sensor carries a fixed-pattern component (bias, hot pixels, PRNU), stable enough that forensics identifies individual cameras by it. It is predictable, so it carries no entropy, and the difference-based estimator cancels it by construction: a fixed component appears identically in both frames and subtracts to zero.

The worry that the cancellation is artificially narrowing the estimate was measured and does not hold: differencing frames from two physically different sensors gave 266 bits against 173 for one of those units against itself, the same order rather than a leap. At these light levels there is no signal for PRNU to modulate. Within-burst (173), across sessions on one device (167) and across devices (266) are separate conditions, not a ranking; reading structure into their ordering over-interprets order statistics. (The cross-condition pairings were drawn from the engineered-seal round's frames but not recorded, so treat 167 and 266 as order-of-magnitude illustrations rather than recomputable figures.)

A finger over the lens

A finger over the lens is not a dark condition; it is a dim red-lit scene. Flesh transmits red and near-infrared strongly (the fingertip-over-flashlight effect, the mechanism pulse oximetry rides on), blood flow modulates it over time, and the transmission is clearly visible in the live preview. It therefore sits brighter than face-down-in-shadow and cannot probe the thin-final-image regime, which is why the 2026-08-06 rounds deliberately skipped it as redundant rather than severe.

The review screen shows black

Covered by IE-M-15: a display-side light test with no entropy effect and no entropy information, recorded here because a dark capture showing an unchanged black review screen also looks exactly like a dead camera, and will be reported as one.

10Adjudication record

11Traps: claims that look right and are not

Each of these is a reading that survives a careless check. They are listed because a reviewer who walks into one will produce a confident finding that costs time to unwind, and because several of them caught this analysis during drafting.

These are drafting traps, not published corrections. Corrections made after publication are recorded separately, in section 15.

12What we did not verify

1. IE-L-01 · No full NIST SP 800-90B assessment. Only the most-common-value estimator was run, and it assumes IID data that this is not. The permutation testing, the nine other non-IID estimators and a physical noise model have not been done, and all of them can only lower the figures. This caveat binds every margin in the document, most heavily the 1.52× headline.
2. IE-L-02 · The chain totals compound optimistic assumptions. Distinct-count × worst-pair overstates (conditioning on several known frames tells an attacker more than one), and summing layers assumes an independence measured to be imperfect (IE-M-11).
3. IE-L-03 · The gain knife-edge is a correlation over four units, confounded with board family, sensor unit and enclosure, however unanimous across sessions and boots. The mechanism (IE-I-05) is inferred, not isolated.
4. IE-L-04 · The distribution question is unanswerable from this data. One desk position spanned 113 to 26,318 bits with nothing moved; one unit spanned 384 to 2,527 under one unchanged engineered method. Measured points are points. Nothing here says what a typical user gets, and no figure should be quoted as if it does.
5. IE-L-05 · Two runs' preview credits rest on a cross-run analogy. data3/000303-6b66 and data3/000031-6b66 hold a single live frame each, so they have no within-run pair; their credits use cross-run worst pairs. This is the one estimate-by-analogy the accounting carries, it is intrinsic to single-live-frame windows rather than a harness artifact, and those two totals should be read as weaker than the rest. It is also the through-line to the distinct-digest recommendation: a window with one live frame has no within-window way to price itself.
6. IE-L-06 · Sensor temperature is uncontrolled in every figure. No run carries temperature telemetry. Testing it safely requires sealed desiccated equilibration (condensation inside the lens assembly otherwise wrecks the measurement); the data2 manifest records why this was deliberately not pursued, and the direction of the effect is inferred from physics rather than measured.
7. IE-L-07 · time.time()'s 25–30 bits is an estimate from mechanism, not a measurement, which is why it is excluded from totals rather than credited (IE-I-02).
8. IE-L-08 · Scene and occlusion descriptions are operator-supplied. The instrumentation records pixel statistics, exposure and gain; what was in front of the lens and how it was occluded is recorded by the operator in the manifests and cannot be checked against the data beyond the pixel-band discriminator. The data2 seal arrangement and each unit's enclosure are now photo-documented (§3, §5), which narrows this for that round but does not close it.
9. IE-L-09 · The loop-rate and stall findings are specific to v0.8.7's Python preview loop. A different camera stack or preview implementation changes them. The content findings (dark quantization collapse, green-plane anatomy) are sensor and pipeline properties expected to carry, but "expected" is not "measured".
10. IE-L-10 · The white-wall series is n=2: one unit, one wall, one morning, natural light. The conclusion it supports is a refutation (featureless does not imply degenerate), which two runs can carry; it does not characterize featureless scenes in general.
11. IE-L-11 · Memory handling. Entropy buffers are dereferenced but never scrubbed, in any release. Out of scope given the threat model, but unexamined.
12. IE-L-12 · No release-tagged test coverage of the chain composition exists, in any version.
13. IE-L-13 · Scope is image entropy only. Dice and coin-flip entropy, transaction signing and everything else are outside this analysis.
14. IE-L-14 · The middle of the illumination axis is unmeasured. The measured populations are ordinary lit scenes and effectively total light exclusion (the properly-dark band). Genuinely dim ambient conditions, a dim room or dusk, sit between them and were never captured; nothing in this document characterizes them, in either direction.

13External analyses

Independent analyses, measurements or validations of SeedSigner's image entropy that we are aware of:

None, at the time of writing.

There is no published external review of this path: no independent measurement, no third-party reproduction of the figures here, and no prior analysis to check this one against. Every figure rests on captures taken by its own author, and the adversarial review it has had was commissioned by that author.

To submit findings, or to have published work listed here: open an issue on the analysis repo. Name the revision your work responds to (the repo commit hash at the time of review, per the reporting guidance) as well as the SeedSigner release you measured, and include your own provenance record if you captured frames. The cited commit is what keeps your work aligned with the version it examined when these documents are later revised.

14How to check this yourself

From the published frames, no hardware needed

All 32 runs ship in full (~340 MB), each with its on-device capture.log, under per-round provenance records. Every figure in section 5 comes back out of them:

# final images, min-entropy, every retained series
python3 analyze_mcv.py

# preview-window structure, per run (data3 onward)
python3 analyze_preview.py data3/burst-19700101-000150-6b66
python3 analyze_preview.py data4/burst-19700101-000117-934f
python3 analyze_preview.py data5/burst-19700101-000306-6b66

# the attacker-computable dark constant, from nothing but the panel size
python3 -c "import hashlib; print(hashlib.sha256(bytes([0,0,0,255])*57600).hexdigest()[:8])"   # 6f77f852
python3 -c "import hashlib; print(hashlib.sha256(bytes([0,0,0,255])*102400).hexdigest()[:8])"  # b71fb8a8

Final frames are raw RGB888 (np.fromfile(p, np.uint8).reshape(480, 480, 3), or 640 for the Plus); preview frames are panel-sized RGBA. Both analyzers validate before reporting: analyze_mcv.py refuses duplicate frames (right for final bursts), analyze_preview.py reports them (right for windows), and the latter re-hashes every dumped frame against its logged digest.

From scratch, on hardware

The instrumented build is packaged in capture-rig/: a one-shot, provenance-gated build script, a verifier that reads the app source back out of the finished artifact rather than trusting the staged tree, and the patches themselves: the burst instrumentation, plus a no-seed kill-switch (added 2026-08-07) that deletes the image-to-mnemonic conversion so a capture build cannot turn the bytes it just dumped into a seed. The build refuses refs it cannot trace to the upstream remotes and stamps any override into the PROVENANCE.txt shipped with the data; it also refuses an OS tree without BR2_PACKAGE_PYTHON_PICAMERA=y, because without that package the release's capture path cannot run at all. Flash, boot, and confirm the splash reads a -BURST-DEBUG version before trusting anything. One run is New Seed → Image entropy, about a minute.

What would be worth the most

Traps for anyone repeating this work, all of which have bitten it

• Check for light leaks before believing any dark figure. Contamination inflates, so the failure mode is a reassuring wrong answer (IE-M-17). Use the pixel-band discriminator (share of first-frame values ≥ 4), the edge gradient, and the AE gain; a run that locked gain low saw light the operator did not.
• Do the analysis off-device. Hashing inside the capture loop stretched the burst inter-frame gap from ~0.59 s to 3.2 s. Log timestamps and digests; dump frames; compute later.
• Never sample a window positionally. First-N/last-N loses the rare interior live frames that are the entire finding in a dark window (section 3). Dump a representative of every distinct digest.
• Dedupe by content, not by assumption. The stream re-serves buffers (IE-M-08), and newer stacks re-deliver frames when polled faster than the frame rate. Verify every frame hash; classify repeats as constant (quantization) or live (caching) before drawing any conclusion.
• Mind the auto-exposure window. capture_frame() freezes AE on first call, so one AE state governs a burst, and v0.8.7's own window is 0.25 s. A rig that quietly allows more measures a different, and in the dark a better-looking, device (IE-M-18).
• Import runs into per-session directories. Elapsed-time run names collide across devices and across boots of one device; an import overwrote and destroyed a capture set once in this work.
• Source camera behavior from the release's own stack, nothing else. seedsigner-os at v0.8.7 ships BR2_PACKAGE_PYTHON_PICAMERA=y and boots start_x=1: the pipeline is picamera 1.13 over MMAL, and documentation for any other Raspberry Pi camera stack describes a pipeline this release does not run.

Working notes

Served raw rather than rendered, and intended for a reviewer rather than a reader: the per-directory RUNS.md manifests (the curated ground truth for every figure here), and 10-image-entropy-history.md, the per-tag working behind section 7. The build, capture and validation procedure is capture-rig/README.md.

15Scope and provenance

Models used

The coordinating session was switched between models during setup, so this document declines to assert a single exact model string for that role rather than guess. The subagent and review models were selected explicitly per task and are stated with certainty.

Review status

An earlier draft of this analysis, built on a since-superseded capture population, went through a hostile-reader review by a separate agent with no involvement in producing it: it re-ran the analysis from raw captures, checked every cited source line at the pinned tag, and its findings changed that draft in substance. The measurement-methodology lessons that came out of that pass and the subsequent rebuild are recorded in the repository's knowledge documents and are baked into the analyzers (the confidence bound, worst-of-all-pairs selection, the duplicate-guard split, the digest-coverage dumping rule).

The rebuilt documents and population went through an independent adversarial pass on 2026-08-07: three fresh-context Claude Fable 5 reviewers with no involvement in the drafting, one recomputing every figure from the shipped frames with its own tooling (not only the shipped analyzers), one attacking claims, logic and convention compliance, one verifying every source claim against the pinned tags. Every finding was re-verified by recomputation before any change was made. Confirmed clean: all 32 runs' figures, all 15 chain totals, both computable constants, every caption statistic, every cited source line and commit/PR attribution, and the release-history code claims. What the pass changed, applied the same day: the v0.4.5 rotation claim (PIL rotate(90) on the era's non-square final crops a third of the scene and injects constant fill, so "rotation permutes pixels" was wrong for v0.4.5–v0.8.5, and "earlier releases were larger" became "no release gave the chain less scene content"); the verdict's scope (restricted to chains that were fully measured, because the engineered-seal round's chains are indeterminate); the review-screen spans restated per-frame (both display classes occur across runs from 113 to 36,462 bits); the AE-gain corroborant demoted to one-directional; a set of range and count corrections (lit floor 1.3M, live-live novelty 469–1,428 properly dark, loop rate to 11.6 fps, sixteen occlusion runs, one 179× multiplier, 2–5 distinct frames on railed units, a 45-slot constant plus one cached live repeat in the 113-bit window); the sub-256 finals attributed to one board rather than two; and corpus-wide final-image uniqueness verified globally, upgrading IE-M-16. One finding was declined: retired figures quoted inside manifest supersession notes remain there deliberately, as supersession records. Claims with no deterministic reproduction path from the shipped data are now marked as such where they stand (IE-M-01, IE-M-02's block statistics, IE-M-18, the cross-sensor pattern-noise figures, and IE-M-06, whose held-button captures were not retained).

Corrections after publication will be recorded here, with what changed and why. Errors caught during drafting are in section 11 as reviewer aid, which is a different thing and is not presented as a correction history.

• 2026-08-07, difference domain made explicit. Added a paragraph to section 4 and a row to the traps table: published figures difference in the signed domain (later − earlier), and recomputing a lit series over absolute values lands 20–35% low. Dark series are domain-invariant. A clarification for anyone recomputing; no published figure changed.
• 2026-08-07, no-seed kill-switch added to the capture rig. A second patch, 0.8.7-no-seed-kill-switch.patch (04ae1136), deletes the image-to-mnemonic conversion so a capture build cannot turn the bytes it writes to the microSD into a seed, and verify-image.py now requires it. The burst patch (21dd1fd3) is unchanged, the published data predates the kill-switch, and no measurement or figure is affected. Section 14 was updated to match.
• 2026-08-07, reviewer versioning guidance. The reporting guidance, the masthead review prompt and section 13 now ask external reviewers to cite the analysis repo commit they reviewed, alongside the pinned SeedSigner release, so commentary against a later-revised document reads as responding to the revision it examined rather than as silently wrong. To make that hash visible, both mastheads gained a Revision entry, stamped with the deployed commit by the Pages workflow at deploy time. Process only; no claim, figure or measurement changed.

Figure parameters

All figures appear in the analysis; their parameters are recorded here, and every plate regenerates from the shipped raw frames via the named script. No plate uses autocontrast or per-image normalization.

Lit bookshelf plates (make_figures_lit.py). data1/burst-19700101-000303 frames 00 and 01, 480×480 RGB888 as dumped before hashing. Differences are |a − b| at fixed linear gains of ×12 and ×40 with clipping. Detail crops are 96×96 at offset (150, 60), scaled 6× nearest-neighbor; the two blink crops also ship as unquantized stills (14_lit_detail_frame00.png, 15_lit_detail_frame01.png) so the comparator can be checked frame by frame. The social-sharing card (social_card.png, 1200×630, the analysis page's og:image) is the as-shot frame 00 and the ×40 difference side by side, both full frame (no crop), scaled to 596×596 (LANCZOS for the photograph, nearest-neighbor for the difference) on a black 1200×630 canvas; neither panel carries processing the published plates do not, beyond the JPEG encode (quality 88) that keeps the card under messenger size limits.

Rig photographs (rig_01…, rig_02…, rig_03…). Operator photographs of the data2 occlusion arrangement and the four units' camera-side enclosures, resized to 1400 px long edge (JPEG, quality 85) and otherwise unedited. They are documentation of the apparatus, not measurement exhibits; the full-resolution originals are retained outside the repository.

Blank-wall plates (make_figures_whitewall.py). data5/burst-19700101-000306-6b66 frames 03 and 06, the run's worst pair by MCV, selected on the estimator reported. Same gains (×12, ×40) and treatment as the bookshelf plates so the two sets compare directly. Detail crop 96×96 at offset (192, 192), scaled 6× nearest-neighbor. The wall is white; auto white balance renders the pale blue-green cast, and the radial gradient is part window light, part the optical system's natural vignetting.

Dark plates (make_figures_dark150.py). data3/burst-19700101-000150-6b66. Final-image plates are the worst pair (frames 00 and 06, 105 changed values), as shot and at fixed linear gain ×60 with clipping; their difference is ×60 and 5×5 max-dilated, because undilated its 105 values are invisible, and the caption states the dilation. Preview plates are live frame 18 (×60) and the 18-vs-19 difference (×60, no dilation). The review-screen plate (dark_review_stretch_frame08.png) is ImageOps.autocontrast(cutoff=2) applied to stock frame 08 of the same run, with no gain or other processing, rendered at Pillow 11.0.0, the version the release ships: the identity-vs-stretch threshold is version-sensitive (IE-M-15), so regenerate that plate at that version. The black constant is stated in captions and deliberately not shown as an image: a picture of pure black communicates nothing its digest does not.

The blink comparators (13_lit_detail_blink.png, whitewall_detail_blink.png) are animated PNGs alternating two detail crops every 500 ms. APNG rather than GIF, deliberately: GIF's 256-color palette would quantize away much of the change (in testing, a shared 256-color palette lost more than half the crop's differing pixels). APNG is lossless, so every pixel that appears to move is a pixel that moved. Each frame carries a caption strip added below the image, never over it, blue for capture 1 and orange for capture 2 (#1B4B7A / #C1621E, 46 px): the standard colorblind-safe opposed pair, kept clear of the series' semantic colors, where a green-versus-red pair on two equally valid captures would read as pass-versus-fail. Browsers without APNG support show the first frame.