Ah, my bad.
Oh now it came to me. Max RGB takes the max value of one of the three channels and converges to it instead of white, right? Hence deep blue sky. Colors which canāt be that easily classified donāt get that much treatment and remain less saturated, so the pixels between green branches and blue sky turn into that weird halo. Correct me if Iām wrong. Iām just a user.
I think the different norms are the basis for applying the filmic tone curve. Then, for each pixel, the new value is assigned based on how they are related to the norm.
So, if you have pixels with values like 1000, 1200 and 1500, the norm will be 1500 in case of maxRGB. Say that the tone curve projects 1500 to the value 240. Then, the pixelās new values will be 240/1500 * 1000 = 160, 240/1500 * 1200 = 192 and 240/1500 * 1500 = 240. The RGB ratio is maintained, so the hue is preserved, if I understand correctly.
If that colour lies outside of the gamut, some further processing is done.
With no chroma preservation, the curve is applied to each channel independently. Since the steepness (gradient) of the curve is not constant (it becomes flatter as we approach the user-defined white point), R=1000 and G=1200 will be mapped higher than with maxRGB, letās say to 180 and 210. B=1500 will still be mapped to 240. Since the values are now closer together, you get desaturation ā but also hue shift. filmic v6 will now go one step further, and restore the hue (but maintain the desaturation).
5 Likes
Also doing something like that you would readjust the white point. which would change the result you seeā¦
This is what color management is for as long as you donāt break the gamut in the working profile it should be mapped by the output profileā¦
Edit: Right now the overexposure indicator set to full gamut shows gamut based on the histogram profile. Change it to a smaller color space and more of the image is out of gamut. The gamut warning is doing the same but is using the softproofing profile not the histogram profile. I thought these would be the same result. I was also under the impression that the softproofing profile was used when activated in place of the current display profile to allow you to make corrections for accurate output for the most part printing. In any case I really donāt care if I am concerned with accurate gamut I set working display and histogram to rec2020 so there is no colorspace conversion issueā¦Iāll trust the output profile to map in gamut rec2020 to sRGB. If that canāt be trusted then DT has broken color management
BB describes:
- yellows (570ish nm) have almost no BB-shift
- reds DO shift towards yellow for higher brightnesses
The observations above are:
- the sunflower shifts visibly salmon
- the embers in the fire are too salmon
additionally:
- RTs CAM16 which does not account for BB-shift (to my knowledge, at least explicitly, maybe implicitly it does) does not show the salmon shift
- @age 's sigmoid in photoflow where he replaces hue with CIE hue (which does not account for BB to my knowledge) does not show the salmon shift
On the BB-shift? Or on the integration of BB-shift into a CAM? For the latter Iām actually not sure (could be implicitly accounted for) for the former, what would entail comprehensive studies? There is quite a lot of data available: Bezold1873, Purdy1931a, Purdy1931b, Boynton1965, Savoie1973, Larimer1974, Larimer1975, Hunt1989, Pridmore1999ā¦they donāt agree on everything and use different methods, sure, butā¦
Surely you donāt set the display profile to any of the rec2020s?
That mapping happens but my point was that you might want to see where the sRGB gamut is exceeded, in which case it will be truncated or squashed in. Then you can choose to do something about it, e.g. reduce saturation with color bal rgb, and perhaps retain more detail in e.g. brightly coloured clothing.
This is way above my paygrade. Watching the video I understood that dtās filmic wonāt shift hues at all from input (this I confirmed via color picker). I believe AP is saying that accurate does not mean pleasing or even realistic to us humans. I believe thatās precisely what happens in the sunflower picture, as well as in sunsets and fire. He quotes a paper from someone that used to work for kodak that talks about pleasing hue shifts (for skin if I remember correctly), and says that those kinds of shifts should be done locally via masks by the user (since the darktable dev team is not kodak, and doesnāt have the means to conduct such research). Darktable provides a neutral base, upon which we can and should make changes. I donāt know if Iām making myself clear, but the video goes into this in much more depth than I could. Anyways, as I said, I only encounter this issue every once in a while, and is easily fixable.
3 Likes
Have you seen the PR (Iāll have to dig it up there are a few) and recent discussion around gamutā¦because DT feeds the data through display first before sending it to the histogram profile ā¦the smaller color space can clip the data so to get true clipping you set the display to rec2020ā¦ the image on your screen will be ugly but the clipping will be accurateā¦
This was already a response to you but this is what I am talking aboutā¦ explained by @flannelhead
This holds true assessing gamut from the over exposure clipping warningā¦the gamut warning is handled differently ā¦it seems referenced against the softproofing profileā¦
Comment by AP regarding this issue, for anyone interested:
2 Likes
Thanks for this!
APs statement, while not wrong, does need a bit more context IMHO.
- The shown graph for āAbneyā effect is in the nice Pridmore paper to demonstrate that there is a lack of naming consistency. The graph does not show disagreement, but experiments which measured different things but called it the same effect. Deriving from that there is no usable hue constancy metric would be not exactly what this graph tries to convey.
- Kirk Yrg/Ych is not explicitly designed to be hue constant. It does somewhat okay at munsell data, which is the only data that was used to optimize the colorspace. The original paper even states that
We need to extend our experiments beyond the reflection
colours of the Munsell colour book. We could extrapolate points in
(r,g) on a high-gamut display and see how far this Munsell-like
uniformity goes.
The novelty of Kirk Yrg was that its based on LMS instead XYZ and would be a better colorspace than Yuāvā for example.
So if there is no fault in APs implementation of Kirk Yrg and the colors are what Yrg does, maybe we are seeing problems with Yrg in that it cannot compress chroma of red-glowing embers (out of munsell gamut), sunflowers backlit by sunlight (out of munsell gamut AND probably too much DR), or sunsets (maybe out of munsell gamut AND definitely too much DR). Testing that would indeed entail what AP writes, trying the same in another colorspace.
Sorry if I appear picky. Tracking down what the error might be is not straight forward when there is
- wrong-math-in-wrong-colorspace
- wrong-in-right
- right-in-wrong and
- right-in-right
when there is indeed a sliding scale of better-worse not right-or-wrong at least for colorspaces.
2 Likes
Before Aurelien implemented his gamut mapping in filmic, @flannelhead was working on his own solution. This hasnāt been merged, but Aurelien was not against there being another option. I guess if any significant differences are found it might become so.
2 Likes
on the flower using the filmic reconstruction tab (set all the balance settings to the right) and adjusting relative white exposure I get good results. Once i add the tone equalizer and color balance to saturate and boost back the highlights I get even better results. my reason for going to reconstruction is that the petals are clipping.
Sorry I misunderstood, I thought you were saying you routinely work with display = rec2020!
1 Like
Iām ok with this gamut clipping but only if:
-
gamut clipping is done at the end of the pipe, not inside filmic
-
users could disable or enable this feature
My tonemapping method is designed to keep the saturation in the highlights while in the same time not doing overflows in the working rgb profile used, actually it slightly darken the āluminanceā in the highlights
This is usefull to avoid orange shifting to salmon hue, blue shifting to purple, red shifting to pink,ā¦
1 Like
Does that mean you chose to move āout-of-gamutā to lower luminance, where filmic moves those colours to lower chrominance? Because you are still doing some form of āgamut-clippingā in your tone mapping.
As you have to, when not allowing out-of-gamut colours in the moduleās output.
Of course, if thereās a way to prevent such colours entering your tone mapping, that might be even better. Not sure how feasable that is.
It seems that filmic is doing a rec2020 ->srgb-> gamut clipping to srgb->rec2020 conversion inside the module itself.
So after the module there no reason anymore to work with a wide gamut color space
Nope, Iām not doing any gamut mapping inside the tone mapping
That statement doesnāt look right to me, simply because APās gamut shift diagram, as referred to just above, says āKirk/Filmlight Ych spaceā is used.
I was wondering how big Kirk/Filmlight Ych space is in relation to rec2020. Does Filmic look at your Export Profile and take that into account when gamut mapping, perhaps? Iām surprised if anything is fixed on sRGB because I thought the philosophy of Filmic was that itās somewhat future-proof, in that when we have big-gamut screens, weāll be able to make use of them without completely re-editing our photos. Iām not sure how that will work in practice, anybody? I just had a quick look at Filmic in the manual, Display tab, nothing leaped out at me.
Maybe this, however it has not sense to do it inside filmic (this should be done in the color space conversion module or in a new module) and it has not sense to force users to do it always without the possibility to disable this gamut mapping.