lgritz
commented
5 years ago I just want to say that I am really happy about this feature. In OIIO, for example, there's a patchwork of logic about which color transforms are handled by OCIO, which have fallbacks to my own code either because OCIO never tried to do it or simply because the OCIO config on hand doesn't contain what I need (example: needing linear <-> sRGB is ubiquitous). I really look forward to the day when I can rely on OCIO v2 for basically all the color conversion I'd ever want and essentially have a single code path for it and know that the common transforms are built in and work work with any config.
michdolan
hodoulp
There are a number of color functions that get used over and over and that currently need to be implemented as 1d or 3d LUTs. Representing them as LUTs is undesirable since it is less accurate and often has problems with over-range values. Also, on the GPU simply doing the math is often faster and reduces the usage of texture memory.
In theory, these functions could be implemented via a general purpose color language such as CTL. However, in practice such languages are difficult to implement in a way that is fast, cross-platform, and robust. Also, that approach does not necessarily provide for an inverse transform direction, which is vital for a number of important use-cases.
Therefore, we have found it very useful to provide a set of hard-coded color functions as common building block transforms. It is straight-forward to do this in a way that is high-performance, cross-platform, robust, supports CPU and GPU, and that includes inverses. (And although the formulas themselves are hard-coded, they take parameters that are adjustable and therefore cover a range of specific cases that all use the same underlying math.)
Because there is a fair amount of overhead involved in adding new ops, we prefer to combine similar functions into a single op. However, if the community prefers to have more granularity at the user-facing Config file level, this is possible by exposing the functions as separate Transforms. For example the ExponentTransform and ExponentWithLinearTransform are separate Transforms at the config level but under the hood they both instantiate a common Op type.
As described in the OCIO v2 proposal, we also want to provide optional built-in color space conversions, but a separate issue will be logged for that. The present issue is to capture the work at the Transform and Op level to implement specific formulas or processing operators and is a prerequisite for efficient implementation of the built-in color space conversions. (Several of the individual transforms/ops will typically need to be stacked together to do color space conversions.)
Here are the proposed new transforms (in addition to the existing ExponentTransform, LogTransform, etc.):
ExponentWithLinearTransform -- Does functions such as sRGB and L*.
ExponentWithOffsetTransform -- Implements some commonly used ICC parametric functions.
LogAffineTransform -- Implements the classic Cineon lin-to-log type curves.
LogCameraTransform -- Implements most camera OETFs including LogC, SLog3, and also ACEScct.
LogHDRTransform -- Implements PQ and the HLG-OETF.
FixedFunctionTransform -- Implements various ACES and Rec.2100 components. This includes the following: ACES_RedMod03, ACES_RedMod10, ACES_Glow03, ACES_Glow10, ACES_DarkToDim10, ACES_ClampDW3, ACES_ClampDW3b, ACES_ChromaScale02, Rec2100_Surround.
LumaChromaTransform -- Implements various conversions into spaces with a chromaticity plane (or similar). This includes the following: RGB_to_HSV, XYZ_to_xyY, XYZ_to_uvY, XYZ_to_LUV.