They an option to use LCMS2 in the preferences, have you tried that?
Also, as I said before, filmic tries to map colours to the output space. If that’s Rec2020, it’s understandable that darktable’s output, mapped to sRGB in an external software, won’t match the output where filmic performed its own processing.
Please give the filmic documentation in account: darktable 4.0 user manual - filmic rgb
When operating in the dark room, filmic maps the image to the gamut of your display profile. On export, it maps to the export profile. If you compare the exports in linear rec.2020 and sRGB to each other in some other image viewer, it’s more than likely that the rec.2020 one will be clipped such that the magenta skews to red. Filmic, when exporting to sRGB, reduces the colorfulness to fit the magenta in the destination gamut (sRGB) and preserves the chromaticity angle (which is related to ”color”).
@jorismak which program did you use to convert the rec.2020 render to sRGB? It’s more than likely that it just clips the individual channels and thus doesn’t preserve the chromaticity and will be different from the sRGB render from darktable.
I can’t say for sure about OP’s issue. It sound a bit like the display profile you use has smaller gamut footprint than sRGB and thus the view in darkroom will show the version that is mapped against the display profile. Could you do an experiment: change your display profile in darktable to sRGB (and restart dt just to be sure) and rerun the comparison of darkroom image to the exported one?
I was convinced it was a profile issue but perhaps filmic is involved… I have no issues with the tests I did but I had just done exposure and thrown sigmoid on it for simplicity…
I can confirm…it happens with v6 filmic for rec2020 but not with sigmoid or filmic v5 so it is likely the mapping as @kofa and others have mentioned… Just another reason I prefer version 5 
Ok, that’s actually a good explanation.
And that also means that exporting directly in a smaller gamut like rgb / adobergb / 709 actually has a good use in Darktable, because filmic actually takes it into account when exporting.
So actually a good case to use linear 709 (because there is no linear rgb one besides that one that i can see ).
The software I used is imagemagick with - i think - lcms2. I ‘assign’ the input profile from Elle’s v4 profiles (like rec2020-g10) and convert to Elle’s sRGB v4 srgbtrc.
I was just taken back by the difference in what i see in the program vs what is exported.
I believed doing as little as possible (like staying in the working profile and just doing the conversion to sRGB outside of DT) would be the ‘truest’, most pure way. But apparently I’m skipping an important step with it in filmic.
Am i summarizing sort of ok ? :).
I tried to investigate this during the summer, and the conclusion was that most of the software simply clips out of gamut colours:
Then I think it was @ggbutcher who pointed it out that v4 profiles with LUTs are needed the more advanced mapping modes, but the details escape me at the moment.
This was one comment from Glenn:
And this topic:
Thanks for all the links… I will have to go back and review everything…really I was only seeing the issue presented by @jorismak if v6 filmic was used… If i used sigmoid or v5 on the same image and even perhaps more saturated I got no issues with the image in DT or other colormanaged software… I did not try v6 set to no to see if it is a color preservation and or gamut mapping in filmic but the conversation might be a bit wider given all the discussions you have provided… I will revisit it…
Here’s what shaped my head on rendering intents:
I just tried this a number of times and i tweaked saturation to start all in gamut and just a bit out to a fair bit out… this time no filmic or sigmoid… so just the color profiles should be involved… All tests at perceptual… and I don’t see anything like the shift that happens when filmic v6 is enabled. It also happens with v6 if preservation is no or any of the others so from my limited position on this it seems like the color management will give an image that represents the display even when exported as linear rec2020 unless filmic V6 is involved…at least that is how it is working on this image on my setup in WIndows…
EDIT PS I do and have always had Little CMS enabled… I have not tested to see if that makes any difference…
Here’s the deal: Color transforms with the ICCs use the input and output profiles to describe the input data and the output data. The color matrix in a ICC file for, say, a camera, describes the transform that turns the camera data into XYX, and vice versa. So, it’s best to regard a color profile as the descriptor for a set of image data.
So, every ICC-style transform assumes the image is in the tone and colorspace described by the assigned profile, used as input. If darktable is doing it’s own gamut-mapping thing, then the assigned color profile no longer represents the image data. It may be some small transform that doesn’t significantly skew the data from the profile, but still, that’s what’ s happening.
Unless a dev with specific knowledge of how filmic accounts for (or doesn’t) the image gamut in its intermediary role between camera → working → rendition color spaces, it’s very hard to figure out why “things look different”…
I think it’s basically the code that @bnpndxtr removed from V6 in his hack that ends up creating what was presented here… I could be wrong
There was a nice presentation by @flannelhead on why this code was in v6 and I think his suggestion that a relaxed version might be the way to go is indeed worth pursuing. Brian got nice results but in totally removing the gamut check the consequences were presented here
So maybe relaxing it a bit might be a way to get as close to the best of both worlds…
As for the rendering intents I think taking an image of a colorchecker and placing lots of color pickers and then pushing it past gamut and exporting with the different intents should show what results can be obtained and if it is working or not…
Are we saying the filmic module is causing issues because it generates values outside of sRGB after profile conversion? If that is the case, would this not apply to other modules, too, if we were to push the values to the extreme? That leads to whether the module should handle gamut compression. Or should it happen at the end of the processing pipe?
PS - In general, each processing step should hand off data that is good for use by proceeding ones. Therefore, I am not implying that per-step adjustments are not necessary.
Filmic has gamut mapping built into it. So its. a little different than other modules.
I’ve not seen issues like this with the modified version of DT I’ve been using for a while now. It seems that I’d have seen it happen by now, if it was going to occur. I’ll try to be on guard for it.
I agree in thinking this is more likely profile mix/match related than gamut mapping related. In general I think it is key that the output profile and the display profile are set to sRGB. If you do that, then if you have a calibrated monitor what you see in your live editing session should be a sort of perpetual soft-proof mode, whether you have soft-proofing turned on or not. The output image will be forced into the sRGB space, and then any viewing SW that respects sRGB will do the correct “thing” with the RGB values so they look right.
Back to my opening comment, the nice benefit here is that even though I know what to look for in terms of possible negative effects from skipping the last RGB gamut map (aka the Salmon filter LOL), what I see on the display is already how it will look in sRGB. No surprises, and if I visually notice something going south (like colors starting to morph into pure RGB primaries to any extant I don’t like), I can address it and see the results and not worry that some other sRGB viewer will look different.
But picking something like rec2020 as an output profile would seem to turn over the gamut mapping for sRGB to whatever application is being used to view the rendered image, and it may not even understand rec2020. To be clear I’m not sure how that even works. But it would seem that if you render to sRGB, then you are safe for any wider gamut display, but maybe NOT visa versa, and perhaps that is the root of the issue being discussed on this thread.
Now the topic of ICC monitor profiles is kind of a different animal to complicate things. I’ve had no end of issues moving between machines, OS’s, graphics applications where the application for example is not a “managed display” application. So whether or not the ICC profile is actually correct for the monitor, or even being used when you think it is, makes a big difference. Gimp and XNView can use ICC managed displays, but you may have to intentionally change the settings to make it work. When it “doesn’t work” what I’ll see is that the image in DT looks different than the rendered output viewed by the external application that isn’t set up right for color managed displays. This is an irritation I have with all PDF viewers I’ve ever seen for Linux- none have display management support built in. So if I embed an image in a PDF, it won’t look exactly right in Linux no matter what I try. Some people might not notice, but everyone here probably would. If I open the exact same PDF in windows with acrobat it suddenly looks correct and matches the look I see in other viewers or in DT itself.
One of the key things I’ve learned is that monitor profile handling is on an application by application basis- it’s not a global feature of the OS that you can “set and forget” such that it automatically gets inherited by any application that runs.
Reading my comment and this reply I might have lead you to believe I thought your code change caused issues when I meant the reverse…
This comment made me think of something I stumbled on but never tried. I think my monitor is close enough to sRGB that I don’t really have any of these issues but tracking up to the OP comments and @jorismak 's example . I only see this on my system if v6 unmodified is involved. Otherwise my trips into WIn 11 photos (not photo viewer which is not CM), FastStone, GIMP all seem nicely color managed…
I think the OP was trying to in principle export a wide gamut linear file for further processing but I think that is less useful if you have used filmic and you would have to setup the data in pass through mode much like you do when you make a TIF of a colorchecker…
I did a quick experiment and didn’t see a difference between how the image looked in my modified DT while I was editing live vs the render. Here is a screenshot of the editing session and the render using the state shown in the DT screenshot. Ouptut color profile is sRGB. Now I should note that I was careful to not let any color morphing get out of hand while editing, and it did need to be watched with this image due to the reds that are pretty saturated to begin with.
editing session screenshot:
actual render:
Ahh OK. Yeah it seems that if you are trying to export a “wider gamut” render for further processing later in other apps, maybe filmic should be skipped, as it “bakes in” gamut mapping that might just become “color distortion” for the next app that does some kind of processing.
It kind of reminds me of the same principle as the pixel pipeline, but now the pipeline is multiple applications, not just DT. So whereas in DT the display space mapping happens at the very end (mostly) of the pipeline, if you now split the scene referred processing into multiple applications besides just DT, then perhaps you need to save the gamut size reduction step until some point in the final image editing/processing application.
What if you export to rec2020 tiff and then bring it back in… I think that was the issue that it was not coming back in color managed but srgb and linear rec 709 were…
EDIT…for me it did with sigmoid and v5 filmic but not when using v6…that is why I suggested that the mapping used in v6 altered somehow the flow between colorspaces but maybe it was just things were let to clip as some have suggested???
I’m not really sure how that should work. I tried exporting rec2020 tif, and didn’t see anything weird with how the image looked after importing. The input color profile after importing is “embedded ICC profile” which makes sense I guess. The working and output profile don’t seem to get affected by what image is loaded.
But once the image is loaded into DT, you are in the working profile immediately, and you are viewing the image through the “lens” of the selected display profile. whatever that profile is set to be. So I don’t think you ever really get to see the input profile “applied” to the image…whatever that might mean in the the context of viewing an image in DT. It kind of makes my head spin.
You may be on to something regarding V6 but I’d need to try some more trials.
