First of all, thank you very much for the clarification!
I’m using alternative settings, but I only increased the contrast a little because the scene looked a little flat. Nevertheless, in both cases there is a “peak” in orange that goes beyond the gamut as seen from the waveform:
Why I’m so picky is when it comes to customer orders, I’m very careful not to deliver results that might make it difficult for him to use the photo for different purposes, i.e. colors that are out of gamut, etc.
Based on the screenshot, base profile is Rec2020. Flick the base primaries to sRGB and see what happens then.
I agree that it’s not great to have values in the image that exceed the medium limits. At the very least, we should have a means to explicitly clip those values before they hit the medium (display or file export). I believe they are clipped currently, but that happens implicitly somewhere we don’t control. And obviously it would be great to have a better alternative than just clipping.
That said, I think the overall focus should be on preventing artefacts such as posterization that start to emerge when things are clipped. I tend not to look at the meters too much but focus on avoiding posterized edges that break the image.
OMG This is so embarrassing. 
I completely overlooked this option. Thank you very much for your patience!
Yes, looks much better now:
This was interesting checking out the alternative settings and @flannelhead 's comments on gamut made me think I rarely if ever check the gamut of my exported files.
I have been using a working profile of Linear Rec2020 and setting the histogram profile to match. For the most part looking at the waveform and gamut pre-export. Using this approach and not pushing things I have for the most part trusted the export profile to do the rest and map the color from the edit to the exported JPG…
Not too long ago I experimented with the srgb ICC profile from color.org as it has the necessary LUT to allow for relative and perceptual rendering. I sometimes found that I liked the punch of the relative rendering and the DT profile is only producing a perceptual render.
WIth this image provided by @s7habo I landed on an edit that I liked visually…maybe not the greens but I was focussed on the orange safety vest. I tried both the primaries setting in sigmoid and did exports. Just for fun I brought the jpg back into DT to check and in some cases and to varying degree’s I still had some gamut issues. This seemed worse using the color.org profile. Maybe due to the LUT’s??
I exported 6 images in total from the edit… Images 1-3 are with sigmoid at rec2020 primaries’ and then exported as relative and perceptual renders using the color. org ICC and the 3rd is using DT default srgb profile. Then I repeated this but with sigmoid now set to srgb primaries…
The following screenshots are those images …first one is the edit… not gamut indicators…
The first run of the 6 images used the color.org ICC for gamut checking and the second run of the 6 images is using DT default srgb profile for gamut checking…
The change in primaries helps a lot and when paired with the default DT srgb profile gamut seems to be handled the best…
Anyway its just an experiment and the sidecar and icc file from color.org are provided below if anyone wants to play around in a similar way…
Gamut using DT default srgb
_DSC0602.NEF.xmp (16.7 KB)
sRGB_v4_ICC_preference.icc (59.5 KB)
I thought the LUTs were required for perceptual, and darktable’s profile only supported relative.
I did as well but I will dig it up the comments that I thought indicated otherwise. I think because the rendering selection at least at one time was always set to relative but even with little Lmcs enabled it I am certain it is now set to perceptual and it is always a pretty good match for the color.org perceptual… relative is much more contrasted and easy to spot with that icc. I looked in the code and its a matrix shaper profile in DT… so maybe it is relative… the code says default intent perceptual but again hard to say maybe that just goes in the setting of the dialog box… In the case of the DT profile relative and perceptual will give the same as there is no LUT so again you may be right the thing is that the output generally is closer to what I get with the the color.org icc perceptual and the relative render is much more saturated and contrasted. There are two other icc from color.org… one is appearance and that one renders relative less saturated and more like what DT produces… It is noted I think if I understand to be more srgb accurate when gamut change is large so maybe this jives with the DT matrix profile… There is a v2 profile 2014rgb.icc which is slightly tweaked to improve on the color casts that could apparently be seen with the original v2 srgb spec… again no idea if that would improve not any rendering over what is produced by DT’s matrix… I guess I will try a set on two or three images and render them all and take a look … I wonder if other that the current one here from @s7habo there are some good test images for gamut… Just thinking about this and how it might interact with the results obtained by tweaking the primaries in sigmoid… that being you end up with a result from your edit but the rendering might impact how faithfully that gets conveyed??
I think I misunderstood this comment
“RGB (web-safe) with relative colorimetric rendering intent is essentially similar to the same profile with the perceptual rendering intent. This is to be expected since the profile doesn’t contain any “intent look-up tables”.”
From this thread
combined with my comparison of the output from DT vs color.org icc profiles it looked more perceptual… but I think you are likely correct…
Looks like sigmoid and primaries has found it way to ART… New feature: support for CTL scripts. near the end of this link…
Well, it’s a whole new way of extending ART, the provided Sigmoid script is ‘just’ one example.
I recently edited a photo with bright blue LED light. Actually, I had started out in Capture One, but got exasperated by its tendency to turn that blue light magenta when it got too hot.
Enter Sigmoid, which at least desaturated it smoothly instead of turning it into a magenta blob. But with a little tug on the primaries, I could actually precisely control the saturation color, and dial in just the kind of desaturation behavior I wanted. Beautifully done!
Thank you for this tremendous feature!
Glad it worked well for you. Sounds like you have grasped it very well! The controls are there exactly for such cases, something to reach for when one need such control over the behaviour. I initially considered just adding some canned configurations with no possibility to adjust, but in the end decided to expose all the controls.
Btw, curious to hear what kind of adjustments you ended up making. I’m sure the preset still needs some fine tuning, so happy for any data points.
I’m glad you did - the presets are very good and invaluable as a starting point, but in some cases (not sure how often - only used it seriously a couple of times so far) it’s great to be able to just fine tune things a little.
My use cases have just been LED Christmas lights so far. 
I’m continuously impressed by statements like these. I’m well aware how technical and knowledgeable people working on FOSS software are, but in the back of my mind there’s always the remnant of the idea that a company with millions invested in a software can’t compete with FOSS offerings on such an important part of image processing(ignoring the part that the users are also paying for it). This is even more impressive by darktable being entirely community driven, as opposed to blender etc that have a lot of funding to bring in developers.
This isn’t a dab at commercial software, as it is better in some other aspects, but I guess just wonderment at the achievement a ‘few’ (counting only sigmoid and other pipeline/image processing/maintainers) developers can make in such advanced topics.
Btw, curious to hear what kind of adjustments you ended up making. I’m sure the preset still needs some fine tuning, so happy for any data points.
I started out with this image (a privacy-preserving crop of an AI-denoised cellphone shot):
The blue highlight here looks terrible, in its artificial purity. This is with Sigmoid in its default state. Note that the blue channel is not clipped, it’s just very hot. What is particularly galling is the harsh transition from grey-purple hues to the blue highlight, and that it has a uniform brightness with no gradation between the center and the edges.
For reference, here is how Capture One, Lightroom, Affinity, Photomator, and Apple Photos render this:
Sigmoid gives you two controls here that lets you precisely control the amount of discoloration and desaturation:
Blue Attenuation at 0%, 12.5%, 25%, 37.5%, 50%:
At 12.5% Blue Attenuation, Blue Rotation at -20°, -10°, 0°, 10°, 20°:
To my mind, a Blue Attenuation of 13%, and a Blue Rotation of -1.5° recovers a feeling of a realistic highlight in the blue area, while maintaining its blueness (1st image). A quick tug in color zones makes it a bit less radioactive (2nd image):
You can achieve something similar with Lightroom’s Calibration panel. Especially during Christmas time with its myriad artificial lights, this is a very useful feature!
Hey @flannelhead thanks a lot for your work. I find it really cool that you guys always try to improve darktable and find new ways for processing Images.
In your post https://discuss.pixls.us/t/introducing-primaries-feature-for-sigmoid/40450?u=jjbraun you mention to change the module order for Modules used to increase purity or saturation after sigmoid. So when my understanding is correct i should move all instances of Color Calibration (used as channelmixer not for WB), rgb primaries and colorbalance which i use to increase contrast after sigmoid is that correct?
How about if i change contrast or luminosity levels witch tone eq or colorbalance? I often use Brilliance grading in colocbalance to enhance contrast. At which point in the modul order schould i set this?
Purity is about color saturation so I don’t think for contrast you need to worry. Also if the image doesn’t need adjustments in sigmoid primaries then I suspect there is no real need to move them. Only for images with weird lighting or saturated flowers etc where you are going to try to attenuate purity with sigmoid primaries to help manage out of gamut would you like not want to be adding more “purity” to the image before trying to correct one that already has issues with saturation…
if you don’t know, the default order is the best order. Changing the position just makes sense, if you need to modify stuff that can‘t be done properly before tonemapping.
but keep in mind: darktable doesn’t protect you from shooting into your foot
Hello,
First of all, thank you very much for this development and your choice to allow the possibility of controlling all the settings.
Personally, I’ve made a series of presets for myself.
Sigmoid-dtpreset.zip (4.5 KB)
At present, I use look 7 as the default processing, where I correct the skew and contrast according to the photo. For more difficult images, I use the various primaries sliders.
In all instances, I like to set hue preservation to 50%.
Greetings from Brussels,
Christian
What about in the main RGB Primaries module itself (not Sigmoid)? Would it make sense to be able to control the brightness of primaries in that module? In it current state, the module effectively replaces the channel mixer and Colorfulness sections of the Color Calibration module, but not the Brightness section. As a result, I often find myself needing to use both modules to work on the primaries.
I imagine you already thought about this and there’s a reason why those controls weren’t added, but thought I’d just throw it out there, and it seems @s7habo had similar musings.
You kind of can already - with the tint sliders. This, by definition, adjusts the gains of the primaries with respect to each other.
Obviously this is not what you are looking for, since the result is in fact an adjustment of global white balance. I understand that you would like to keep the achromatic areas as they are.
However, this can’t be accomplished by channel mixing (matrix multiplication). When implementing something like this, one probably ends up with some sort of hue / chrominance selective adjustment of exposure. That is also (kind of) how it is implemented in color calibration.
There are several modules already which do something like this. The freshly-merged color equalizer, color zones and color calibration at least. I would suggest looking at those ones.
This module is better kept as just a stupid matrix multiplication and nothing else.
