Red channel z-stack acquire (manual) at 12 bit false color does not save in false color

[EtalumaSupport]

Blue and green do work.

[ericweiner]

Status: under investigation, no fix yet. Need bench data to disambiguate hypotheses.

Caller survey (no Red-specific branching found):

• `drivers/ledboard.py::led_on` is per-channel additive; not save-path.
• `modules/protocol_image_writer.py::capture` reads `step['Color']` and `step['False_Color']` from the protocol step; passes through to `save_image`. No Red-specific branch.
• `modules/lumascope_api/_lumascope.py::save_image` and `prepare_image_for_saving` -- no Red branch.
• `modules/image_utils.py::write_tiff` -- gates on `data.dtype in (np.uint8, np.uint16)` (post-8-bit false colored fluorescence channel max z-projection images are greyscale #669 fix) and `color in get_image_layers()`. `get_image_layers() = ['Blue', 'Green', 'Red', 'Lumi']` -- Red is included.
• `modules/image_utils.py::add_false_color` -- canonical RGB ordering: `Red -> img[:,:,0]`, `Green -> img[:,:,1]`, `Blue -> img[:,:,2]`. Symmetric across all three.
• Defaults in `data/settings.json`: `Red.false_color = True`, same as Blue / Green.

There is no code-side path that would cause Red specifically to skip false-color save while Blue and Green succeed. Per Rule 39 I will not propose a fix on a single data point (your report) -- I'd need a second data point to localize the cause.

Diagnostic asks (any one is sufficient to narrow it down):

1. From a session where this reproduces, attach one Red z-slice TIFF + one Blue z-slice TIFF (just any random slice from a manual z-stack run with false-color on, 12-bit, immediately after acquire). Comparing the actual TIFF contents (3-channel-RGB vs 1-channel-grayscale; ImageDescription tag) will localize where Red diverges.
2. The full `api.log` from the session would show what `color` value reaches `save_image` for Red vs Blue. The log line is `save_image color=Red...` or `save_image color=Blue...`.
3. Open `data/settings.json` and confirm `Red.false_color` is `True` (it ships True by default; a UI bug could have flipped it).

If the saved Red TIFF is single-channel grayscale, the bug is in the protocol-step layer config flow (False_Color flag for Red not propagating). If it's 3-channel but with the wrong color plane (e.g. all zeros instead of Red), the bug is in `add_false_color`. If it's correct 3-channel-with-Red-plane but renders grayscale in the viewer, that's a viewer-side issue (PhotometricInterpretation tag, etc.).

Tracked in `docs/AUDIT_COLOR_CONVENTION_2026-05-15.md` Phase 0 status as open.

Related but separate: #669 (8-bit fluorescence false-color save) was an adjacent finding from this triage and is now fixed in `5b7a16b`. If Chris's Red z-stacks were 8-bit by accident, the #669 fix may also resolve #668 incidentally -- retest after the next bench build can falsify that.

[ericweiner]

Triage / analysis (no fix yet)

Disposition: needs-bench

Root cause: Red z-stack acquire (manual) at 12-bit false color does not save in false color. Static read cannot disambiguate the false-color save path without a sample.

Proposed fix shape: pending a bench artifact -- a Red and a Blue z-slice TIFF to compare the saved color-mapping path.

Cluster: standalone (distinct from the stitched-greyscale issues already fixed).

Status: analyzed; awaiting bench data (More Bench testing needed).