Ya for these images I think v5 with no is a great start and then you can tweak the look settings and usually get a nice result…I guess maybe out of gamut and or in accurate but hey in the end a nice looking yellow flower 
@priort And that’s exactly what happens here. But with those intense yellows, if you push them to the limit of rec2020, they are out of gamut in sRGB. So something has to give when converting to sRGB (i.e. display): either you maintain the hue, and play with saturation and luminosity, or you allow a hue change (note that each of those choices can be mathematically correct). The aim of V6 was to minimise hue changes, V5 does show some hue changes.
If you do not push too much in rec2020, you can get a transform to sRGB with minimal changes. I find I have less trouble keeping red and yellow flowers with natural-looking colours when not pushing too much.
I think here the issue comes out very clearly because the flowers are the brightest part of the image. In many casese, that’s not the case, the brightest part is a specular highlight or clouds in the sky. Then the effect isn’t as visible…
1 Like
Which i remember from your thread about that image … You like the yellow you get from v5, chrominance mode ‘no’.
Which j get, it’s lovely :). But having put that image through a few other editors , that golden orange is the more ‘true’ rendering it seems. A lot of programs give that.
So - as i said in that thread - the yellow is not an outcome i would would want from filmic , because it is a big hue shift.
In your case, a lucky accident basically … which is fine it gives you what you want , but to me it seems like something is wrong with it :).
I would expect a nice default rendering would be a flower full of color , with no ‘turn to white’ on the specular parts of the petals , but without a flat look.
Then if i would want yellow , a very quick hue mask takes flower and you can shift the hue to yellow.
Again, in your case v5-no does this in go so you are absolutely right in liking and using it . But like I said , it means it’s shifting colors unasked where it shouldn’t IMHO.
So if this patch gives a nice correct chromatic result , then it seems interesting. Because then you can layer your artistic choices on top .
V5 is fine to use, but I’m sure it will go away at some point. But this is an interesting point. filmic v5 didn’t include this gamut_check_RGB, and it works fine. It does desaturate highlights, BUT the point at which this is very noticeable is at highlight values much higher than when v6 starts mashing colors. I’m not convinced there is not simply a bug somewhere that, if fixed, would stop all of this (or else delay the onset of the color mashing to more or less where v5 would have applied noticeable desaturation). I haven’t looked that deep into the various calls within that function at this point.
I haven’t dug into the v5 code deeply either. It desaturates highlights at the extreme ends. I don’t don’t think this is necessarily “gamut mapping”, but rather trying to make a tone mapper that produces results that look like film. And if v5 (or the older versions) really don’t do the same kind of gamut mapping as v6, then how important could it really be? It seems like an overly pedantic approach that ironically gives crappy looking results.
The whole fact that there have been 6 “color sciences” makes me question any absolute statement made about color science and “what I should want an image to look like”. I don’t buy it at face value. I can see shitty-looking results with my own eyes LOL, and that is the elephant in the room IMO.
As an aside, the recommendation for filmic RGB use has always been ETTR (expose to the right), but ironically it seems like that will guarantee that problems like this are encountered.
1 Like
Yeah the filmic in master shot looks like crap to me.
I don’t want to dive off into a tangent here but I have my doubts about the accuracy of the gamut check tool anyway. It’s funny- in the shot you attached, the areas that show up as out of gamut are areas that filmic v6 didn’t mess with (at least compared to the obviously whitened areas, which DON’T show up highlighted as being out of gamut in the checker, I guess because they’ve been “fixed” by filmic v6 already). So why didn’t v6 totally clobber the whole sunflower and turn it peach/white, based on what the gamut check shows? Based on the gamut check it missed a bunch. Again this kind of thing leads me to doubt.
I think the key was providing the other images and not focussing on just the sunflower…Visually I found them instantly more appealing without more work to bring it back to something like that. accurate or not. Superimposed on this is the choice of UCS vs JzAzBz… if you use CB module and toggle these you get quite a different image. I am not sure wrt UCS if filmic v5 and V6 interaction would be or is the same??
Ettr recommend for filmic ??? Aurelien was strong in opinions , but ‘using the benefit from modern cameras’ was always one of them. He was against ettr.
There are a lot ok these forums , but also elsewhere who don’t think ettr is something to blindly follow. It’s hard to do right and consistently , and the images that clip highlights are more difficult to deal with compared to images that are a bit underexposed.
I know there are people who use the camera for the image it shows on the screen, and want to shoot the image there and then.
But the fact is that to use all the data in a raw file correctly , you need to see your camera as a 'light sensor capture device ', not something that creates images.
@priort I’ve never tried building darktable on Windows before. What you might try doing is simply replacing the two source files with the two I attached further down in this thread, rather than using the patch. The openCL module is the data/kernels folder, and the std module goes in the src/iop folder.
Since @AxelG tagged me, I’ll try to reply something. I didn’t read the whole thread in depth, just commenting on a general level.
I took part in designing the filmic v6 color science (you can look at the PR to see the whole exchange), so hopefully I can provide some useful insight (from my point of view, anyway. Can’t speak for Aurélien, of course.)
The part of the gamut_check_RGB() causing issues here is the so called “upper boundary” handling. That is, while we work in the working RGB primaries (usually Rec.2020) and the final RGB triplets after the filmic curve are all between 0 and 1, when we convert to display (usually close to Rec.709 → much smaller gamut footprint), some of the RGB components might be greater that 1. That means they are too bright to be displayed.
(The “lower boundary” - when RGB values get negative - doesn’t seem to be troublesome here. At least I haven’t heard of any strange effects from that part of filmic v6’s gamut mapping.)
As filmic v6 was set to preserve the original hue at constant luminance, in those cases, under these constraints, the only option is to decrease the chrominance. Filmic v6 does this in a chromaticity linear manner (yes, while the special Yrg color space is used, the de-chroma is still chromaticity linear) a shift of the perceived hue might happen. In plain words, the color before gamut mapping is mixed with white until we get a color that is displayable on the target display at the desired luminance.
Unfortunately the yellow-orange area seems quite sensitive in our psychophysical system that forms the image we see when actually standing there. There are at least a couple of effects in play here. As some of you may know, mixing white may actually change the perceived hue (Abney effect, strongest seen in blues) and also the perceived hue may change at a higher luminance (Bezold-Brücke shift, probably visible in the yellow-orange range). The chromaticity-linear unfortunately model can’t account for these.
Fully saturated yellow (as in RGB = (1, 1, 0)) has the greatest available luminance of all the fully saturated colors along the perimeter, but the available luminance falls off rapidly when we approach red (for example in the orange-ish colors in the sunflower). That’s why, when the original luminance is tried to be preserved, the only option is to reduce the chrominance quite a bit.
As far as I can tell, there is not such a ground truth to “what should an image look like”. Hence, using your own eyes is encouraged. Most of this (as far as I see) boils down to engineering a reasonable “path-to-white” - how those very high luminance colors are fitted to the display. This is arguably a very important task for all “image formation” processes - that is, what filmic does in darktable. There are several attempts around which all have their good and bad sides. Filmic v5 was also one attempt - there the path-to-white was implemented as a specifically crafted desaturation curve. In filmic v6, the path-to-white is determined from the display gamut and original chromaticity angle is preserved at all costs.
There’s still no single ultimate solution out there, but there are some recent promising developments. Personally, I’m keeping a close eye on what happens in the Blender community - there are some folks making an improvement over the Filmic that was implemented for Blender (and where also darktable’s filmic takes inspiration). There’s something called AgX that’s discussed in this thread and it looks very promising so far.
TL;DR what is seen here is a function of filmic v6’s design constraints, specifically in the “path-to-white” - fitting saturated, bright colors into display. There are quite a few approaches, and none are perfect. As it currently stands, depending on the image one approach might be better than the other (e.g. filmic v5 over v6). I think it’s safe to say that filmic v6 won’t be the last iteration of the image formation process in darktable, but I also do think the next iteration will have to be carefully considered and tested against a wider base of test images. AgX development might be something to follow.
Unfortunately I don’t have much spare time at the moment so I can’t promise to follow this thread very closely, but I’ll try to respond to pings. I hope this reply was at least slightly useful.
Some of this might have to do with the fact that filmic brings the chrominance right to the edge of the available gamut. I think also the gamut check functionality uses Little CMS 2 somehow, and I don’t have looked up what LCMS2 does in that case. However, I think the gamut check only shows the part that is too saturated - i.e. the “lower boundary” I was talking about.
10 Likes
Also here’s one more, as images speak tons more than text. Here’s a couple of different yellows and oranges, desaturated by mixing with white. See anything familiar here?
11 Likes
Thanks a lot for being patient and explain this again.
I slightly get it. It is even harder to digest, when here we are not talking about clipping but preserving luminance.
I think your statement, that each approach is not ideal has a very sympathetic athetic touch.
I just wonder, what would be the best approach for those oranges we see in above samples, where I don’t like to see the magenta cast on the right. The examples on the left look nicely rich and pleasing to me, even I understand, that the aim of v6 might got jeopardised by the method and hue shifts might appear in other scenarios…
Here’s an attempt. XMP from original post, latitude decreased to 0.01%, white point increased to 4.5 EV. Nothing else touched. Rationale for latitude change: smoother desaturation at the highlights, at a lower rate. White point change: give the yellow-oranges a bit more room to get full saturation.
Aside of this, local exposure adjustments prior to filmic could serve towards the desired goal.
I sympathise that it might be easier to get good looking yellows with the filmic v5 color science for this kind of imagery. The yellow area seems pretty sensitive. There might be some low hanging fruit for improvements on filmic v6 - e.g. possibility to give up a bit of the hue preservation (that is actually chromaticity angle preservation as currently implemented) or relax the gamut mapping a bit. That might introduce a desirable skew to yellow which would, in turn, allow preserving more chroma in the yellow highlights. But all speculation at this point. I’d rather look forward and look around as there are plenty of other people experimenting with this stuff in the context of other software.
10 Likes
I was thinking to try that …for some reason I could not open the patch file to examine what it did…I might give that a try…
This is a text book reply and very useful to explain the nuance of what is going on. I for one appreciate the opportunity to be further educated around this topic and this post is really helpful from a big picture perspective which is what is needed …Thx
2 Likes
@rvietor what do you recommend for the histogram settings. Here are my settings. Do you see any problems?
1 Like
@flannelhead Thanks for taking the time to give such a nice background on this! It’s all really interesting.
2 Likes
Just wanted to say thanks for the best explanation of what’s happening in v6 that I’ve seen yet 
I’m following this thread with interest - even if I glaze over occasionally on the code related bits…
@bnpndxtr 's work looks very interesting. Keep it up everyone!
2 Likes
Yeah, what you did is similar to the way I used to get anywhere close using the std build. To what you listed I would add that moving the shadows/highlights balance far to the right causes a similar effect to pulling out all of the latitude, and could help sometimes. Both pull highlights away from the shoulder.
Let me ask this, as I’n curious- If I disable the gamut_check_RGB() function like I have here, if I were going to see issues, what would I expect to see? So far I’ve used this on lots of images and I’ve yet to see anything other than as good as or better looking results (understanding of course that is partially subjective)?
1 Like
I’m not recommending anything, I wouldn’t know how. For what it’s worth, I use those same settings (except histogram profile set to “work profile”, which is linear Rec2020 RGB). I just noticed the effect of that setting, and how it corresponded to the change in colours after passing a certain level under rec2020.
That said, it makes sense to have your histogram reflect your working space, so you don’t push parts of your image outside that (loss of detail at that end of the range). You’ll still have to keep an eye on the displayed image as well, and do gamut checks if you need to export to yet another space.