I’ll just comment on this, as I don’t quite trust the gamut checker tool. You can render an image to sRGB, then immediately open the resulting file in DT again. Then if you use the gamut checker on that image it should be impossible to see anything flagged as out of gamut, and yet I see this happen.
This is why I tend to rely on my eyes rather than the gamut checker, and tend to focus on not clipping the RGB values in the waveform or histogram too much. A little bit is OK.
I’m not sure anymore but if you go to the top, first image. I feel like the OP thinks this is okay and representative… I would not call that red… I think he gets the deep oversaturated reds when he was exporting and that was the complaint…but its late and maybe I am not picking up the nuance of it…
If you extract the jpg it would seem they are…
Indeed. I checked in darktable, and those have RGB code values like (0.7, -0.1, 0.5) in destination primaries, in this case Rec.709 which are the same primaries as sRGB. Note that this is just an illustrative example.
So you see the green channel has a negative value at any exposure (exposure adjustment is just multiplication of the whole triplet by a constant).
Eventually the negative component gets clipped to zero at the output stage and the result is (0.7, 0, 0.5). The ratio of red to blue is 0.7 / 0.5 = 1.4. This is a magenta with an emphasis on red.
If we wanted to properly correct for the negative, we might first add an amount of white to the signal. In this case (0.1, 0.1, 0.1) suffices to bring the negative to zero: (0.8, 0.0, 0.6). Notice now that the ratio of red to blue is 0.8 / 0.6 ~ 1.33 which is less towards red than the above clipped case. This is how clipping skews the colors.
The latter corrected RGB triplet has a greater luminance than original, but this is easily corrected by applying a suitable gain (multiplication by constant). This doesn’t change the ratio.
In the general course of this thread, I notice that some confusion may be caused because filmic rgb maps the output against display profile while in darkroom and against export profile when exporting. The intention is that you are able to see the actual hues (in the HSV / chromaticity sense) while editing, and those same hues are preserved no matter if you export to sRGB or AdobeRGB or some other encoding.
The confusing part is, if your display can’t reproduce the whole export color gamut, the exported file will look different than the darkroom preview when viewed in a viewer that doesn’t do this kind of gamut mapping to preserve hues (most image viewers, I imagine? Darktable is also one of these when you open an exported image in the darkroom). I could see if there’s any clarification to be made to the manual.
You can’t preview the effect. It is as simple as that .
How can you make edits if what you are seeing kn screen is going to be different to what is exported or printed ?
So i don’t know if the problem here is the 'not being able to preview ’ or if the gamut mapping introduces a hue shift in this image… But preview <> export is a problem in my book.
If the sRGB export colours look different from the darkroom preview (when you view the exported image in e.g. Darktable), this is most probably because the display can’t display all of sRGB. So if you export to sRGB, you’re ”in the dark” anyway since you don’t see all of the destination space.
Other reasons I can think of:
I’ve already checked a couple of times when issues like these have been reported, and I believe dt has been working correctly in these cases. So I’m fairly confident in the code. Things like these are pretty hard to diagnose because of the substantially different setups people have (OS, display, display profile etc. )
The whole point is about exporting to something different than srgb.
edit: and it shouldn’t be hard to recreate, the file in this thread thread is the perfect example.
Set up any edit you want with filmic v6 (or take the xmp I posted in the github issue to be sure) and export to sRGB, linear srgb through an icc or to linear 709… and export to linear2020. All the srgb/linear-rgb/linear-709 ones match what Darktable shows inside Darktable. The linear2020 one makes the flowers a different colour.
What this basically means, is that - because my display profile is close to srgb - that any other export option is broken.
Filmic should not be making ‘different decisions’ the moment you press the export button. It should do what it’s doing when previewing on the screen. I understand why it’s doing something different, but that should be user controllable.
If I want to export to linear2020, I should be able to tell filmic I want the gamut mapping to be done for linear rec2020, and that result should be displayed.
Yes, no way my screen can display the entire rec2020 gamut, but that’s besides the point. At least the export will match the preview.
Basically, I’m saying there needs to be a way to softproof what filmic will be going to do on export time. There is none at the moment.
It is user controllable. Export to a gamut your display can handle. By selecting 2020 you are telling dt to make changes you can’t see. The only ways to avoid that is buying a new display or exporting to a gamut covered by your display. No software can possible solve wysiwyg of a larger gamut than the display can handle.
Why are you exporting to 2020 when you can’t see the results?
Thanks for a great explanation. Is this the issue in general or how this might be handled in v6. We sometimes do this discussion and drop the version number… So are you talking about filmic in general or v6… Because I was able to do all the exports in sigmoid and v5 and to any profile and when I opened the tiff back in DT it was color managed to match what I expected in DT…except when exporting to the larger gamut with v6… So I just wanted to clarify as the explanation is presented as a general filmic processing consequence and yet I did not experience it using v5??
Tricky, as you don’t know how the gamut mapping will be done by your viewer application when exporting to something other than sRGB (assuming basic screen display).
When you export to something with the same gamut as sRGB (rec709) that’s a non-issue, as is the linear/non-linear distinction (which doesn’t change the colour primaries). But rec2020 has a much larger gamut…
Can be multiple reasons , but the fact is this goes for every kind of profile exchange.
Imagine you want to print to something that has a narrow gamut , but you have a monitor that is close to adobergb.
What you see is something quite different to what will happen when you want to export to print. There is no way to preview (softproof) what filmic will do with its gamut mapping when you export . What you see if way less gamut mapping applied compared to when you are exporting , with no way to control that.
The only way to do it properly would be to always export in your display profile , because that is exporting what you are seeing .
So if i want to export linear rec2020 , or someone wants to export to some other profile … It doesn’t matter. It still wrong you can’t control what will happen.
For me , I’d like to export a) in linear space b) in whatever the working profile is. To skip a conversion step , to further process it in next tools.
Anyway, when I export to rec2020 , and convert the result to sRGB , i get bright red with clipping.
If I’d see this in Darktable , i know i have to compress the gamut or try something with saturation.
But instead i see something purple without issue… Until i export.
Normally this is where softproofing comes in. If i softproof to linear rec2020 , you get that conversion in the preview pipe . It goes from working spaces , to simulated export space (still rec2020 in this case ) to display space .
The weirdest thing about it that the hue seems to shift , although i still have to check this with color pickers if that’s possible .
Just remember that the pickers use the histogram profile to provide the values so if you want rec2020 values or sRGB values you have to change the histogram profile… Its actually a great way to show why you get the dark image for rec2020 in a non color managed app… Look at the value is srgb then switch to rec2020 and see the numbers are smaller… so if this gets opened and mapped to sRGB by some app the resulting image is then much darker…
I can see how you’d think that, but you’re missing the point of color management. If each rendition medium is displaying an image that was transformed to the colorspace and tone curve of the profile for that medium, all the rendtions should look the same. In this case, what you’re seeing on the raw processor window on your display should look the same as a JPEG displayed on a properly color-managed viewer anywhere in the world.
The point of ICC color management is to have the best chance for consistent display of an image regarding color and tone, anywhere.
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.
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.
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.
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 ).
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…
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.
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:
Adding 'color calibration ’ (as a no-op) and then adjusting the gamut compression slider ?
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?
