Bull. Not a SINGLE person poked him when he went on his condescending tantrum about desmis’ good work. You claim that I am the one who defaults to a condescending tone, but he goes straight to a condescending rant with no provocation whatsoever. Show me one example where I’ve done that unprovoked.
1 Like
Why are you showing a 2 years old source code file of filmic ?
Because you insisted that hue twisting was never an issue, when the code says otherwise?
Dude this isn’t even the first time I’ve called you out on your tone. And I don’t even type it into the forum as often as I think it.
People like nosle, bobphotophsyics and a few others have been poking for a few years, the same rhetoric every time for workflows that are fully documented and working just fine for others. Neither seem to take the time or effort to look at the docs or videos, but just keep beating the same dead horse.
2 Likes
ok, maybe that code shows that there was a hue twist at least 1 year and 5 months ago 
I can’t check myself.
I conclude you’re saying that filmic is bad today because it was bad a long time ago and that it seems you never tried again since 
EDIT : Haha you almost got me, this is filmic.c and not filmicrgb.c
4 Likes
Please folks, we don’t want this to spill into other threads. To quote @patdavid:
Are we being awesome!?
11 Likes
Thanks for misrepresenting my arguments in this manner, I guess?! 
back on-topic:
I thought, correct me if I am wrong, the argument was that this would blow up the filmic module into a state where maintainability and UI would be problematic.
I can imagine a colorcode visual-aid to modules in order to signal users which of the bunch of modules is a display rendering transform. This would open up the possibility to include stuff like OpenDRT or your UCS/CAM flavor-du-jour.
1 Like
They can be treated as two separate contributions if needed.
- The hue preservation method (or just the idea of preserving hue) for per-channel display mapping can be added to both the filmic rgb module and the base curve module.
- The sigmoid curve for compressing the unbounded scene-referred space into a displayable space.
Number two can either be done by adding a third display transform module as you have listed or by integrating it in one of the existing modules i.e. in filmic. Both are doable but come with a different set of advantages/disadvantages.
One of the main disadvantages is as @PhotoPhysicsGuy remembered that the code would become quite hard to work with and few shared user parameters make the settings struct nasty.
I also think it should be clear that we should expect the addition of multiple display transforms to darktable as the problem is so large (what to throw away when compressing an infinite space into a finite?). Each and every method also have a look and I would for example love also have the ACES transform supported such that it can be used for parallel video and stills production.
Adding them as separate modules would make the most sense programming-wise. They could be instanced by a wrapper module if one wants to reduce the clutter in the modules list.
Adding coloring or a small icon for communicating a module’s pipeline position would definitely be nice to have!
Summary:
- Hue preservation for per-channel-based transform can be treated as a separate feature.
- Adding the sigmoid curve requires some software architecture thinking. Adding it as its own module is the best option from a programming perspective.
6 Likes
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.
6 Likes
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.
1 Like
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.)
1 Like
I thought it might offer some blown vs clipped regions…really didn’t’ check……I know the query was not for tone mapping……thx for responding…
2 Likes
This one looks challenging…
Agreed 
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
CAM16 in RT is akin to ZCAM but based on CAM16-UCS. The HDR-sigmoidic-JzAzBz I think is different to ZCAM. @jdc correct me if I am wrong!
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:
- Brightness / contrast (absolute luminance) or Lightness/contrast (relative luminance), chroma, saturation, hue rotation
- curves Jz(Jz), Cz(Cz), Cz(Jz) and also curves Jz(Hz), Cz(Hz), Hz(Hz)
- shadows/higlight (Jz)
- wavelet(Jz) (very simplified)
- clarity and sharp mask
- recovery base on luminance mask
- mask (like the ones I developed…)
I don’t say it’s perfect, but it’s a step towards…and there is still a lot of work to do to make HDR an integral part of RT?
Excuse my bad english.
Jacques
8 Likes
@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).
This is a simple sigmoid edit.
_5D_03055-classic-car-V3-sigmoid-S-sRGB.xmp (45.2 KB)
Cheers
1 Like
The man in the passenger seat looks a bit like a ghost…is that possibly a consequence of such a curve?? Maybe I misunderstood ??