FastStone doesn’t color manage the thumbs only the full previews so you can see the raw…it gets rendered (not with the DT edit of course) and the edit exported with the 3 profiles that were mentioned… and it would appear that they are correctly color managed so I don’t think the export is broken??
The issue is that a linear-rec2020 from Darktable, then converted to sRGB in some other program, looks different to the sRGB-direct output from DT.
That basically takes my monitor settings and calibration stuff out of it, because it’s never in play then.
For exmple, if I export linear rec2020, convert to sRGB from the CLI, then throw it in Word (as you said, it’s not colour-amanged). Then throw the sRGB darktable export in Word… and they show differences, then something in how the export is written is different (if it looks OK or not is not even the question then).
I’ll have to check but I tried Gimp…looked fine to me… as for other program…you are using the DT srgb export profile which is and unbounded profile I think… or at least might be specific to DT and if you are using the OS and that srgb profile…there could be slight differences. Also the display profile is in a funny place in DT so maybe your calibrated profile is playing some small role…in any case we can wait to see if others have your issue and if it follows a pattern… I don’t seem to have that issue…
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?
1 Like
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.
1 Like
This was one comment from Glenn:
And this topic:
1 Like
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:
1 Like
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”…
1 Like
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…
1 Like
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…
1 Like
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:
