Implement support for alternative set of parametric transfer functions using the new CLF definitions.

Hi,

We discussed a bit about using the new CLF definitions to build some alternative variants for various camera log transfer functions. The main interest of such functionality is to be able to generate CLF LUTs by appending directly the transfer function of a colourspace with its metadata attached (or the necessary metadata) which in turn would inform one of the colour.models.logarithmic_function_camera definition for example.

As there are a few ways to go about that, thus I’m creating a new issue to discuss this.

This relates to #636.

[zachlewis]

I have five somewhat overlapping desires:

1. Easily represent / convert RGBColourspaces to CLF transforms The CLF Log and Exponent ProcessNodes (and in turn colour’s newly-added exponent_function... and logarithmic_function... methods) are capable of representing most, but not all, of the various decoding and encoding CCTFs supported by colour. For those that cannot be represented, it would be nice to have a mechanism for sampling (and possibly caching) a transform to a colour.LUT1D or a colour.LUT3x1D (which, in turn, can be serialized to CLF). Ideally, we’d have a standard idiom for converting RGB_Colourspaces to other representations that “does the right thing” without much user intervention.

2. Serve as a reference for pre-computed Log CLF / LogCameraTransform OCIO parameters for known CCTFs (and relevant permutations). @nick-shaw put it perfectly in slack: “Colour is an amazingly useful reference for colour science formulae and other information gathered in one place before you even start using the code!” I couldn’t agree more. Among other things, it’s definitely an extremely useful one-stop shop for device primaries, whitepoint, and vonkries methods data; and a map of precomputed coefficients for parametric representations of different device CCTFs seems like a natural next step. For the representable CCTFs, I propose we provide computed coefficients for the general form x < cut ? e * x + f : a + log(c * x + d) / log(base) + b. Compared to the CLF and OCIO parameterization, we’d provide as a convenience an additional value for f(the offset of the linear component). (A worthwhile deliverable, perhaps for colour-nuke, is a Nuke expression node with presets for different cameras).

3. Optionally instantiate RGBColourspaces with colour.models.logarithmic_function_camera or colour.models.exponent_function_monitor_curve kwargs (i.e., in place of specifying cctf_encoding and cctf_decoding). Being able to structure / unstructure certain RGBColourspace instances to and from JSON would be sweet. There’s a lot of value in being able to unambiguously represent an entire “color space” in a single line of text.

4. Improve and expand colour’s general LUT / transform toolset and user-experience Kind of a nebulous, larger end goal. colour’s AbstractLUTOperator framework makes it extremely easy to add almost arbitrary support for all sorts of custom operations (which may or may not align perfectly with CLF 3.0). Ostensibly, colour could support its own flavor of CLF extensions without much difficulty. This is a larger conversation, and my fingers are getting tired.

5. Improve colour’s support for CLF / CTF / OCIO / ACES / etc. Another less-specific goal. To what degree colour could / should provide “support” for OCIO, ACES, etc. is definitely outside the scope of this issue, but it’s worth considering how users will want to use parametric transfer function data outside colour itself, and to what degree colour can serve as a conduit between representations and uses.

[zachlewis]

1, 2, 3

Providing the callable seems redundant, no? Otherwise, we may as well use a partial directly.

Yes, good point, I’m wondering if we should not do that, it would make the implementation cleaner with less magic. If magic is required later we could still introspect the parameters from the partial.

You’re right, that makes much more sense. Seems much easier to map from RGBColorSpace encoding and decoding transforms to other representations this way, too. Right on.

Should not logarithmic_function_factory take only **kwargs as arguments?

Now that you mention it… 😃 Looks like that call to validate_log_parameters could use a good filter-kwargsing too. kwargs-filtering. filters kwarg.

There is a bit of branching in the validate_log_parameters mama jama but it is not too bad. Should be careful that the parameters have similar ordering and defaults in any case.

Word. I don’t actually know what branching means, but I’ll look it up and unbranchify. Intuitively, I think I have an idea of what you mean. It definitely feels awkward to me… I think you’re on to something with this branching business. Good call re: parameter ordering and defaults – I’ll make sure I’m consistent with logarithmic_function_camera

4

Sorry, I did not understand this one properly but then it is late and I missed my post-lunch coffee 😃

Oh god I don’t know what I put this here. This is a conversation for an entirely separate thread.

In as few words as possible, I’m talking about the relationship between style “forwards” and “reverse” variants (i.e., monCurveFwd) vs cctf encoding and decoding variants vs a node’s “orientation” in a DAG (output-facing vs input-facing).

As I said… a whooooole different thing.

5

Maybe we could output a dictionary at build time OCIO build time you mean for example? It would certainly be great to be able to obtain the parameterisation easily from wherever it is defined without having to manually extract it.

I didn’t mean OCIO, but that’s an interesting idea. Reminds me of a bug report I need to file.

Kind of a wacky idea. By “build”, I think I meant generated as an artifact in a (color) release hook, or during testing. If we were to solve approximate camera log coefficients for cctf samples, this could be a place to do it.

Maybe we could generate an XML catalog of CLF transforms for different parameterizations? That could be very powerful and handy. A job for colour_datasets, maybe?