Comparing filmic color science v5/v6

Not absolutely sure, but I thought that one of the design aims was to change only the luminosity, and leave hue (and possibly chroma) alone. That what you posted a bug report about, if I understood correctly

Anyway, my remarks were in reply to @nosle 's posts, where he complained about filmic not causing a fairly large hue shift he felt was required to get a correct image. And that’s certainly not filmics responsability.

I did manage to introduce a bit of yellow in the flames with the color balance and a bit of masking, after reducing contrast with the tone equaliser:

1 Like

Given the direction the thread has taken, maybe someone might find some of these discussions interesting:

2 Likes

YES!
While not everything discussed there should be seen as “gospel” I think it is a remarkably well informed discussion about goal definitions of a DRT, different approaches for creating DRTs and presenting intermediate results that are somewhat meaningful (including, but not limited to exposure sweeps) enough to compare different DRT approaches.

Reading those threads brought up the idea ushered above that judging fire (it’s representation by a SDR-DRT) is a lot more complex than starting with test-swatches that gradually get brighter and must dechroma at some point, or out-of-gamut swatches that need meaningful representation inside a much smaller gamut.

I can highly recommend reading those discussions.

A last comparison:

the first image is the result of a sigmoid tonemapping on the rgb channels, as final step I’ve copied the original hue (from CIE LCH) to the tonemapped image
t004100.pfi (39.4 KB)

this second image is my tonemapping

1 Like

I’ve just dipped my toe into those discussions. Wow! Until recently I never realised what a complex area this whole tone/gamut mapping thing is. Thanks for taking my thoughts onboard everyone… I think I might back out before I expose my ignorance any further :smiley:

On second thoughts, I have a quick question… If I use the color picker set to LCh, does the ‘h’ show a valid reading of hue? I ask because I tried switching filmic in and out while adjusting exposure, on @bastibe 's sunset image, and filmic does shift it a bit towards blue - not sure whether its a significant amount or not. If anyone wants to try, I was simply pushing the exposure up and down, with filmic enabled, while watching the color picker on a spot in the bright bit near the sun.

It seems to me that we need to add the norm before assigning something to filmic so filmic plus this norm resulted in this effect because simply using a different one can make the observation something different

I was actually quite happy with my filmic less edits near the start of this thread…no wrestling with norms and color science :slight_smile:

I’m just about to give sigmoid a go, in your portable build from a few months back… I’m feeling a little filmic-jaded myself :grin: To be honest though, I don’t think I had worried about it too much before I found this thread. Maybe I need to take a step back and actually take some photos!

Sigmoid is very user-friendly on the fire image - by default it gives a bit salmon flames, but it has a hue preservation slider that lets you go all the way to ‘ratty’ yellows if one wants OR anywhere inbetween. It doesn’t feel as flexible as filmic but as an option I think it’s quite good. Having said that, I sort of understand AP’s view that it’s an unnecessary option, but I can’t see anything against having it available…

One more observation, before I head off for now. Sigmoid doesn’t handle oversaturated colour very well… a bright red car turned partly black when I pushed the saturation a bit in color balance rgb. Whereas filmic V6 effortlessly pulls it in line.
I expect there’s a good reason for this, but my feeling atm is that neither are ideal, filmic or sigmoid. Maybe the perfect one doesn’t exist yet…?

It would take some poking in the code and someone likely knows the answer strait away but I think some of the modules might take data from filmic if it is activated…maybe not I just thought I recall AP talking about the scene referred modules being coded/designed to work together so it could be a bit of this that you are seeing… This could also be complete rubbish I am just going from someting I think I recall hearling… :smile:

that’s not the case. Exposure and Filmic modules take the exposure compensation from the image exif data and use that info to set their parameters accordingly; there is some communication between white balance and color calibration to flag to the user when there is a doubling up of CAT. But apart from that, the modules all operate independently, and each perform their own gamut mapping to ensure valid values on their output.

If this sigmoid thing is outputting black pixels, it is most likely a buggy implementation in that code.

1 Like

Thanks I was certain AP had made mention of some interplay between filmic, color calibration and or color balance but as noted I really had not investigated…thanks for setting the record strait…

Why? Surely the most important gamut check is to see what will happen when we produce the output, whether this is a print or a file for people to view. The functionality provides for that.

Friends, is there any masking going on in the filmic module? I mean… I came across a weird effect when I combine max RGB and increased exposure. There are trees, a clear sky behind them and if I increase the exposure, the sky stays the same but the trees start shining and there’s a glow around the branches. It occurs to me that hue preservation is in fact not quite a good thing at all.

Max RGB, +0 EV


Max RGB, +2 EV

No hue preservation, +0 EV

No hue preservation, +2 EV

Don’t you have CA around the branches and twigs? I think I’ve had some shots with strong CA that looked a lot better with filmic once I cleaned that up.

Hue preservation is indeed a good thing. Otherwise you get unwanted hue shifts when you apply a tone curve.

Regarding your artifacts, from the manual:

[…]
max RGB is the maximum value of the R, G and B channels. This is the same behaviour as the original version of the filmic rgb module. It tends to darken the blues, especially skies, and to yield halos or fringes, especially if some channels are clipped. It can also flatten the local contrast somewhat.
[…]

Regarding the infamous salmon colors, even though not explicitly, AP explains it all in this video.

Filmic does not shift hues, as designed, but that doesn’t mean that the colors will look right to our eyes. This is what I believe happens to our flower, sunsets, and fire with filmic: Bezold–Brücke shift - Wikipedia

Since there are no comprehensive studies done on the subject, as AP has said, filmic will “fail” in a consistent way, so to fix those colors I understand that we need an instance of color balance rgb with a local mask. Meaning, the hues are “right”, as in, they are the same hues as at the input, only they don’t look right to us. Anyways, an easy fix, that will only affect a small number of the photos I take (sunsets, fire, high key sunflower pictures).

It seems like in the end there is no problem, and it’s only user error (also on my part). Once you know what to do, it’s very easy to fix.

4 Likes

Well there’s certainly some CA as no lens is perfect. But I don’t see any. The image is not processed in any way. There’s only a default set of modules. You can see there’s no halo around the branches with hue preservation turned off.

You can’t turn hue preservation off in v6. You did turn off chroma preservation, though