JPG images inverted with respect to tiffs but are correct

[EtalumaSupport]

Choosing jpg for live image format results in images that are inverted from the tiff images. It turns out the tiffs are inverted from reality so the jpg shows the correct orientation. Tiffs are the view from above and should be inverted. Be aware of the effect on tiling.

[SN12064-2026-06-01-063841.zip](https://github.com/user-attachments/files/28467442/SN12064-2026-06-01-063841.zip)

[ericweiner]

good catch.

[ericweiner]

Ready for bench verification

Fix shipped on 4.0.0-beta at 045d0802 (current tip ea4a0c8d) -- JPG live-format saves now share the TIFF save orientation. Previously the TIFF path applied a vertical flip that the JPG export skipped, so JPGs saved upside-down relative to the TIFFs and the tiling pipeline. Both formats now go through one shared orientation step.

Chris, please grab the latest beta build and verify: a JPG-format capture's orientation now matches the corresponding TIFF (and tiling lines up). Then close if resolved, or add a note/log if anything's still off.

Note: this brings JPG in line with TIFF on the current camera. Getting orientation right per camera brand/sensor (so different bodies normalize correctly) is a separate, larger change tracked with the IDS/FX2 camera integration.

[EtalumaSupport]

jpg is now the same as tiff but inverted from reality showing a top down view. Is this what we want or a toggle?

[ericweiner]

Triage / analysis (no fix yet)

Disposition: original bug fixed; the new question is a separate orientation-design decision (decision-gated, folds into the camera-orientation work).

What #690 reported is resolved: JPG and TIFF now share one orientation step (_apply_save_orientation at modules/image_save.py:328/384/515, shipped 045d0802), so JPGs no longer save upside-down relative to TIFFs and tiling. You've confirmed they now match.

The new question ("both are inverted from reality / top-down -- is this what we want or a toggle?") is about which orientation is canonical, which is a per-camera/sensor property, not a per-format one. A JPG-only toggle would re-introduce exactly the JPG-vs-TIFF inconsistency we just removed, so that's the wrong shape.

Proposed shape (not implemented): settle the canonical orientation ONCE in the driver layer (each camera normalizes to one orientation; TIFF + JPG + live preview + coordinate math all inherit it). This is the existing "Camera-side vertical reverse" item in Firmware/docs/TODO.md (Pylon ReverseY / IDS Mirror, removes the np.flip workaround across all save sites). The current np.flip(array, 0) is a single seam, so flipping the canonical default is a one-line change there once the direction is decided.

Decision needed (Eric): is the current orientation correct as-is, or should the canonical default be flipped to match the "reality" view -- and do you want a single global orientation preference (not per-format)? Recommend deciding this inside the camera-orientation driver work, verified per camera brand on the bench, rather than a one-off JPG toggle.

Cluster: the orientation seam is shared with the camera-orientation TODO (TIFF/JPG/preview/coord-math); not a standalone JPG concern.

Status: analyzed; original consistency fix shipped + reporter-confirmed; orientation-correctness decision not started; not yet verified on hardware.