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?
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. 
No not at all, interesting, and I know what a binary search is!
I didn’t mean to imply you didn’t. I meant to say I’m the one out of his league.
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.
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…
This is a good tool to check your output if you are trying to do it…
