Our experimental Point Color model passed a useful test: exact gray remained unchanged. It also matched its frozen Python reference across 1,178 outputs. A broader safety audit found a problem neither check could detect. Two inputs separated by roughly one ten-millionth in a single RGB channel could produce noticeably different brightness.
This candidate is outside Chiado’s active renderer. The audit did not change the app, fit new coefficients or inspect the reserved October photographs. It tested the existing zero-Variance model before further integration.
Test the neighborhood of the invariant
The audit covered 1,152 swatches: six source hues, four source saturations, four source brightness values, three Range settings, two boundary configurations and two combined shift directions. Each swatch received 565 synthetic RGB inputs, including exact grays and nearby perturbations. That made 650,880 evaluations, not 650,880 independent photographic examples.
These settings are accepted by our experimental harness. We have not verified that Lightroom accepts or preserves every boundary swatch in this grid. The audit is about the candidate’s supported input domain, not a claim that every case can be reached through Lightroom’s interface.
Every output was finite and within the supported range. Every exact gray remained unchanged. Yet the largest near-gray difference stayed near 0.056 as the input perturbation became smaller—about 14 levels in an eight-bit output.
Separate the adjustment from the selection
The smallest-step witness used an almost white gray, a green source with zero saturation, open selection boundaries and Range zero. The inputs were approximately (0.95, 0.95, 0.95) and (0.95, 0.9500001, 0.95). Their actual Float difference was 0.0000001192. The first output stayed near 0.95; the second fell near 0.894.
We repeated that pair with each adjustment separately. Hue alone and saturation alone produced differences close to the tiny input difference. Luminance alone reproduced the large jump. That isolated which adjustment exposed the unstable selection.
Inside the working-space conversion, tiny channel differences assigned the nearly neutral inputs hue coordinates of 0.5 and about 0.389 on a unit circle. Their hue is numerically defined but poorly determined: near gray, a small coordinate change can rotate the angle substantially. The model’s selection weight changed from zero to about 0.20. Its luminance adjustment then treated that uncertain hue as a meaningful selection signal.
Removing the special case would not fix this witness
The candidate explicitly leaves exact gray untouched. That guard initially looked suspicious. A trace showed that the unguarded calculation also gave the first input zero selection weight. Removing the guard alone would therefore leave this particular failure intact.
The largest jump occurred with open boundaries and a low-saturation source. Original boundaries also showed a smaller nonvanishing difference. The audit identifies a broader requirement: a complete Point Color model must define how unreliable near-neutral hue influences brightness. It does not establish Lightroom’s rule or justify choosing a new threshold without measuring it.
Check source settings that Lightroom actually returned
A follow-up reused twelve source swatches and their selection boundaries from completed Lightroom SDK probes. With those recorded coordinates and bounds, we evaluated three Range settings and both luminance-shift signs in the candidate. The largest smallest-step difference was about 0.00977—roughly 2.5 eight-bit levels—for a red source at saturation 0.25 and brightness 0.5, using its recorded Range of 0.5.
That confirms a candidate failure without relying on the first audit’s unverified open boundaries or zero-saturation source. It still does not tell us how Lightroom renders those near-gray inputs: these follow-up outputs came from the candidate, not new Lightroom captures.
The current renderer needs a check, too
The investigation also found a related defect in Chiado’s current, simpler Point Color renderer. Sampling an eight-bit gray and raising Point Color luminance by 50 brightened an exact gray by 0.25. Adding roughly 0.00000012 to that input’s green channel moved its hue outside the selection and left it unchanged. This was a separate compiled reproduction of the active renderer, not the experimental candidate.
Rejecting the candidate therefore does not fix every near-neutral problem. The active renderer also needs a repair that accounts for saved recipes and keeps the picker, range visualization and rendering paths consistent. At the time of this finding, that repair is unresolved.
A faithful port can faithfully preserve a bug
The original 1,178-output verifier still passed after the failure was found. That is not a contradiction. It checked agreement between two implementations on fixed samples. The new audit checked behavior near a boundary those samples did not establish.
Exact endpoints, finite values, bounds, numerical port agreement and continuity answer different questions. A useful test suite needs each where it matters. We recorded the witness as another adoption blocker, alongside the unresolved Variance behavior, instead of making the average photographic improvement stand in for safety.
Related: what Point Color Variance actually changes, why hue becomes unreliable near neutral, and choosing samples that exercise the boundary.