New Sigmoid Scene to Display mapping

Maybe after YEARS of having the choice of hue twisting or norms, that finally got fixed.

That issue never existed lol :rofl:

Sure did back in 3.4.0: darktable/filmic.c at release-3.4.0 Ā· darktable-org/darktable Ā· GitHub

Please do tell me where Iā€™ve ever said anything remotely close to this.

I enjoy the work he has put into darktable because Iā€™ve taken the time to try and learn the way those modules work according to him, and they do in fact allow me easier and more creative control. Now, trying to reduce the impact of my words by labeling me a fanboy is ad hominem and not appreciated.

Unfortunately, he, the person, often has the same consending tone as you, which really makes the words written ineffective. At least he has to be poked several times before using such a tone, where as it seems to be the default with you. Really some humility would go a long fucking way for you.

2 Likes

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 :man_shrugging: 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 :+1:

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?! :person_shrugging:

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.

  1. 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.
  2. 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 sure if anyone tried your module on this oneā€¦might do so laterā€¦ Glow with Diffusion Module

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ā€¦

Is that anything like what @jdc has implemented in Rawtherapee? HDR capable JzAzBz.

Agreed :wink: 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