kofa
(István Kovács)
June 9, 2022, 7:50pm
35
Has the behaviour described here changed?
for the non-chrominance preserving method (independent RGB channels), we still enforce hue to be passed along from input to output. We still keep the desaturing behaviour in highlights but we set the original chroma in shadows to avoid resaturating .
darktable-org:master
← aurelienpierreeng:filmic-v6
opened 02:38AM - 24 Jan 22 UTC
That crossed #10975 by a thread.
What's new ?
1. we ditch the mandatory de… saturation to white, since it was too harsh in many cases and we don't need it because…
2. introduce 2 steps of gamut mapping, one against LMS cone space, one against pipeline RGB, and I'm considering mapping to output RGB directly,
3. for the non-chrominance preserving method (independent RGB channels), we still enforce hue to be passed along from input to output. We still keep the desaturing behaviour in highlights but we set the original chroma in shadows to avoid resaturating.
4. Bottom line is all methods now preserve hue. Chrominance-preserving norms preserve saturation as well.
OpenCL available, but there is a discrepancy between C and OpenCL that I need to find. Reference implementation is OpenCL. I publish now to show @flannelhead
The gamut-mapping is much simpler than in #10975 and done in Kirk Yrg space (linear). Hue is preserved at all cost, then we do a test projection in RGB. Out-of-gamut are spotted if any coordinate exceeds [0; 1]. In which case, we record the Ych value of:
1. the original color,
2. the clipped color (closest in-gamut color, but at a different hue),
3. the darkened color (closest color at same saturation).
From the clipped color, we update the Y value (usually a bit brighter, which is desirable to retain luminance consistency of colored lights), and from the darkened color, we update the chroma estimation (chroma at same saturation and lower luminance is actually lower than original). So we march like this toward the boundary of the gamut, and iterate up to 8 times until we find it.