AcademySoftwareFoundation / AcademySoftwareFoundation/OpenColorIO
LUT1DTransform - implement alternate hue correct algorithms
- Dominant language
- C++
- Stars
- 2.1k
- Forks
- 503
- PR merge metrics
- No merged PRs in 30d
Description
LUT1DTransform has a pretty fancy "hue correct" feature, which provides a means for optionally wrapping channel-independent 1D lookups in channel-dependent operations, inducing crosstalk as a function of relative RGB values before and after the lookup.
Currently, OCIOv2 supports one algorithm, codenamed `HUE_DW3`, the ratio-preserving Hue Restore algorithm used in ACES-0.3-0.7; and the API indicates OCIO intends to implement `HUE_WYPN`, the Weighted Yellow Power Norm algorithm presented in doi:10.5594/M001808 and elsewhere [proposed](https://www.displaydaily.com/paid-news/ldm/ldm-event-reports/press-and-market/a-proposal-for-aces-2-0) for ACES-2.0
It so happens the topic of chromaticity-preserving, dominant-wavelength-linear tonescale application algorithms briefly popped up again in the ACES-2 Output Transform Architecture VWG meeting the other day, so it seemed like the right time and place to inquire about `HUE_WYPN`, among other things.
There was some very brief discussion on the Slack channel a while ago about implementing other norms as well -- there's demand for a simple maxRGB norm.
Currently, the algorithms are assumed to be fixed. Is there value in providing support for potentially parametric algorithms, like we do for FixedFunctions? For example, a parametric version of `HUE_WYPN` could be repurposed as a simple uniformly-weighted power norm, or could be driven to behave like a maxRGB norm.
Curious to hear if there's desire for other algorithms. I know OpenDRT is using a weighted Euclidean distance norm...
Thoughts?
Contributor guide
Assessment
This issue has not been assessed yet.