Possible case of filmic's preserve chrominance not applied in exporting

Processing
73

Thanks for taking the time to give these nice examples.

So most of the goofing around I’ve been doing on this thread was on my laptop, either during lunch at work or sitting on the couch in the evening. But that screen is not calibrated and also not full sRGB.

However most of the real editing work I do is on my main desktop that has a calibrated sRGB monitor. So I’m looking at things on the calibrated system now for comparison. Interestingly the differences now between the image in the DT editing session using std filmic v6 and the rendered result are basically gone. There are certainly differences between how the live image looks between filmic v6 and v5, but those differences track to the renders as well when viewed using my nice monitor. Same goes for the hacked version of v6 I use- looks the same in DT as in the rendered image viewed externally.

Immediately switching to my laptop and opening up the same renders I just made on my desktop, and comparing them to what I see when opening the raw file in the DT editing session on my laptop, the color differences between the live editing session and the externally viewed renders are back once again.

I think there is no point in posting results, as everyone on this thread is probably seeing something at least mildly different than what I’m seeing unless they are using a calibrated sRGB monitor.

So in my case looking at this image, I think a large part of the reason the foreground flowers in the std filmic v6 image turned significantly more red in my external viewer was that my laptop display is not that close to sRGB where it mattered for this image.

74

That’s not really the case though. It would mean that the view of a highly saturated image on a high gamut display and a srgb display are identical.

No reason for buying the super expensive display if a srgb gives the same view.

75

Fair 'nuf. Should have said, “about the same.”

But my fundamental observation holds, that’s the purpose of the ICC pipeline, to present some level of hue and tone consistency in image renditions across different media. sRGB won’t accommodate the hue gradations a higher-gamut display will, but neither can accommodate the gradations of what the viewer regarded at the original scene. Both require some kind of shenanigans to make hue gradations that approximate the scene. One of the many reasons our photographs are just a coarse approximation what was seen at the original scene.

76

I know the point of colour management… I also know that the way filmic v6 picks it profile to do the gamut mapping is that it basically breaks colour management .

By choosing a profile that you cannot change and have no control over , and isn’t always the correct one for the situation.

The more and more i try to explain this , the more it gets clearer that the one and only issue is that filmic v6 ignores any softproofing.

You can already pick a profile to use for softproofing, you can already enable or disable softproofing… Make filmic respect it. That’s all.

Somebody explain softproofing to me. Because maybe I’m just wrong on how it works or what the purpose is .
But in my mind , soft proofing is basically done by forcing an extra conversion step. So normally you go from working profile to display profile and then on screen. With softproofing you go from working profile , to a profile of your choosing , to your display profile and on screen.

So if i want to export a file linear rec2020, and convert it to sRGB in a later step, i basically want to softproof how the export would look if done to linear rec2020 , and then to my display profile (assume sRGB for this).
I can’t , because filmic still picks my display profile to do its gamut mapping , even with softproofing enabled but when export time comes , it suddenly switches to a different profile.

I know my monitor can’t handle rec2020 , but that is exactly what i want to see. I want to see the colors clipping , because that’s what the final export looks like. Now i get a magic fix i didn’t ask for.

Filmic inserts itself in the whole colour management workflow , but doesn’t let you choose the profile it works with. Just think about that, how crazy is that ?

There needs to be a way to tell filmic what your intended profile is going to be . Softproofing profile (and if softproofing enabled ) is the perfect place for that . But just using the profile in the ‘output profile’ module would also help .

Just thinking out loud. Imagine the reverse situation. I want to export to a narrow gamut profile, but my monitor is way wider than that. Imagine you have a monitor with full Adobe rgb coverage, or some other wide but realistic one (dci-p3?).

Filmic will always map the gamut to the display profile , so to Adobe rgb kind of gamut . But in export time , it will do it do sRGB of that is what we’re exporting. So it will do way stronger gamut mapping. You have NO way to preview that , without first trying a test export. No where can you tell filmic ‘do the mapping to sRGB’ and then preview it on your adobergb monitor (which is perfectly capable of it ).

1 Like
77

Sorry, the statement you made in that previous post didn’t convey that. However, in the rest of your post here, you definitely get it and state my specific concern quite eloquently.

ICC color management has its warts, but that is what is inculcated in the culture. If one wants a fighting chance of having their precious rendition rendered the way they want it in the widest variety of situations, they’ll export to sRGB and embed that profile in the rendition file. ICC profile.

New high-gamut displays only cement that. No standards in play like there are in theaters, ACES folk have it so easy. And there are still old fools out there like me, cherishing their precious sRGB antiques…

Filmic started life as a tone curve. Given what damage a tone curve does, I get the idea behind preservation of colors, and with the recent additions the dt filmic module handles that quite nicely. And, those tools handle it in the same way the display and export transforms do, okay. But, to take on the role of the final transform before rendition and not do all the things those transforms require per the ICC workflow does indeed bollox the whole pipeline, locking the rendition into just a few use cases.

Not being a darktable user, I’m looking at all this primarily through the descriptions of others. If I’m off-base here, someone shout out and I’ll take my lumps. But, there’s an architecture to consider here, and it doesn’t sound like darktable filmic is respecting it…

78

I’ve tried exporting from darktable to linear Rec2020 without any filmic or sigmoid curve, only adjusting the brightness. Then, I clipped the C of LCh(ab) or LCh(uv) so the result fits inside sRGB. These are the results.

_DSC8850-ClippingLab
_DSC8850-ClippingLab1625×1080 431 KB

_DSC8850-ClippingLuv
_DSC8850-ClippingLuv1625×1080 433 KB

I’ve written a small tool for this experiment; what I’d still like to do is introduce a gradual saturation drop instead of simply clipping, so saturation differences would be preserved.

BTW, this is what everyone’s favourite sunflower (processed the same way) looks like:

0L0A3314-ClippingLab
0L0A3314-ClippingLab1619×1080 422 KB

0L0A3314-ClippingLuv
0L0A3314-ClippingLuv1619×1080 430 KB

2 Likes
79

Adding 'color calibration ’ (as a no-op) and then adjusting the gamut compression slider ?

80

Clipping and gamut seems to be a messy area in DT. I wonder if it needs a good sort-out. I’m not properly up to speed on all this but wonder about these points for a start -

  • why is the histogram profile involved in gamut checking? (Clipping shown by the Clipping button, whether “full gamut” or “saturation only”, depends on hist. profile)

  • why does the clip button show different results to the gamut check button, which depends on softproof profile? Why are different profiles being used?

  • why do jpegs exhibit out-of-gamut areas when opened in DT?

And then there are the filmic aspects as discussed above.

@kofa , how did you clip the “C” please?

81

I sweep L and h, and use a simple binary search to find the C such that converting to sRGB I get at least one RGB component very close to 0 or 1 (but strictly >=0 and <=1). I store those maxC values in an array indexed by L and h.

Then, I take the Rec2020 pixel values, convert them to LCh, replace C with the minimum of C and maxC[L][h], and convert this to sRGB. Because of inaccuracies, I actually use a slightly reduced maxC, but may switch to actually solving maxC for each out-of-gamut pixel individually.

Sorry if this is nonsense: business coder playing with colours here. :crazy_face:

82

No not at all, interesting, and I know what a binary search is!

83

I didn’t mean to imply you didn’t. I meant to say I’m the one out of his league.

84

I didn’t mean to change darktable processing. I’m just playing around, and learning about colour. Specifically, how one could map any image from Rec2020 to sRGB.

1 Like
85

I think we also still have this issue with the display profile being wedged in between the working and histogram profile in series so unless you set your working, display and histogram profiles all to say rec2020 which will make the image look off but will show the true clipping if any other wise its getting truncated at the display profile and not actually based on what you set for the histogram profile…

86

This is a good tool to check your output if you are trying to do it…

87

Yes, I’ve used it to provide test data.

88

No worries, I didn’t interpret it that way!

89

Nice experiments @kofa ! Hope you found the exercise educational. Perhaps others would be interested to see the code :wink: Some time ago I did almost the same experiment. Just beware of CIELAB, though - even if it’s supposed to correct for perceptual phenomena regarding hue, it actually makes the Abney effect like distortions in the blues even worse than they would be with a chromaticity linear approach. :stuck_out_tongue:

Related to the discussions in this thread, on my side I’ve been prototyping the idea of having a separate module for ”gamut mapping” or whatever you might call it. It would find its place in the pipeline right before the output color profile module. Having it as a module would have several good outcomes

  1. Users of sigmoid and basecurve would benefit from it
  2. The destination color profile could be selectable independent of the current display / export profile. Users of wide gamut monitors would benefit from being able to see the result of mapping to sRGB.
  3. Some tuneability could be added. For example, the tradeoff between chrominance and luminance in the highlights which would be clipped. This could help with things such as sunflower images washing out.
  4. Last but not least, it would allow also having modules applied after filmic / sigmoid / basecurve and still getting the benefit from the gamut guard.

When it comes to design constraints, I firmly believe this module should be chromaticity linear. Any creative distortions (such as making the highlights of a sunset image yellowish) can be achieved elsewhere.

There are right now experiments regarding this kind of a transform in the Blender community. I’m following this closely and contributing my own ideas to the discussion. Let’s see what eventually comes out of it.

What @RawConvert said about the gamut check tools in darktable has been baffling me. I ought to check what is actually happening there. I believe part of this is that the display profile is always (sadly) involved in the measurements done in darktable (including color pickers) but it doesn’t explain everything. It is correct, however, that at least the gamut check that’s behind the exposure indicator button is made against the histogram profile. I believe this is also stated in the manual.

10 Likes
90

Thanks for the kind words.

91

:clap: Excellent. Users will benefit from it. That was what I was hinting at earlier.

92

I would have to go back and find the thread. I had asked about this sort of thing a good while back. I am not sure it was its own thread but after some experimenting I found if I recall that the actual gamut checker is using the softproofing profile to determine gamut and the exposure gamut checking uses the histogram profile. I wasn’t sure why they would be different but I guess if it were not for the display profile one could roughly give you gamut of the pipeline if you set the display temp to rec2020 and the gamut with your softproofing profile set to sRGB would show gamut of output if it was to sRGB??