-
Notifications
You must be signed in to change notification settings - Fork 491
Description
When ACES 2 was implemented, there was some uncertainty in how to decompose the overall Output Transforms into FixedFunctions, and so the YAML reader and writer issue warnings when any of these are used:
FIXED_FUNCTION_ACES_OUTPUT_TRANSFORM_20
FIXED_FUNCTION_ACES_RGB_TO_JMH_20
FIXED_FUNCTION_ACES_TONESCALE_COMPRESS_20
FIXED_FUNCTION_ACES_GAMUT_COMPRESS_20
At this point, we should try to finalize what the fixed functions are and remove the warnings.
I like having a function to convert to JMh, but there are two things I find inconvenient about the current one:
- The results are in the hundreds (e.g., J goes up above 800, h goes up to 360) and this makes it inconvenient to use in other tools that would prefer more of a 0 to roughly 1 normalization.
- The more conventional channel layout is for hue to be first and lightness to be last. For example, the existing conversions to HSV and HSY use that channel layout.
Currently, in order to use the existing RGB_TO_JMH with the GradingHueCurveTransform, I need to put a matrix on either side to rescale and reorder the channels. My proposal would be to create a new function that is ordered hMJ and has h divided by 360 and J divided by roughly 500.
Similarly, my only concern about the others is whether the inputs/outputs are normalized in a way that is convenient.
As we are currently developing LMTs that may work in JMh, it would be helpful if the optimizer was able to decompose an ACES_OUTPUT_TRANFORM into one or more fixed functions that expects JMh (from an LMT) as input so that a pair of RGB_TO_JMH and JMH_to_RGB could be dropped. Currently, is it possible to replace an ACES_OUTPUT_TRANSFORM with RGB_to_JMH + TONESCALE_COMPRESS + GAMUT_COMPRESS + JMH_to_RGB?
Tagging @KevinJW and @remia for input.
Note: When implementing this, search Config_tests.cpp for "experimental" and clean up accordingly. Likewise remove "experimental" from OpenColorTypes.h fixed function descriptions.