5 Commits

Include renames

Author	SHA1	Message	Date
tfaour	015993af00	Add battery level reporting (Kconfig-gated) and display orientation ... Battery (firmware + server, disabled by default): new battery.c reads a 2x200k voltage divider via ADC oneshot with curve-fitting calibration (the ESP32-C6's scheme), maps through a piecewise LiPo discharge curve, and restores the pin to button duty after each read -- the settled XIAO ESP32-C6 design shares the back button's GPIO0/A0, time-shared per wake. Skipped entirely when on mains (a 2x100k VBUS divider into a spare digital pin -- the 5V pin is dead on battery power, so presence = mains, where the charging voltage would read misleadingly full) or when the reading is implausible. The manage overlay gains a battery region (static outline glyph + "NN%", below the manage QR, all menu levels), and the device POSTs to the new /frame/battery endpoint after a successful fetch; the server stores percent + as-of timestamp, exposed via /api/queue and shown in the web UI. FRAME_BATTERY_ADC_GPIO / FRAME_VBUS_SENSE_GPIO default to -1 (fully inert on the dev board); compile-verified both disabled and enabled, hardware bring-up deferred until the ordered XIAO + batteries arrive. Orientation (server-side only): new config setting + web UI dropdown (landscape / portrait / landscape_flipped / portrait_flipped). Photos are composed/cropped at the logical hanging shape (portrait crops at 480x800, so face-aware crops match how the frame actually hangs), then rotated losslessly into the panel's native 800x480 byte layout after dithering -- the device never knows. Face-label anchors are transformed through the same rotation (logical_to_native()) so they stay attached to faces on rotated frames. Known documented limitation: the on-device manage overlay still renders in native orientation, so it appears sideways on a portrait-hung frame (QRs scan at any rotation; text reads sideways).	2026-07-19 22:11:14 -04:00
tfaour	e870898490	Refine manage overlay: US/CAN state abbreviations, share-QR caption, and an escalating second menu with named-face labels ... Two rounds of follow-up work on the manage-button overlay: 1. Location formatting: US/Canada now show abbreviated state/province ("CA", "ON") instead of the full name, other countries show the full country name, and each is its own line (was one line, now wraps to two) so longer international place names have more room without threatening to overlap the top-right QR box. The bottom-left share QR also gets a "SCAN TO DOWNLOAD" caption. 2. Escalating menu: pressing the manage button again while its overlay is already up adds a second level -- each Immich-identified person's name labeled next to their face in the photo (using Immich's own face recognition/People data, no detection/recognition added to this project). A third press exits immediately instead of waiting out the 30s auto-revert timer. No new Immich API needed -- GET /api/faces already embeds a nullable person.name per face; new server/app/face_labels.py maps a named face's box into the final 800x480 frame's pixel space (reusing crop-box math extracted from image_pipeline.py's face-aware cropping). Capped at 4 named faces, sized to a real firmware RAM budget: each label is its own malloc'd overlay region on the device, alongside the 4 fixed corner regions already in use. New GET /frame/face-labels returns a flattened fixed-slot JSON shape (not a real array) so firmware's existing flat-scalar parser can read it without needing an actual array parser. No persistent state needed for the escalation itself -- it's all local control flow within one continuous awake session (frame_client.c's run_management_menu()).	2026-07-19 09:09:06 -04:00
tfaour	f2a374b363	Make face-aware crop minimal-shift instead of full re-centering ... _face_aware_crop_box() previously always centered the crop on the union of all detected faces' centroid, even when the plain center-crop already kept every face fully on screen -- unnecessarily moving a composition that didn't need fixing. Now starts from the plain center-crop and only shifts it the minimum amount needed to bring an otherwise-cropped-out face back into frame; already-fine framing is left untouched (falls back to centering on the faces' midpoint only if they're spread too wide for any single shift to contain them all, which is unchanged from before). Verified: a face safely inside the plain center-crop now produces byte- identical output to the no-shift case (previously it still would have been re-centered); an edge face gets a 100px shift instead of the 1050px a full re-center would have applied. Re-ran against the real 4-face test photo from earlier -- all four were already fully visible, so the refined box now exactly matches the plain center-crop instead of shifting unnecessarily.	2026-07-18 15:46:01 -04:00
tfaour	6e353c2271	Add server-configurable refresh interval + face-aware cropping ... Two features, both toggleable/settable from the web config UI: Refresh interval: new GET /frame/config returns {"refresh_interval_s": ...} as plain JSON. Reuses the endpoint the frame already needs to hit for a reachability check each wake cycle (previously /health) rather than adding a third round trip, and always returns 200 with current settings regardless of Immich-configured state so it stays valid as a pure reachability signal. Clamped to [60, 86400] seconds in POST /api/config. Face-aware cropping: GET /api/faces?id={assetId} on Immich already returns real per-photo face bounding boxes from its own People-feature ML -- confirmed against a live instance, boxes scaled to the asset's native resolution. No face detection built or bundled here at all, just an API call plus rectangle math. image_pipeline.render_frame() gains an optional `faces` param: when present, computes the largest crop window matching the panel's aspect ratio that fits in the source image, centered on the union of all face boxes' centroid (scaled into the downloaded preview's actual resolution) instead of the image's geometric center, clamped to stay within bounds. No faces (or the smart_crop_faces config toggle off) falls straight back to the existing ImageOps.fit() center-crop -- zero behavior change in that case. A faces-lookup failure logs and degrades to center-crop rather than failing the whole request. Verified: unit tests for the crop-box math (horizontal shift toward an off-center face, edge clamping), a full mock-Immich end-to-end pass (extended to serve /faces) confirming the toggle changes output and the response is still exactly 192,000 bytes, and a live comparison against a real 4-face photo on the user's Immich instance (crop top shifted from 528px to 246px toward the detected faces).	2026-07-18 15:32:29 -04:00
tfaour	5e7c47e2eb	Add FastAPI server: pulls from Immich, pre-processes for the panel ... Implements the server side of the architecture decided on: the ESP32-C6 has no PSRAM and a tight RAM budget, so all the heavy lifting (JPEG decode, resize, Floyd-Steinberg dithering, 6-color quantization, 4bpp packing) happens here instead of on-device. The frame just does a single GET and streams the response straight to SPI. - GET /frame/image: looks up the current cursor's asset in the configured Immich album, downloads its preview thumbnail, and returns it packed into the panel's exact 800x480/4bpp/2px-per-byte format (application/octet-stream, always exactly 192,000 bytes). - GET / + POST /api/config + GET /api/albums: a small web UI for entering the Immich URL/API key and picking an album, rather than cramming that into the ESP32's captive portal form. - Config (Immich creds, selected album, cursor) persists to a JSON file via a docker-compose volume mount. Verified locally with a venv (Docker isn't available in this environment): unit-tested image_pipeline against a synthetic image (exact byte count, valid panel color codes only), and ran a full end-to-end pass against a mock Immich HTTP server exercising the real /frame/image path. Pinned dependency versions in requirements.txt after hitting a real bug with unpinned floors: the latest starlette (1.3.1) resolved by `pip install fastapi` breaks Jinja2Templates outright. Not yet wired to the ESP32 side (task 6) or authenticated -- /frame/image is unauthenticated for now, fine on a trusted LAN but worth revisiting once the firmware sends a shared device token.	2026-07-18 14:35:14 -04:00