llm-ingestion-okf/docs/2026-09-18-bildestien-holder-0-10-1.md

The image path, second review: the bound bound a claim, not a cost

A second independent review, one day after the first, read 230d1cb — the commit that closed the two MAJOR findings of the v0.10.0 review — and found that one of the two was not closed. This is what that review found, what it measured, and what this round changed. It is the round that makes v0.10.1 true; the round it corrects is docs/2026-09-17-bildestien-0-10-1.md, which now carries a correction block where it claimed this defence.

What was wrong: a declared size and a decompressed stream are two numbers

check_size read /Width and /Height out of a PDF image dictionary and refused anything over MAX_IMAGE_PIXELS. Both numbers are written by the document. /Length beside them is the compressed length, and nothing in the dictionary states what stream.get_data() will return. A document that declares 1 x 1 and hangs 400 MB of deflated zeros off it therefore passed the check, paid the whole cost, and was carried as a one-pixel picture.

Measured on 230d1cb, and re-measured here on ed8d9d7 before anything changed, with the same fixture in its own interpreter:

stream inflates to	file size	declared	carried	rejection	peak RSS
400 MB	408 516 B	1 x 1	yes	none	891 904 000 B
1,2 GB	1 223 843 B	1 x 1	yes	none	2 436 MB (review)

About 2 100x the file size, linear, so a 10 MB document is roughly 21 GB. It is the failure mode the first review named — one document killing a batch build — reached through the other number.

The first round's four mutations were all killed by its tests, and that told us nothing about this: not one of them separated a declared size from an actual one. A test built on an honest 20000 x 20000 declaration is green whether or not the stream is bounded.

What changed: three numbers are bounded, and the limit is stated

CORRECTION, 2026-09-18 (same day, later) — point 3 below bounded ONE LINK of a filter chain, not the chain. A PM checkpoint of 0f308c1 measured /Filter [/FlateDecode /FlateDecode]: 1 636 bytes of file, 889 573 376 bytes of peak RSS, still refused at the end by the backstop after the memory was spent. The sentence below that the measurement "runs before get_data()" is true; the sentence in the section after it, that the measurement covers the case where "FlateDecode is the first filter", was a bound on the first link and was therefore not a bound. The round that closes it, with the three classes of filter and the refusal for the ones no chunked measurement can reach, is docs/2026-09-18-filterkjeden-og-backstoppen.md. That round also found the backstop this paragraph leans on had no test at all: deleting it passed all 2 132 tests.

1. What the container DECLARES — unchanged from the first round.
2. What a carried FILE measures — new. read_image now checks the size it sniffs out of the header. This package never decodes such a file, so it pays nothing for it; but a 7 000 x 7 000 PNG of 47 705 bytes written into a bundle hands the consumer the same bomb with 7000x7000 px printed beside it, and the README's first sentence about this bound said such an image was refused. Over the 4 828 image objects of the reference corpus the largest is 18.6 MP, so nothing measured is refused by this.
3. What a PDF image's STREAM decompresses to — new, and the finding. assets.inflated_size inflates the raw stream a chunk at a time, keeps only a running total, and discards the output, so the measurement cannot cost what the bomb costs. It runs before get_data().

The limit is stated, not implied. The stream measurement runs where FlateDecode is the first filter and the document is not encrypted (the raw bytes are ciphertext until pdfminer deciphers them). Every other filter chain is caught by check_payload(len(data)) after get_data() — a counted refusal, not a bounded one: the memory is spent and then the picture is dropped. That distinction is the whole substance of this round, so it is written in _check_inflated's docstring rather than left for the next reviewer to find.

A legitimate image is therefore inflated twice, once to measure and once to carry. That is the price of not holding an unbounded buffer in order to find out how big it is, and at this sample it does not show: three PDFs of the K2 reference corpus, 800 carried images between them, extracted twice in one process with the measurement on and off.

document	images	rejections	with the bound	without
Bilag 3.1 Miljøteknisk rapport	464	0	18.21 s	18.51 s
Bilag 1 Kravspesifikasjon	311	12	16.28 s	16.88 s
Bilag 3.3.1 Brannkonsept	25	0	2.70 s	2.35 s

The bounded arm is faster on two of the three and slower on the third, which is run-to-run noise rather than a speedup: the honest reading is that a second inflate of these streams is below the noise floor of a PDF extraction that is dominated by text layout. What is NOT noise is that the fate of every image is identical on both arms — 464/464, 311/311 with the same 12 rejections, and 25/25 — so the bound refuses nothing these documents carry.

A declared size that is not a size

/Width -1 /Height 40000000000 multiplies to a negative pixel count, under which every > bound reads as satisfied. check_size returned silently, 400 MB was decompressed, and the refusal arrived from encode_png as asset_samples_invalid — a code about a sample buffer, for a defect in the declaration. A non-positive dimension is now asset_size_invalid, raised before the stream is read.

It gets its own code rather than joining asset_too_large because the two say different things about a document: a publisher shipping a picture larger than this package carries is not a dictionary written to be read wrong, and counting them together would make a corpus statistic about the first untrue. None stays UNKNOWN — a container that declares no size leaves nothing to bound, and inventing a number would refuse a legitimate picture.

The line that says what is missing

Two smaller findings in the same line, both introduced by the first round's fix:

• The address was written twice, once in a code span and once bare, and a GFM/linkify renderer autolinks a bare URL into <a href>. It takes a click rather than a render, so it is weaker than ![...](...) — but "inert" was half true, and half is what that line exists not to be. Written once now.
• The caption was dropped. label stayed in the signature and no branch read it, so the alt text or figure caption of an image the bundle does not carry was lost — a regression against 0.10.0 and against the line's own stated reason for existing (a reader cannot weigh an absence they were never shown). It is written again, in the same -- <label> form a carried pointer uses.

Measured after

Same fixture, same machine, same command, in its own interpreter:

stream inflates to	file size	before	after
400 MB	408 516 B	carried, 891 904 000 B peak	refused asset_too_large, 57 065 472 B peak
1,2 GB	1 223 843 B	carried, 2 436 MB peak	refused asset_too_large, 64 569 344 B peak

The bounded figure barely moves when the stream triples, because what grows is the compressed input, which was already in memory. The cost no longer scales with the bomb, which is the property the first round did not have.

End to end through the shipped CLI, default flags, the bomb beside one ordinary markdown document so the build has a plan to write:

$ /usr/bin/time -l okf build /tmp/okf-r3/in --bundle /tmp/okf-r3/bb \
      --bundle-id t3 --okf-version 0.2
exit=0
            79650816  maximum resident set size
$ ls /tmp/okf-r3/bb/assets
ls: .../assets: No such file or directory
$ grep Images /tmp/okf-r3/bb/log.md
* **Images**: 0 carried of 1 found, ...

The review measured 838 000 640 B and an assets/…-im0.png written after it. The concept says what stood there:

Image: page-1-Im0 (not carried: the stream behind 'page-1-Im0' decompresses to
more than 268435456 bytes from 407685 bytes of input, over this package's
bound; refused without being held, because the size a container declares is a
claim and this is the cost)

The version

v0.10.1 was going to be cut from a tree that said 0.10.0 in nine places: two bound to each other by a test, and seven bound to nothing — four README install lines telling a consumer to install the release before this one, two prose lines about what that tag declares, the "current tag" entry, and a CHANGELOG whose 0.10.1 content sat under [Unreleased].

Two new tests in tests/test_packaging.py bind all of them to llm_ingestion_okf.__version__, plus the guard tag in the README to the one in [tool.uv.sources], which is the same class of instruction going stale. Proven red in the intended way: bumping __version__ and pyproject.toml alone turned the first one red with install lines name ['v0.10.0'].

Not measured

• The 43-document reference corpus was not rebuilt. The render_missing change adds -- <label> to the line for an image a bundle does not carry, so an assets-on corpus build differs on exactly those lines. That is the repair, not a side effect, but its size across that corpus is unmeasured here. What IS measured: 0 shipped artifacts move. No bundle under examples/, skills/ or tests/fixtures/ carries an image pointer of either kind — 0 occurrences of Image: against a known-positive control on the same directories — so both this change and the new read_image bound move zero committed bytes.
• The pinned K2-bundle-default-20260912 predates the image path entirely and cannot move.
• The review's own "not measured" list stands: the content accounting after this change, R761's 50 carried of 50, docx/pptx/xlsx zip-slip, SVG as active content, and the [ocr] path.