There is an important but maybe not obvious difference between, “clipped” and “blown out”.
TLDR:
Clipped highlights = very bad.
Blown out highlights = artistic choice and usually good.
Longer explanation:
Clipping usually means that a function is abruptly clipped and forced to stay within some strict bounds. Imagine drawing a nice smooth curve on a piece and paper and that someone then just came around and abruptly cut off the top part of that paper. The line would now abruptly end at the edge where the cut where performed. Abrupt changes are harsh and non-smooth, this is bad as we are good at seeing abrupt changes, i.e. edges. (also applies to other senses, you can barely detect a slowly raising the temperature in a room while we are excellent at feeling if one room is a bit warmer than the other).
Blow out highlights then?
Well having white pixels (100% emission) on the screen just means that you push the dynamic range of the screen which usually is good! I’m firstly interested in taking a look at one image where you feel the sigmoid curve doesn’t blow out fast, enough even with maxed skew!
But I can give some possibilities of working with it anyway. I would first try to work the highlights that you want to be very bright with other scene-referred modules. The tone equalizer is my first suggestion as the highlight isn’t as bright as you want it, then make it brighter!
As of making the range of the skew parameter larger, could probably be extended some more but not too much as you need really high powers after some time and there is a limit to even floating-point precision. And I would actually recommend editing highlights like that directly rather than pushing very high skew values. Rather use the skew parameter for skewing the general contrast distribution in the image.
Not really related to the display transform but rather the lack of a proper scene-referred linear addition bloom module. Essentially the same math as the new blur module but masking out bright parts before the blur and then add the blured version to the image.
That could be very useful but comes with the huuge caveat that ACES1.2 is a hot mess (channel-wise math, notorious-6-clipping). Apparently nobody uses vanilla ACES1.2 as it is.
There is a workgroup which gets newly developed candidates ready for ACES2.0 with different approaches (OpenDRT is one of them, another is employing a hdr-capable-CAM (ZCAM which is based on JzAzBz), basically all of them use some form of michaelis-menten-style tone-curve, go figure!). Those DRT candidates are sent out to industry people in the coming weeks in order to get feedback.
(This is extremely abbreviated, nothing is set in stone over there, criticism is plentiful, it’s a huge respectful discussion.)
You mention the ZCAM (in Rawtherapee) module conceptualized by M.Safdar, Y.Hardeberg, R.Luo, I implemented it by strictly respecting the algorithm, the results tested by 2 contributors of RT and myself were disappointing (the code is implemented, but disabled).
So I “tinkered” in the CAM sense of the word, to bring to Jzazbz (implemented as JzCzHz) some CAM features : as mentioned by @PhotoPhysicsGuy
taking into account the “Mean luminance Yb%” of the scene
“absolute luminance” (in cd/m2) corresponding to the shooting conditions (speed, diaphragm, sensitivity,…)
“black Ev” and “White Ev”, which translates the dynamic range (DR) of the shot
as well as “surround” (average, dim, black) also characterizing the conditions of the scene.
The development of the JzCzHz module was full of pitfalls with problems that appeared, not documented by the researchers, especially for the curves using Hz in abscissa. But now everything seems to work, after many tests made by @Jade_NL and @Wayne_Sutton .
This part of RT (in Rawtherapee - Local adjustments mode, so that deltaE and transitions can be taken into account) also allows you to use “Log encoding Jz” and “Sigmoid Jz” in addition to the usual adjustments:
@jandren , can we go into clipping a bit further please. You’ve described cutting the top off, just what I had in mind. So I was envisaging a curve like below where instead of going asymtotpic at the highlights, it reaches a limit. Now I accept for nice results there shouldn’t be an elbow in the middle of a curve, and it’s said the slope should be a continuous function (I think). However, does this matter much at the boundary?, i.e. where y = 100% and x = a bit less than 100%. I’ve never noticed issues when doing this boundary thing in tone curve module, or read about people having issues. Can you produce an example of this going bad?
I’m struggling to find a raw I can share that has this, and in does seem sigmoid blows quite fast! I still find it a bit strange that I can’t just adjust the blown highlights in a more “direct” way within the module, but that’s maybe just me, and it’s early days. Using the skew to do this feels like I’m abusing it.
Here the glint off the headlight is indeed (255,255,255).
@jandren , @anon41087856 , something is not right with filmic 6 in the sigmoid build, at least on my system.
In my pure Master build of 4 April, the Extreme Luminance slider is having an effect.
Whereas in my Master+Sigmoid build of 10 April, this slider is having no effect. (And that’s with at least 3 of the Preserve Chrominance options)
This is your own Frankenstein build. If you can reproduce with just the lastest master, please report, but you’re unlikely to get support for this custom build.
I’m not looking for that, more reporting the possibility of some problem with the 2 sets of code when merged. Why Frankenstein? - no one has said the process I documented is invalid.
The shadow areas in the foreground have been a huge headache, I probably would have been better off just going back at a different time of day
)