Those preserve hue results are indeed very nice!
Thanks for this detailed explanation @jandren . All the images I edited so far confirm what you described. And now I also know the reason .
Up to now I tested a few dozen images from pixl.us, especially out of the PlayRaw section and a bunch of my own nasty ones. Your module runs very well and fits nicely into the raw-editing toolbox we call darktable.
I really hope it will find its way into master finally.
Work-around: Most browsers offer the “Open in new tab” option if you right-click on the image. Switching between these tabs you can compare them like a slide show.
The more I read of color appearance models and how to do them ‘right’, the more I think that as long as something is not obviously offensive it is ‘good to go’. I’ll come back to this.
While I don’t like the crosstalk option at all, the orange to yellow hue shifts in the ‘Fire Clouds’ image look very pleasing to my eye. The skin tone hue-shifts for the ‘happy kid’ picture look awful compared to preserve hue, and awful is an understatement.
Crosstalk in the ‘Circus Arena’ image shifts blues to cyan and leaves the hints of purple in those other lights alone, making it easier to see the two different colors with which the stage is illuminated. It’s wrong, but it ‘reads’ better for the lack of a better word.
Preserve Hue appears to be much better in the accuracy department in ‘Circus Arena’. Curiously though, RGBratio at least tries give the blue and purple lights their ‘strength’ back. For my taste it goes way too quick to white at high intensities and floods everything with the same hue of blue, but it tries to render the strength. What RGBratio does nicely is render the colors of the control panel in the front compared to the other two options. In ‘Music Hall’ RGBratio renders a believable carpet color…obviously I haven’t been there and can’t say if this is more correct than the other options. This of course holds true for all the statements above.
What is this personal opinion then good for? Not much, except for ‘PreserveHue’ works for me, except when it doesn’t. I’d use it. Are there applications for RGBratio? Sure! Are there aspects of ‘crosstalk’ that I sometimes would like to have for ‘PreserveHue’? Very few and rarely.
This brings me back to color appearance models (CAMs) and the general question of how to represent the full spectral gamut that humans can see into smaller colorspaces of displays. It’s very likely that you can break any gamut-mapping algorithm at the moment. There are some doing a better job than others. Of course one should opt for the latter ones IF it doesn’t break for a particular image. But, especially the appearance of high chromaticity colors of high brightness, particularily in the blue and red spectral range is something that even the ‘best’ CAMs still struggle with. It is a current research topic. So while true that PreserveHue is not perfect, it might absolutely be good enough or even better in cases where the ‘better’ option breaks.
Great work on that module! Looking forward to it!
I prefer the rgb crosstalk.
Rgb ratio has too much low saturation in the shadows and highlights
Preserve hue totally removes luminance details leaving a solid color blob
Neither rgb ratio and preserve hue really preserve hue because they are based off on the rgb color model (blue is shifted to purple and red is shifted to pink), sometimes they could be accurate but most of the time they just have the opposite hue shift compared to rgb
However it’s great to have many options because the perfect way to handle colors doesn’t exist.
Thanks for the nice comments!
They also really show how much of a personal taste and image intention plays into this topic as well.
Especially lovely to see your results with trying it out @pass712! Really good results
I think I will prepare a follow-up post with some synthetic charts that makes it easier to show some aspects of how these three methods differ from each other. Especially on the topic of desaturation in highlights.
It is also a topic that is covariant and intertwined with what you do before this module. Take the control panel in the Circus Arena for example. I would say that the solution for making it more saturated actually is to dodge it a little bit with a masked exposure. It will become more saturated once closer to the mid-tones.
As for a merge to master, well I would recommend you to not hold your breath as the PR still is marked as controversial. It will need to find its proper place, naming, and function before a merge. I hope these last updates have moved it slightly closer.
A post was merged into an existing topic: The darktable magicians have crafted something again - detail mask
Well, time will tell. Regarding the discussion on github it will be interesting to see how the decision is made in the end. I think it is important to discuss it and can follow the arguments against it to a certain degree.
I can only encourage others to test this module thoroughly. If needed I could support the Win 10 fraction with the build I’m using at the moment.
Why not just distributing the module as is for the time being? AFAICS, Darktable’s plugin architecture is flexible enough to load any .so’s that fit the expected interface.
Without being represented in the iop order list darktable doesn’t know how to deal with a module.
Of course it’s possible to build a custom darktable version after integrating the pull request.
Correct, that’s what I did .
So if there is any dirty Win10 user out there beeing interested to play with sigmoid just let me know.
Technical follow-up on the subject of color processing!
It’s easier to show some behaviors on synthetic charts so I created a simple one where the background is middle grey (0.1845 on all channels) and the color triangle is the linear interpolation between the three different primaries with a constant average of 1.
So let us just show what these look like for the three different color modes with the exposure adjusted up by 1, 2, and 3 Ev. All other settings are default i.e. contrast = 1.6, skew = 0
|Base||+1 Ev||+2 Ev||+3 Ev|
|Base||+1 Ev||+2 Ev||+3 Ev|
|Base||+1 Ev||+2 Ev||+3 Ev|
They all look pretty very similar for the base image with this contrast setting and it is actually hard to tell them apart at this level. But even small changes hard to spot here can be visible in faces as shown earlier.
The crosstalk and preserve hue options are still hard to tell apart when doubling the intensity by increasing the exposure by one stop, but something weird happens with the RGB ratio option. A triangle between high saturation purple, yellow, and cyan is formed. The extreme red, green, and blue are desaturating before less saturated colors closer to the neutral center of the triangle.
Doubling the scene intensity again by increasing the exposure with another stop continues the trend of the RGB ratio option where desaturated colors remain saturated in a cross in the middle while colors on higher saturation are desaturated before these. Its also finally possible to see a difference between crosstalk and preserve hue where the former has its purple, yellow, and cyan regions has widened while they stay unchanged for the preserve hue option. There is just one downside to the preserve hue option: star-shaped desaturation spikes going out against the primary locations.
The trend continues for the last picture where rgb ratio has saturated neutrals, crosstalk twists almost all colors, and preserve hue keeps the original hue along the edges.
I, first of all, want to focus on the problematic desaturation behavior of the rgb ratio option. The shape of the artifact depends on which norm you use but it will pretty much be there in some form. I think it is important that any desaturation of colors in highlights has to begin with low saturation colors and then gradually desaturate more saturated colors. This is what the crosstalk and preserve hue options do as the saturation is part of the dynamics of the tone mapping and not a separate manual step. I find this very problematic, what would you say?
It’s also clear that the preserve hue option actually preserves the hue even for brighter colors while it also becomes clear why any piece of bright sky pretty much always ends up cyan. But also note that there is very little difference at lower intensities between these two options such that the colors will be correctly preserved if the sky exposure first is reduced using either a masked exposure module or the tone equalizer. I.e. dodging and burning in scene-referred space is king and reduces the needed reliance on the tone mapper preserving colors!
I finally encourage you to try out the synthetic image yourself on the sigmoid or any darktable module for that matter! It is a really good method for revealing how colors are changed! I like to drag the exposure up and down to see how modules react to changing exposure levels!
Download the openexr-file or the Blender-file that I used to create it with:
average plane at 1.exr (8.0 MB)
color slice.blend (550.9 KB)
I took a very geometrical approach and assigned the colors from the coordinates of the surface, just change the surface if you want to modify what plane to look at or what colors to include.
I like preserve hue more now!
Yes that seems discontinuous. Modifying preserve hue might also be an interesting rabbit hole!
I would argue against that. Maximum saturation/chromaticity colors will be limited by display primary color emission-strength while at the same time you need/try to preserve emission ratios. You can either pin the color at the rim of the gamut and not change its apparent luminance when you increase exposure OR you change its apparent luminance and desaturate (as you cannot do both).
The latter at least tries to keep the dynamic range of whatever scene, the former alters it to maintain saturation. Luminance is maybe more ‘important’ than chrominance, otherwise black-and-white would not work. The sigmoid is quite superb at mapping luminances from scene to display, to me it would be strange to let color-appearance distort those luminances again.
I think this is technically only true for preserve hue. The fact that crosstalk bunches all colors to cyan, purple, yellow makes it almost useless. The above mentioned downside is that when trying to keep saturation, they(preserve hue, crosstalk) remap luminance to do so. And this is even without touching factors like perceived luminances of different colors at different saturation levels.
I’m not saying I like RGBratio…the way the colors wash out seems odd…but I can see why the colors do what they do.
There are several good threads over at acescentral dealing with similar problems and questions. I think there might be one or more solutions on the horizon that go one step further. Gamut mapping options which might look more correct than RGBratio. We’ll see.
Curiously LUTs could be the preferred solution here. They could model whatever desaturation or saturation maintaining behaviour one wants or ‘feels’ is right. Sure this is not as elegant as a analytic approach, but as long as no good analytic solution to chroma mapping exists, carefully handcrafted LUTs might be the way to go.
I keep repeating myself, sorry, but:
I’d personally use preserve hue and RGBratio for now, keeping in mind that both are not perfect.
As always, great work!
I think this is a rabbit hole worth spending some time digging out so I will try to prepare some examples of my experience so far with testing this. Would you be able to compile the sigmoid branch yourself and try using it yourself on some images? It really makes it much easier to grasp the dynamics of things!
And some images of mine just to show that it still works! All of them are using crosstalk or preserve hue, rgb-ratio have remained unused so far. Editing process is basically exposure, masked exposure, and color balance rgb in scene-referred space before the sigmoid module. The black and white picture is also using some local contrast in scene-referred space even though it hasn’t been ported to work here yet. (I would really love a local contrast rgb module that works on “exposure level”/brilliance mode and handles infinitely bright pixels!)
How can we download that branch with sigmoid?. I only know to do it from the master
You can checkout the sigmoid branch from GitHub - jandren/darktable at sigmoid_tone_mapping and rebase it to the darktable master branch which works almost without conflicts. Then you can compile that branch and get sigmoid included in the master branch.
@jandren I did some experiments in the last days and it looks really promising to me. I had only some issues in highlight details where filmic did a better job in my opinion.
Just take care it adds entries for sigmoid module in your database data.db and if you remove the module DT is not happy so you have to do some work purging the entries…
As @priort said do take care when trying it out. I would recommend the following to not fuck with the rest of your installation:
clone my fork into its own directory:
git clone https://github.com/jandren/darktable.git
then checkout my branch:
git checkout sigmoid_tone_mapping
Finally build as a separate version using the test build command from the darktable readme
./build.sh --prefix /opt/darktable-test --build-type Release --install --sudo
You could even rename it /opt/darktable-sigmoid to really make it unique.
And probably backup that data.db file just to be sure.
Nice to hear that you tried it out @dirksagwitz and that you liked it! Would you mind sharing some pictures where you think filmic did a better job in the highlights? Would be interesting to both see what result you had like to achieve as well as try it myself. I.e. the raw file + your edit as jpg and its xmp? Would help me greatly in bringing this forward
Here is an example where in my opinion Filmic does a better job … even if I like the sigmod saturation a but more but it’s missing e.g. some details in the clouds and I am not quite able to recover them well.
Picture published under CC-BY-NC.
IMG_7253.nef (28.5 MB) IMG_7253_04.nef.xmp (10.6 KB) IMG_7253_01.nef.xmp (10.2 KB)
@jandren , I noticed this too. I will be back home tomorrow evening and supply some examples. I solved this so far by using the tone equalizer and to tune down the highlights.
Compared to filmicrgb, in my tests sigmoid had less “out of the box” trouble with colour shifts. This was mainly caused by filmicrgbs standard setting for “middle tones saturation”=10%. Set this to 0 and both tonemappers are almost equal in this aspect. A good measuring tool to judge colour this is the new vectorscope, btw.
Using standard settings, sigmoid delivers images with noticable more oomph, due to its contrast setting. filmicrgb needs a little more local and global contrast but catches up if you know which of the 16 sliders hidden in 5 tabs you have to touch . Put those in a preset and again, both are close.
Where sigmoid imho really shines is in highlighted areas in the transition zone to clipped areas. Simply use highlight reconstruction and you´re done. I will post some examples tomorrow.