FR-DEV-12 — Colour grading by tonal range #4

New Issue

2026-09-05T16:09:16Z

dtourolle commented

2026-09-05 16:09:16 +00:00

Add colour grading by tonal range — hue and strength applied to shadows, midtones and highlights independently, plus a global cast.

Why

The colour mixer targets hues that already exist, regardless of brightness. Grading targets tonal ranges and can introduce colour that is not present — cool shadows against warm highlights, the classic split tone, and the only route to toning a monochrome conversion.

The distinction between the two tools is the one photographers most often need explained, which is a sign it is load-bearing rather than a nicety. DarkRoom has the first and not the second, which makes this the largest single gap in the develop panel.

WidgetKind::ColourWheel is already declared in the descriptor vocabulary with no operation behind it — this is the operation it was declared for.

Acceptance

A declared node in core/dr-pipeline/ops/ with attributes: [colour], so it joins the right group with no frontend change.
presentation.widgets: [colour_wheel], degrading to plain hue and strength sliders where the wheel is not implemented — which is the current state, and must remain fully usable.
Neutral means absent: at defaults it contributes no code, no uniform and no branch to the fused shader.
tests: block asserting the neutral and the uniform mapping.

Lands in

One new YAML file. The colour wheel widget in ui/dr-ui is a separate, optional follow-on — the node is useful before it exists.

Part of the Develop Ergonomics spec (FR-DEV series proposal), 2026-09-05.

Add **colour grading by tonal range** — hue and strength applied to shadows, midtones and highlights independently, plus a global cast. ## Why The colour mixer targets hues **that already exist**, regardless of brightness. Grading targets **tonal ranges** and can introduce colour that is not present — cool shadows against warm highlights, the classic split tone, and the only route to toning a monochrome conversion. The distinction between the two tools is the one photographers most often need explained, which is a sign it is load-bearing rather than a nicety. DarkRoom has the first and not the second, which makes this the largest single gap in the develop panel. `WidgetKind::ColourWheel` is already declared in the descriptor vocabulary with **no operation behind it** — this is the operation it was declared for. ## Acceptance - [ ] A declared node in `core/dr-pipeline/ops/` with `attributes: [colour]`, so it joins the right group with no frontend change. - [ ] `presentation.widgets: [colour_wheel]`, degrading to plain hue and strength sliders where the wheel is not implemented — which is the current state, and must remain fully usable. - [ ] Neutral means absent: at defaults it contributes no code, no uniform and no branch to the fused shader. - [ ] `tests:` block asserting the neutral and the uniform mapping. ## Lands in One new YAML file. The colour wheel widget in `ui/dr-ui` is a separate, optional follow-on — the node is useful before it exists. --- Part of the Develop Ergonomics spec (FR-DEV series proposal), 2026-09-05.

dtourolle added the develop pipeline size:S labels 2026-09-05 16:09:16 +00:00

dtourolle commented

2026-09-19 10:19:16 +00:00

Landed in 7c3e1d2 (2026-09-05, two hours after this was filed): colour_grading declared as a node at 105, and FR-DEV-12 is tagged in the matrix.

Landed in 7c3e1d2 (2026-09-05, two hours after this was filed): colour_grading declared as a node at 105, and FR-DEV-12 is tagged in the matrix.

dtourolle closed this issue

2026-09-19 10:19:17 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dtourolle/DarkRoom#4