About b-splines, Beziers and expressions

Hello guys,
a few of us were having a conversation elsewhere and I thought this might be a thing the rest of the community would want to see, especially if you’re involved with Output Transforms Virtual Working Group (OT VWG).

The question that triggered the conversation was if we should start from scratch the Output Transforms. A great answer was given by Scott :

From the working group proposal: “Though the current suspicion is that a more careful expansion and fleshing out of the remaining components of the v1.1 Output Transform architecture will allow us to address the known problems, the potential for other rendering algorithms is not excluded from this project and should be explored.” I would say that the solution will be the simplest one that addresses all our issues. There might be more than one proposal that check all the boxes. In that case, I would pick the one that is simplest. The short answer is : we can redesign from scratch if the issues we are attempting to address warrant it. And we need to gather these pieces and define what we want this thing to do and not do. It is very possible that we shift away from per-channel lookup - if it gets us the things we need and without introducing it’s own artifacts. There is no law that says we must have per-channel lookup.

The conversation followed with a question by Troy :

Is there a reason you went with b-splines ? I understand how they have that nice facet of C0-2 continuity. But I was wondering if there were other reasons ?

Several answers and explanations were given :

They allow flexibility, exactness and control simultaneously. A problem though was too many control points. That’s why Scott reduced it to the minimum required for the functionality he wanted in the 1.1 HDR transforms. They are tricky if you have too many coefficients or “handles”. B-spline are quick and easy to calculate too.

The conversation followed with some Bezier examples by Troy :

To emulate a sort of emulsion print through response, a Bezier has the nice upside of firmly locating the points in an image-maker friendly representation. Whereas splines are somewhat abstract. I just find having had to negotiate curves of abstract things with other image-maker types, splines always seem to fall short on the “Understanding what the scatter of dots do”. (Where nearly every image maker has touched a Bezier, few, if any, have touched a B-Spline. Who knows.)

In this thread, Scott explains that he tried to de-abstract the splines by making the input to the functions affect the curve the way he wanted : the min, mid, max luminance values don’t feed the spline code directly but are used to calculate the values that the spline code uses. So there are controls that are relatable to the users.

The conversation followed with interesting examples :

I think that “pass through identical points” is a byproduct of all splines depending on how they are designed. Is it modeled after a print-through curve, with the curve largely forming above middle grey to peak ?

Yes we (the ACES team) modeled after film. The early tone scales actually output density and our “key point” was to map ACES 1.0 to a density of 1.0… This made sense for film but we were more often than not converting density to corresponding display luminance so then we basically just ended up flipping the curve. At some point we decided to anchor the curve base on 0.18 rather than 1.0. Both are reasonable but most people don’t think in density, especially in a digital world where emissive displays reign supreme, so for easier understanding a mapping directly to luminance eventually took over.

Then Daniele did an interesting comment about splines :

I think they actually do not solve anything but move the hard problems to the user controling the spline. Also I don’t think we can model spline like behaviour in our visual system (in terms of freedom). So the mathematical form does not align with the phenomena you try to simulate/compensate. Most often you find a much simpler expression to model the problem at hand, which aligns much better with thing you are actually try to achieve. I try to avoid splines in the context of colour management. […] S Shape is golden, I wanted to mention that I find using splines as the mathematical form is sometimes leading the research and development in the wrong direction. […] A sigmoid function depends on what you want to do. So let’s first discuss and find out what that transform needs to do, then we can find a suitable form. We could first look at something like the Naka-Rushton formula or variation of it like the Michaelis-Menten Equation (also called MM sigmoid), they are often used to model chemical/biological behaviour.

As Scott and Thomas explained :

These functions have been explored in early RRTs and are used in hdr-IPT and hdr-LAB. And they might model biological behavior but they are a pain to adjust because the variables have no direct connection to what we’re adjusting. They give less control if you need an expert viewer to tweak the curve, which is why we had a spline style curve in the first place. Hable Power Curves are also quite good but not necessarily “bio” based. We are certainly not opposed to using any methods for the tone curve but we first need to figure out what the transform needs to do and then pick the suitable form.

Finally the conversation ended with a few words by Scott :

I personally feel like the tone scale is actually the least of the problems with the current rendering. Perhaps it could use a little less contrast and some slight tweaks to the behavior at end points, etc. but otherwise it’s pretty good. But applying it to RGB? That might be an issue. However, the neutral tone scale and the current method for expressing it is imo the least objectionable part of the rendering, though probably the easiest to talk about. […] Linearly interpolating between OCES and SDR “knee” and “shoulder” weights as a function of output range is currently the method. Not super scientific but seems to work well at least across the devices I’ve been able to test on. It might not hold up but it was how I set it up to “figure out” the coefficient that controls rolloff shape.

I personally enjoyed a lot this conversation and if you’re interested to comment or leave any thoughts, acescentral is open during Christmas. :wink:



I found less degree of freedom actually helping in this case. You can still add a user-parameter layer ontop of the rendering code. But the rendering code remains clean.

Thanks for the precision. That is indeed a very interesting process !