0ab90a01cb26b9191e2ba4414d1a124d3b5ec832
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  steveandClaude Opus 4.8
|
0ab90a01cb |
EXIF orientation: bake it in when normalizing images (#103)
imagenorm decoded and re-encoded to JPEG but ignored the EXIF Orientation tag. Phone cameras store the sensor pixels one way and set an EXIF flag to rotate on display, so a "portrait" JPEG is really a landscape bitmap tagged "rotate 90°" — and our re-encode strips EXIF, so without baking the rotation in, a packet photographed in portrait reaches the vision model sideways (bad OCR) and any future thumbnail is wrong. - exifOrientation: a small pure-Go parser that walks the JPEG APP1/Exif segment for tag 0x0112, returning 1 (normal) for non-JPEG or unparseable input — never guess a rotation onto a correct image. No cgo, no new dep. - applyOrientation: bakes in all 8 orientations (the 4 rotations + mirrors) after downscale (cheaper to rotate the small image; a 90° turn swaps the sides but not the longest edge, so the downscale bound still holds). - Non-JPEG paths (HEIC/webp/png) are untouched — their decoders own orientation and they carry no JPEG EXIF. Tests build oriented JPEGs (a corner marker + a spliced Exif APP1) and assert the marker lands where each orientation says, dims swapping for the quarter-turns; plus parser defaults for non-JPEG / no-EXIF / garbage. Stays CGO_ENABLED=0. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |
||
|
steveandClaude Opus 4.8
|
cb594f34d8 |
Address Gadfly findings on #80
Build image / build-and-push (push) Successful in 6s
Security / correctness (multi-model): - Wrap the decoders in a recover (decodeSafely): a malformed HEIC/WebP that panics libheif-via-WASM or x/image/webp now fails this one request as ErrUnsupported instead of taking the process down. - Make the pixel-bomb guard overflow-safe: check each side against maxDimension BEFORE multiplying, so a header claiming ~2^32 on a side can't wrap int64(w)*int64(h) negative and slip past the pixel-count cap. - Lower maxDecodePixels 100 MP → 50 MP (~200 MB peak), still above any current phone sensor, capping the amplification a small hostile header can force. - Sentinel errors use errors.New, not fmt.Errorf without a verb. The finding 5 models agreed on: the decompression-bomb guard was UNTESTED and a stale comment implied otherwise. Added TestNormalizeRejectsPixelBomb, which crafts a ~40-byte PNG (valid IHDR + CRC) claiming a huge canvas and asserts ErrTooLarge from DecodeConfig alone, before any bitmap is allocated — covering both the per-side and the area trip. Fixed the stale comment. Error-handling / docs: - format is now "" on ALL error paths (was populated on some, empty on others). - Doc rewritten to state the actual error contract (read/encode I/O → wrapped, not a sentinel) and to stop referencing a non-existent TestNormalize / TODO. - Guard io.LimitReader's +1 against an int64 overflow at an absurd MaxBytes. Tests / provenance: - Downscale test derives its numbers from DefaultMaxDim instead of hard-coding. - Check the previously-ignored DecodeConfig error in the small-image case. - testdata/README documents where sample.heic/webp came from. Deferred to the #81 upload handler, documented in the Normalize doc: EXIF orientation (best fixed and tested with a real oriented photo end-to-end) and context cancellation (image.Decode isn't cancellable mid-decode; the caller runs it under a timeout, and the size guards keep the work finite regardless). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |
||
|
steveandClaude Opus 4.8
|
74f6b9a876 |
Image normalization package: decode HEIC/webp/png/jpeg → JPEG (#80)
Prerequisite for seed-packet capture (#81). majordomo's media pipeline is stdlib-based and cannot decode HEIC or webp — and HEIC is the iPhone camera default, so the capture feature's very first input would fail on the device that motivates it. Normalizing at the upload boundary means everything downstream only ever sees JPEG. internal/imagenorm.Normalize(reader, opts) decodes any of jpeg/png/heic/webp, downscales to fit MaxDim (2048, ollama-cloud's limit) on the longest edge with Catmull-Rom (sharp on the text a packet is mostly made of), and re-encodes JPEG. CGO stays off: github.com/gen2brain/heic runs libheif as WASM via wazero (pure Go), golang.org/x/image/webp is pure Go. Both register with image.Decode. The ~5 MB these add only links into the binary when #81 imports this package — it's not pulled into cmd/pansy yet, so main is unchanged in size for now. Guards against hostile uploads: input capped at MaxBytes (ErrTooLarge) before a full read, and the decoded pixel count checked from DecodeConfig BEFORE the bitmap is allocated, so a small file claiming a huge canvas (a decompression bomb) is refused up front. TestNormalizeAllFormats round-trips all four formats to a valid JPEG — its real job is catching a dropped blank import, where the intuition-breaking failure is that the COMMON format (png) breaks while the exotic one (heic) still works. heic/webp fixtures live in testdata (Go has no encoder for them); the webp is a known-good 16x16 from Python's stdlib test corpus, verified to decode. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |