Repository navigation
README: name the decoders, because which one runs is the point - #107
Conversation
It said "a JPEG is decoded by the standard library". That stopped being true when the fork was taken: image.go imports go-images/jpeg, and its own comment says why -- Go's image/jpeg merges a four-component picture's four planes itself and hands back an *image.CMYK, so a caller cannot correct the chroma upsampling afterwards, and on the corpus's 258x258 YCCK picture that is worth 36 levels against 2 on the cyan plate. Two whole codecs were missing as well. The module depends on go-images/jpeg2000 and reaches JBIG2 through go-gfx/gfx/codec, and the section listing what it draws named neither -- while most of the conformance work of the last month has been about exactly those two. So the four filter families are in a table with the decoder each one reaches, since "which decoder runs is the point" is what the code says about itself one line above the import. No code change.
The Testing section said CI gates on "a cross-compile across linux/{amd64,
arm64,riscv64,loong64,ppc64le,s390x}, js/wasm, darwin/arm64 and
windows/amd64", which was true until 2026-09-26 and understates what the
workflow does now: beside that cross-compile there is an arch-qemu job
that RUNS go test ./... on riscv64, loong64, ppc64le, s390x and arm, a 386
lane that runs it natively, and an os-matrix that runs it on macos-latest
and windows-latest.
A README that describes a build where the file beside it runs a test suite
is understating the only thing a reader would want to know -- and the
difference is not academic: those lanes found four defects on 32-bit, one
inexpressible on Linux, and five POSIX-only fixtures.
The 386 lane's reason is carried over from the workflow's own comment,
because "runs natively" without "qemu-i386 loses the guest's floating-point
state across preemption" reads as an arbitrary exception.
No code change.
A second thing the same section had outgrown
True until 2026-09-26, and it understates the workflow beside it. There is also A README describing a build where the file beside it runs a test suite is The 386 lane's reason is carried over from the workflow's own comment, because Verified today across the ten repositories of this stack: 10 of 10 carry all 🤖 Generated with Claude Code |
1 participant
No code change. Independent of #103, #105 and #106 — touches
README.mdonly.What was wrong
That stopped being true when the fork was taken.
image.goimportsgo-images/jpeg, and the comment one line above the call says why:What was missing
Two whole codecs. The module depends on
go-images/jpeg2000and reachesJBIG2 through
go-gfx/gfx/codec, and the section listing what this draws namedneither — while most of the conformance work of the last month has been about
exactly those two.
What it says now
A table of the four filter families against the decoder each one reaches, since
"which decoder runs is the point" is what the code already says about itself,
one line above the import.
🤖 Generated with Claude Code