Question
What focused refinement of the existing interface makes exposure editing precise and the two preview modes understandable without obscuring controls?
After the two research investigations, use the prototype skill to present a small layout/interaction proposal for the user to react to. Keep the approved layout: preview beside the editor on wide screens, below it on narrow screens, and expandable for inspection. Support still-image import and selecting a frame from local video without a continuous playback requirement.
Show source interpretation and metadata suggestions with clear confirmation, demonstration versus verification labels, frame selection, comparison controls, selected-band center/boundaries, numeric editing, and signal-warning meaning. Specify how the High signal stacking leak is contained and how focus, narrow screens, contrast, error feedback, and editing precision will be checked. Reuse current components and workflow; do not build production code or invent a new design system.
This is a human-in-the-loop decision. Resolve only after the user reacts to the prototype. The outcome must identify which existing UI tickets need updating and the minimum acceptance checks for implementation.
Additional user report
The color-automation section is difficult to understand. Ramp preset versus Lightness profile is unclear, and Max vividness versus Max sRGB range appears to make no difference. Investigate actual handler behavior before proposing wording. The prototype must distinguish choosing band positions from assigning colors, show what a palette preset changes versus its brightness progression, clarify whether adjustments are staged until Apply colors, and explain or eliminate apparently redundant maximum buttons. Favor plain-language controls and visible results, with OKLCH numbers and gamut diagnostics available only when useful. Preserve precise editing capabilities.
Baseline evidence for the prototype
Read-only audit of draft UI commit 698512a:
- Apply colors recolors existing bands by relative exposure position while preserving positions and widths. Changes to custom ramp controls are staged and do not recolor bands or the image until applied. No unapplied-change or already-maximized feedback is present. See frontend/src/App.tsx around lines 1012 and 1060 and frontend/src/editor.ts around lines 245-267.
- Max vividness retains endpoint hue/lightness and selects the smaller endpoint chroma limit, capped at 0.35. Max sRGB range replaces endpoints using a coarse search for their OKLab distance, rather than maximizing coverage of the entire ramp. The second action can already satisfy the first. See App.tsx around lines 680 and 740 and editor.ts around lines 115-143.
- Out-of-gamut colors silently lose chroma in 10-percent steps while rendering. Applying Ascending or Even lightness after gamut calculations can invalidate the meaning of the earlier maximum. The initial custom endpoints may have different chromas while the shared control reports only one. See editor.ts around lines 65-78 and 146-152 and App.tsx around lines 679 and 769-771.
- Vivid and Exposure use the same nine base anchors with different brightness treatment. Ascending spans lightness from 0.48 to 0.82 by anchor index; Even averages anchor lightness; Custom preserves stored lightness. These behaviors need plain-language explanation and useful thumbnails.
- Endpoint dragging has pointer handlers but no corresponding keyboard adjustment. The proposal must preserve exact numeric/keyboard editing, not merely hide the technical controls.
These observations inform the prototype; they do not resolve the user's design decision or claim a runtime reproduction.
Research handoff
Read the resolutions and linked notes in Choose reliable video-frame extraction and source-color identification and Define trustworthy demonstration and exported-LUT preview behavior.
The prototype should make the distinction between display-ready appearance and numerical agreement with the exported LUT understandable. Propose an SDR viewing default without silently changing existing export conventions. Show a clear comparison baseline; raw log viewed as display pixels is not a neutral before/after reference. Include the chosen frame's actual timestamp, source interpretation confirmation, cancellation for expensive extraction, and missing-tool/unsupported-format feedback. Recommend reasonable initial clip/resource limits for implementation rather than claiming unlimited file support. Release bundling is out of scope.
Question
What focused refinement of the existing interface makes exposure editing precise and the two preview modes understandable without obscuring controls?
After the two research investigations, use the prototype skill to present a small layout/interaction proposal for the user to react to. Keep the approved layout: preview beside the editor on wide screens, below it on narrow screens, and expandable for inspection. Support still-image import and selecting a frame from local video without a continuous playback requirement.
Show source interpretation and metadata suggestions with clear confirmation, demonstration versus verification labels, frame selection, comparison controls, selected-band center/boundaries, numeric editing, and signal-warning meaning. Specify how the High signal stacking leak is contained and how focus, narrow screens, contrast, error feedback, and editing precision will be checked. Reuse current components and workflow; do not build production code or invent a new design system.
This is a human-in-the-loop decision. Resolve only after the user reacts to the prototype. The outcome must identify which existing UI tickets need updating and the minimum acceptance checks for implementation.
Additional user report
The color-automation section is difficult to understand. Ramp preset versus Lightness profile is unclear, and Max vividness versus Max sRGB range appears to make no difference. Investigate actual handler behavior before proposing wording. The prototype must distinguish choosing band positions from assigning colors, show what a palette preset changes versus its brightness progression, clarify whether adjustments are staged until Apply colors, and explain or eliminate apparently redundant maximum buttons. Favor plain-language controls and visible results, with OKLCH numbers and gamut diagnostics available only when useful. Preserve precise editing capabilities.
Baseline evidence for the prototype
Read-only audit of draft UI commit 698512a:
These observations inform the prototype; they do not resolve the user's design decision or claim a runtime reproduction.
Research handoff
Read the resolutions and linked notes in Choose reliable video-frame extraction and source-color identification and Define trustworthy demonstration and exported-LUT preview behavior.
The prototype should make the distinction between display-ready appearance and numerical agreement with the exported LUT understandable. Propose an SDR viewing default without silently changing existing export conventions. Show a clear comparison baseline; raw log viewed as display pixels is not a neutral before/after reference. Include the chosen frame's actual timestamp, source interpretation confirmation, cancellation for expensive extraction, and missing-tool/unsupported-format feedback. Recommend reasonable initial clip/resource limits for implementation rather than claiming unlimited file support. Release bundling is out of scope.