Add CurveTrack, a tone curve widget

[matt-edmondson]

Step 1 of ImageGui's M2c (ktsu-dev/ImageGui#14 is the design). A tone curve control, its pure interaction state, tests, a demo section, and the docs.

Why this is not one of the existing curve editors

ImGui.Widgets/Editors/ already has two CurveEditor overloads, CurveData, CurveField and BezierEditor. They are real, tested and demoed — and they edit animation keyframes. Measured against CurveData.Sample on the published 3.32.2 package, they cannot carry a curve applied to pixels:

Property	Measured
Identity	worst |f(x) − x| = 0.003920, biased down (1/255 is 0.003922)
Resolution	255 distinct output values across 0..1 — a 256-entry cache read with a truncating index
Monotonicity	a 4-point curve decreases by 0.00078 at x ≈ 0.51
CurveShape.Freehand	Sample returns 0 everywhere, whatever the points

None of that matters on a keyframe track: overshoot is expressive, 8-bit sampling is invisible, and nothing inverts if the curve dips. All of it matters on an image, where a curve that decreases inverts it locally and a neutral curve that is off by a step darkens it.

So this sits beside them and nothing is retired or changed.

The decision it rests on

CurveTrack does not own the interpolation. The caller passes a Func<float, float> and the widget plots it.

A curve editor is the one control whose drawing is its specification. A histogram drawn slightly off its bins is cosmetic; a curve drawn differently from the one being applied is a lie about what the user is editing. Taking the function in makes the drawn and applied curves one function by construction rather than two that agree today.

Shape and gestures

It overlays a rectangle and restores the cursor, like HandleTrack, so it can sit on a Histogram drawn into the same rectangle — which is how a tone curve is normally edited and what the demo shows. It paints no background; a caller with nothing underneath reserves the box with the degenerate Histogram call that is already defined to draw exactly the empty frame.

Gestures deliberately avoid the vendor's: press near a point to drag it, press away from every point to add one and drag it straight away, right-click a point to remove it. Adding on a plain press rather than a double-click matters — the editor that uses double-click throws when the gesture lands past its last point (CurveField's own remarks record it as unrecoverable, since the throw escapes between PushID and PopID), and it cannot populate an empty curve at all, because that gesture is the only way to make a point.

CurveTrackState holds the rules with no ImGui dependency and is tested without a context, as HandleTrackState is. Ordering is the one constraint that never yields: two points at one x make the curve vertical there, which is not a function of x and which no interpolation through them is defined for.

Two things found while building it

• A pinnedEnds count was ambiguous — two at each end, or two total? It is a bool pinEnds instead, which is what was actually meant. The ends are pinned in x and free in y, since the ends are where clipping is expressed.
• The default grab radius was ~4px. The same radius draws the points and catches the press, so a point small enough to be hard to hit is small enough to be hard to see; it is now half a line, floored at 6px.

Testing

• CurveTrackStateTests — 24 tests, no ImGui context: ordering, y carried with its point when sorted, bounds, the minimum gap, pinned ends in x but not y, grabbing by distance in both axes, a miss reported so the caller can add, a stationary drag reporting no change, add refusing where it would not fit, remove refusing a pinned end and refusing to go below two points.
• CurveTrackTests — 13 isolation UI tests driving the widget alone, including the one the design turns on: changing the sampler changes the pixels, and the plot asks across the whole domain.

dotnet test -c Release: ImGui.Widgets.Tests 281 passed, ImGui.Widgets.UITests all passed.

A finding about main, not about this PR

The full suite reports 45 failures across ImGuiAppDemo.UITests (26), ImGuiWidgetsDemo.UITests (12) and ImGuiMarkdownDemo.UITests (7). They are identical on clean main with this branch stashed — same three suites, same counts — so none are this PR's.

The cause is environmental rather than a defect: the demos load PNGs that are Git LFS pointers in a checkout where LFS objects were never fetched, so ImageDecoder is handed the text version https://git-lfs.github.com/spec/v1 and correctly refuses it:

InvalidImageDataException: Unrecognised image format; the file starts with 76 65 72 73.

76 65 72 73 is vers. Flagging it because it makes a local dotnet test look broken to anyone without git lfs installed, which is worth knowing before someone goes hunting.

🤖 Generated with Claude Code

https://claude.ai/code/session_015qxqZVzN8CJcDxTb5gtWua

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
17 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud