Repository navigation
fix(core): sample hue curves across their periodic seam - #5287
Conversation
jrusso1020
left a comment
There was a problem hiding this comment.
I confirmed the mismatch on current main. compileHfHueCurve samples the periodic table at (index / size) * 360, but applyHueCurves still calls sampleAdvancedCurve(hsv.x, 1.0). That function scales by size - 1 and clamps the upper texel, so hue lookups drift and never interpolate from the last sample back to sample 0 across red. The new sampleHueCurve uses fract(coord) * size and wraps upper with mod, which matches the compile side, and RGB curves keep the endpoint-inclusive clamped sampler. The Chromium test runs the real shader against a CPU reference built from compileHfHueCurve, including near-red seam cases and an RGB endpoint control. main has since split the shader into HF_STAGE_* variants, but the hunk still applies cleanly inside #ifdef HF_STAGE_HUE_CURVES.
— Rames
Hue curves are compiled with samples at
index / size, but the grading shader reads that periodic table athue * (size - 1)and clamps the last sample. This shifts narrow hue adjustments and fails to interpolate back to the first sample across red. Real Chrome reproduces visible errors of 20 and 84 channel levels on a near-red source pixel.Add a dedicated hue sampler that uses the periodic table size and wraps its upper sample. RGB curves keep their endpoint-inclusive, clamped sampler. The fix applies to all three hue-curve channels without changing authored grading data or lookup packing.
Validation:
The Chromium tests run when a local browser is available and follow the existing Windows opt-in convention.