Maybe after YEARS of having the choice of hue twisting or norms, that finally got fixed.
That issue never existed lol 
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 
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