Progressively load higher-resolution images when zooming in the session detail view

[mihow]

Summary

The session detail view renders captures from a generated "large" (2560px) thumbnail so that detection bounding boxes align with the displayed pixels (see the fix for portrait EXIF-rotated captures). This keeps the initial view fast and correct, but when a user zooms far into a capture, 2560px is noticeably softer than the original file (often 4000px or wider). We should load higher-resolution imagery on demand as the user zooms in.

Proposed behavior

1. The view starts with the large thumbnail, as it does today.
2. When the zoom level crosses a threshold (for example, when the effective on-screen resolution exceeds the thumbnail's native resolution), the original source image is fetched and swapped in underneath the existing zoom/pan transform, similar to how map tiles sharpen as you zoom.
3. The swap should be seamless: keep showing the thumbnail until the full image has loaded, then replace it without resetting the zoom or pan position.

Constraint: EXIF orientation must not regress bounding boxes

The original file can carry an EXIF Orientation tag. Browsers force-apply that rotation to cross-origin images, while detection coordinates are stored in the raw (unrotated) pixel space — this is exactly the bug that moving to thumbnails fixed. Swapping the source image in at high zoom would re-introduce misplaced boxes for those captures.

A simple guard: after the source image loads, compare its reported natural dimensions against the capture's stored width and height. If they are transposed (rotated orientation), skip the swap and stay on the thumbnail. A fuller solution would expose the orientation from the backend and transform the box coordinates to match.

Notes

• The zoom/pan interaction was added in Add zoom and pan support in session detail view #1339; the thumbnail-based rendering and the "large" size were added in the follow-up fix for portrait captures.
• Bandwidth is also worth considering: original files can be several megabytes each, so the swap should only happen on sustained zoom, not on every pinch.

[mihow]

Claude says: Implementation sketch after the discussion on PR #1374, which capped the session detail view at the 2560px "large" thumbnail.

Approach: resolution ladder driven by zoom level

The view keeps a ladder of image tiers — medium (1024) → large (2560) → original — and requests a higher tier whenever the zoom demands more pixels than the current tier provides. All of the pieces exist already; this is frontend-only.

1. Track effective resolution demand. react-zoom-pan-pinch exposes the current scale via onTransformed / the existing transformRef. Demand is container CSS width × devicePixelRatio × scale. When demand exceeds the current tier's native width (with ~1.2× hysteresis so we don't thrash at the boundary), start loading the next tier. Debounce so a pinch gesture settles before any fetch fires.
2. Blurry-first comes for free. The currently displayed tier is already stretched by the zoom transform, so the user immediately sees the upscaled (blurry) image. Render the incoming tier as a second stacked <img> in the same transform container; when its onload fires, crossfade opacity and drop the old one. Zoom/pan state is untouched because both images fill the same transformed container, and the box overlay is percentage-based so it never needs to know which tier is showing.
3. Loading indicator. While a higher tier is in flight, show a small non-blocking pill in a corner of the viewport ("Loading full resolution…") using the existing spinner component — not an overlay that hides the image.
4. EXIF guard for the original tier. The original file can carry an EXIF Orientation tag that browsers force-apply, which would rotate the pixels out of the coordinate space the boxes are drawn in (the bug PR Fix misplaced bounding boxes on portrait captures and add large image thumbnail size #1374 fixed). After the original loads, compare its natural dimensions against the capture's stored width/height: if they are transposed, stay on the large thumbnail. Longer term the backend could expose the orientation so the coordinates can be transformed instead.
5. Initial tier by display, not a constant. Once the ladder exists, the view no longer needs to default to "large": pick the starting tier from container width × devicePixelRatio at mount (medium on a 1× laptop, large on a retina display), and let zooming pull in the rest. That restores the lighter default load without a quality regression.

Scope estimate

A useProgressiveCaptureSrc(capture, transformRef) hook owning the ladder state (current tier, in-flight tier, abort on capture navigation), plus the stacked-image crossfade in the capture component. No backend changes — the original URL and existing thumbnail sizes are sufficient. Roughly 1–2 days including tests and polish.

Open questions:

• Should the original tier ever be fetched on metered/slow connections automatically, or behind a click ("load full resolution")? navigator.connection is only partially supported, so a settings toggle may be simpler.
• Prefetching the next capture's starting tier during navigation would make scrubbing feel instant and could reuse the same hook.