4 Commits

Include renames

Author	SHA1	Message	Date
steveandClaude Opus 4.8	8aad2278a0	Address EXIF review: single alloc, no per-pixel boxing, hardened parser ... Gadfly on #103: - (4 models) applyOrientation allocated a WxH RGBA then threw it away for a quarter-turn to allocate HxW. Compute the output dims once, allocate one buffer. - (perf) The At/Set loop boxed a color.Color per pixel — millions of heap allocs on a full-res rotation. Convert to *image.RGBA once (draw.Draw) then copy 4 bytes per pixel by offset. No boxing. - (2 findings) exifOrientation didn't skip 0xFF fill bytes before a marker, so a spec-valid padded APP1 would be misread. Skip them. - (2 findings) orientationFromApp1 read the tag's inline value without checking its type/count — a mistyped LONG/offset would be read as a bogus SHORT. Require type=SHORT, count=1; also validate the TIFF 0x2A magic agrees with the byte order. - Tests now cover all 8 orientations (added the mirror/transpose cases 2/4/5/7, the most error-prone switch arms) as t.Run subtests. All imagenorm tests green; gofmt clean; still CGO_ENABLED=0. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ	2026-07-22 01:35:19 -04:00
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	2026-07-22 01:23:08 -04:00
steveandClaude Opus 4.8	cb594f34d8	Address Gadfly findings on #80 ... 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	2026-07-21 23:27:00 -04:00
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	2026-07-21 23:03:40 -04:00