Sunflower Sagas and Solutions

bnpndxtr · October 30, 2022, 12:54am

For the last several years I have traveled to a sunflower farm in KS for a photo shoot. The field of rich color is hypnotic and it’s a lot of fun.

Unfortunately this year I discovered that the new filmic RGB v6 doesn’t deal with the rich colors without it applying excessive amounts of desaturation and in some cases color shift. To deal with it you have back off on highlights color brilliance and/or exposure and perhaps throw away a significant portion of the histogram range. You end up with dull, sometimes under exposed-looking images that nobody could argue looks good.

I used a workaround for while where first I reduce the color brilliance of the highlights until the weird desaturation and color shift go away, and then boost the brilliance of those same highlights by the same amount post-filmic. I can get OK results this way, but I shouldn’t need to do this (never had to in the past). And although this “works”, you lose filmic’s tone-mapping benefits for those highlights as a trade-off.

I finally decided to try to figure out where this happens in the code. After some experimentation I found it and disabled it in a test build. IMO it produces much better looking results now in every color preservation mode. I’ve been using this test version for several weeks and I will be sticking with this as my standard version for now.

You might say “just use filmic v5”. It’s a fair comment, but there are other differences between v5 and v6 and I like v6 so far in general except for the behavior I’m describing here.

What I’ll include next are several test images. With the exception of the first one which is mine (the sunflower, CC-BY-SA), these are all images freely available on the web: DPReview sample raw, RAWSAMPLES.CH (CC-BY-NC-SA), https://www.signatureedits.com/free-raw-photos.

After the test images I will attach a source code patch file that you can use if you are interested in trying it out. The test version makes no change to any database or XMP file structure, so it won’t mess up anything with that. It simply alters the behavior of filmic RGB.

Each processed image here will be presented as an A/B comparison between the test version (image on the left) and std darktable v4.0.1 (image on the right). In each pair of images, the XMP file is exactly the same, and is the one used to develop the image on the left. The image on the right is simply the same XMP file opened in the std darktable v4.0.1 against the same raw file.

For each raw file there are 5 A/B comparison images. The only difference between the 5 comparisons is the color preservation mode chosen. I did the raw file developing using the test build with “no” as the preservation mode, the mode I personally use the most, and then simply changed the preservation mode for each of the remaining 4 comparisons without doing any other edits. I’ll comment a bit more along these lines after the images below.

0L0A3314.CR2 (33.3 MB)
0L0A3314.CR2 (filmic v6 ngm).xmp (33.2 KB)

DSC08632.ARW (23.6 MB)
DSC08632.ARW (filmic v6 ngm).xmp (11.8 KB)

_DSC8160.ARW (23.8 MB)
_DSC8160.ARW (filmic v6 ngm).xmp (28.6 KB)

IMG_0753.CR2 (32.8 MB)
IMG_0753.CR2 (filmic v6 ngm).xmp (10.7 KB)

RAW_CANON_EOS-M3.CR2 (27.2 MB)
RAW_CANON_EOS-M3.CR2 (filmic v6 ngm).xmp (20.4 KB)

Signature Edits Free Raw Files - Tag @signatureeditsco IMG_7837.cr2 (21.2 MB)
Signature Edits Free Raw Files - Tag @signatureeditsco IMG_7837.cr2 (filmic v6 ngm).xmp (18.5 KB)

|
|
|

So you might say that the A/B comparisons are unfair to some degree because I didn’t try to optimize the edits using stock filmic v6. Well, I didn’t show them here but I did experiment with that too. And I spent plenty of time doing this after this year’s sunflower shoot. With max RGB in std darktable you can get sometimes close to my “no” edits either by sliding the latitude slider to zero to “shrug the tone mapper shoulder” or by leaving the latitude alone and moving the shadows/highlights balance slider far to the right (again shrugging the shoulder). Or you can just make the image darker. Neither of these moves are required using the experimental build. I don’t have to give up any shadow or highlight range by pushing the shadow/highlight balance almost completely to one end, give up a wide range of decent contrast by totally pushing the latitude to zero, or losing local contrast/detail by switching to max RGB. And lastly even if switching to max RGB or one the other preservation modes is preferred for some reason, they all look better using the experimental build anyway.

Here is the src code patch file.

darktable_v4.0.1_bp_test_ngm.patch (22.4 KB)

Summary of changes made by the patch: For both the normal and openCL versions of filmic RGB, disable calls to gamut_check_RGB. Instead, do the conversion from Ych back to RGB and then clamp RGB to display_white. I also changed the “darktable” text in upper-left corner of the application window so that it is obvious it is test version of darktable.

To use it, first follow the instructions for a normal build here to download the source code: GitHub - darktable-org/darktable: darktable is an open source photography workflow application and raw developer

Use the patch file just before you run the build command to compile the source code. Put the patch file in the parent folder to the darktable source code folder that gets created when the files are pulled to the local computer. Then navigate to the “darktable” folder, open a terminal window and type this command:

$ patch -p1 < …/darktable_v4.0.1_bp_test_ngm.patch

Compile/build prerequisites: Assuming Linux, you need to have both LLVM (Linux Mint: sudo apt install llvm) and Clang (install via SW manager) installed.

Final thought: I think it would a very useful and simple modification if a checkbox could be added to Filmic RGB options tab that would globally disable the gamut_check_RGB function via a user selection. Users that want it could have it, and users that don’t won’t.

priort · October 30, 2022, 3:55am

Thanks for taking all the time to explain what you have done and sharing the code…

Edit …tried it on windows… copies to darktable folder and darktable\src terminal command says it can’t find it…

I must be doing something wrong

rvietor · October 30, 2022, 7:03am

What profile do you use for the histogram?
I see what you mean by not using a large part of the histogram when using the working space for the histogram. But if I adapt the histogram using the working profile, and then switch to look at the histogram for my display profile, the highlights are way off the scale (which of course clips colours to white).
If I adapt filmic so that the histogram fills the available space for my display profile without clipping, I get the rich colours you want.

(Note that changing that setting doesn’t change the image in any way)

AxelG · October 30, 2022, 7:07am

@bnpndxtr
I am not a coder, just a user and tester fo gh master release of dt.

That “salmon-ish” color cast has been discussed widely and finally always reached the point “because green pixels clipped first”. As much it is technically maybe correct, something in my gut feeling never got fully convinced.

I see that magenta cast on the pumpkin and on girl’s heat in your above samples…

However on the developer’s version on github there is a new mode in highlight reconstruction module, called “inpaint opposed”. That has eliminated most of those problems.

I did not check if your above pics have sensor clipping, as I’m reading via phone atm…

Also some defaults of filmic have been changed recently, which might make your issue even better.

So would you mind trying gh master?

Actually github would be the right place to promote your code.

Sadly Aurélien decided to leave the dt community and also is barely open minded unless you proved to deserve his respect (I will stop Bein polemic here)

Maybe @flannelhead would take a look to your changes?

Cheers
Axel

AxelG · October 30, 2022, 7:28am

I keep forgetting, where to change that

rvietor · October 30, 2022, 7:46am

Right-click on “gamut setting” gives you a few options to change, histogram profile is one of them.

I think the question is “how and where do we want to correct out-of-gamut colours?”. Filmic RGB seems a rather logical place to do that: end of pipe, we have to do a colour space conversion there anyway, and I understood the gamut mapping could be done in a hue-invariant way there.

jorismak · October 30, 2022, 9:49am

Thanks for the patch. When the little one allows me to get some sleep , I’ll dig in.

In the meantime : others have already mentioned that the scene referred defaults changed a bit lately , from a commit that aurelien did back in June in his r-darktable. Latitude to almost 0 and the contrast curves to hard is part of that. This often gives more pleasing results IMHO.

In the first sunflower picture , i ‘solved’ the unused histogram by using rgb levels or curves after filmic. But basically you are then clipping something , but the results are more pleasing, more punchy.

If stuff like that is more easily had with your patch, it’ll be interesting.

Also, aurelien had been on that there seems to be missing a gamut check step in the output section of darktable . In a way that he has a branch with a lot of stuff removed to redo it. But since then it’s been quiet.

Did you try if selecting different working profiles and or output profiles had any effect ? Just curious.
Or a difference between the output profile used in export and the one used in the ‘output module’, in the chain.

To others :
Magenta casts ARE often the results of clipping highlights. It can be highlights not reconstructed (which are then magenta or another color in the real raw data because of clipping + white balance ).

But the older reconstruction methods can produce weird results together with the modern color workflow (color calibration after white balance, with reconstruction in between).

In dt master this has made huge strides since more reconstruction methods and more 'user friendly defaults '.
Only issue dt still has is wrong white points in some cases. Patch for Sony has made quite a difference, but still issues reside in files from other manufacturers.

bnpndxtr · October 30, 2022, 2:40pm

I use the working profile for the histogram profile (linear rec2020 RGB). I actually use the waveform view mostly now, not that it matters. The upper dotted line is supposed to be 100%, but what profile? Well it appears to be the display profile based on my clipping to “display_white”. I say this because while I was experimenting I changed the clipping value from 100% to lower values just to see what would happen. Well the clipping level just moved down to various points below the upper dotted line, based on the new clipping point you pick.

So even though I’m using linear rec2020 RGB as my histogram profile, that upper dotted line is 100% on the display profile, not the working profile.

bnpndxtr · October 30, 2022, 2:48pm

I think there is no clipping going in where the SW starts mashing the color in the cases I’m highlighting here. It starts well below any level where any channel clipping starts. That is part of the issue, and is why one would tend to back off on exposure to fix this, even though nothing may be clipping.

Raw clipping is not a factor in the cases I’m highlighting here, so it is definitely not a highlight reconstruction thing.

As far as github goes, I’ll admit right now I’ve never used it and am not very familiar with it. On my list of things to do. I’ve written code before but only for personal enjoyment, and not that much in a while. I’m not really promoting code here, but rather trying to expose a problem and lobbying for a simple and minor change.

bnpndxtr · October 30, 2022, 2:54pm

So while into the code, I saw more than one kind of gamut mapping being done in filmic v6. the first one is in the Yrg space, and I left one alone, as it didn’t seem to be causing the issues I’ve describing here. The one associated with the weird color effects here is gamut_check_RGB.

My argument is not that filmic is the wrong place to do “gamut mapping”, but simply that whatever technique is being used now is yielding bad-looking results, and I’m tried of monkeying around in the display referred end of the pipeline to fix it. I would even go so far as to say it looks “broken”. Maybe there is just a bug lurking there somewhere. I might dig some more later.

bnpndxtr · October 30, 2022, 3:05pm

Interestingly what you mention about doing things post-filmic to compensate is just what I was doing before this experiment. I reduced the brilliance of the highlights affected by the desat/shift, and then after filmic just boosted the brilliance of those same highlights by about the same amount as I cut them. Again this kind of works, but then you lose all of the tone-mapping benefit of filmic. But now I don’t have to :).

We should not get hung up on my comments about giving up histogram range too much, as the goal of photography is not to fill the histogram, and that was not the point I was trying to make. It’s just about the effect on the brilliant colors. I just thought it was funny that when you back off on luminance, etc, to below the threshold where the SW starts affecting the color, it looks like you haven’t adjusted exposure right sometimes because the histogram is not filling the right.

And then just to make the point again, because these concepts are sometimes confusing, the issue I’m talking about here is not from channel clipping. There are no raw image blown out channels in the affected color areas in the examples I’m using here.

g-man · October 30, 2022, 3:22pm

Can you share the actual code changes? Maybe in an issue in GitHub. Maybe someone can provide a on/off selection to the gamut check rbg.

AxelG · October 30, 2022, 3:29pm

@bnpndxtr actually that gammut thingie was one of the major aims for V6. If AP would be still here, you would face intensive discussions

For me the code is way over my head.

You can still reach Aurélien via IRC or more precise matrix, as there is a room for R&darktable, where he might be active still

jorismak · October 30, 2022, 3:30pm

True!

I just remember that sunflower pick from the playraw. I had issues with it, in the sense that i didn’t want any white on the flower petals. But lowering the white that much (with whatever chrominance mode got me there ) removed the punch from the image. Whatever you did before filmic , didn’t remove this , since filmic always flattened it. So doing something behind it made sense.

In photoshop (or alike) tools i would fix this by using an levels adjustment . So i went searching for something similar here.

I don’t have have this issue much.m. i remember the flower because of it :).
It’s one of those rare cases where ‘commercial tools’ got me in a likeable place quicker.

So, looking forward to trying it out.

Still wondering if that code does what its supposed to do , and what it’s doing then .

bnpndxtr · October 30, 2022, 3:36pm

Yeah the code changes are shown in the patch, but here are the source code files themselves. Do a text search for the word “test” and you’ll zoom to the section with the simple change that stubs out the function calls to gamut_check_RGB. I had to append “.txt” to their extensions so they would upload here.

non-open CL version:
filmicrgb.c.txt (205.3 KB)

openCL version:
filmic.cl.txt (47.6 KB)

priort · October 30, 2022, 3:41pm

I always kept it simple from what AP said in his gamut freak video…set histogram equal to working and as long as you don’t clip there let the output profile map it back to whatever you are outputing… This makes sense to me…otherwise we would all be setting this to display or srgb and working to keep the histogram in that space but perhaps this is not what you are talking about and my apologies for being dense…

AxelG · October 30, 2022, 3:42pm

I can see, yes. I tried your sunflower with the defaults it looks not so weird but dark, yes…
If you would discuss with AP, he would say “oh out of gammut, tough luck” (I simplify, admittedly)…

Your mods show much nicer colors to me visually, but I am not into color science unfortunately…

This BTW: is what current filmic in master does, if I press the eyedroppers

priort · October 30, 2022, 4:21pm

I think a lot of this is likely answered in AP’s UCS thesis document. I think in the end he has worked to make things mathematically accurate but in doing so there is often the need to rework things post filmic to get what many would expect as the pleasing or actual representation. In most cases if you go to color balance after and mess around you can get there and for one off edits or a purist wanting a precise technical edit this is likely the ticket …but if someone takes 20 shots of sunflowers you might be able to edit one with this approach and copy and paste but you might not if the lighting changes a bit or whatever so I think in some cases Brians approach or perhaps using v5 as I think I would do rather than fight with v6 is what I would do…

AxelG · October 30, 2022, 4:24pm

fully with you @priort …

This is what I got from V5 w/o colorbalance and Brian don’t want to go back to V5 actually, which is understandable

AxelG · October 30, 2022, 4:26pm

we actually argued a lot with AP on IRC about the magenta cast, which I desperately dislike. But we never made it to something suitable for a normal user. (you gotta learn, gotta understand, was ever the mantra)