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:
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.
That would be my experience so your mod doesn’t have that gamut intervention and that was the only thing that tweaked things for me otherwise things seemed color managed and it followed them being viewed in other software as well… if color managed … no issues unless created with v6 in the pipeline at any color pres mode… Obviously and n=1 image is not proper test…
No, filmic fixes colours, and by exporting to linear rec2020 i bypassed that fix .
Or actually, i leave the fix to be done by LCMS2 and proper colour profiles and after its in display space. Which causes different results .
1 Like
As far as the first post here goes, remember that filmic v6 is giving the correct, wanted output de the OP. While bypassing the gamut mapping in filmic v6 gives him a look he doesn’t want .
Simply said , the flowers do have a purple colour , and aren’t really red. At least , that’s what the OP said.
After some thinking…
I wish it would be possible to ‘declare my intended output profile’ to filmic v6.
Maybe by using the output-profile-module or something?
That way filmic could use that profile in making gamut-mapping decisions… but the output after filmic is just handled as normal in the pixelpipe/display pipe (which means, it gets converted to my display profile and gets displayed).
That way, if I plan to export to linear rec2020, I can set the output-profile-module to linear rec2020, and filmic will do very little gamut mapping, just as it will do when I’m finally exporting. But that way I do get a preview on screen of what will actually be in my file.
This also means that for people intending to export directly to sRGB, they can leave it set at that.
What happens now is that filmic is using a different profile to do its gamut mapping depending on if I’m displaying or if I’m exporting, and depending on export settings. And that seems a bit wrong to me.
Or maybe another workaround, but it seems filmic doesn’t do anything with the softproofing mode. If I set my soft-proofing to linear rec2020, I would export filmic to ‘map to linear rec2020, the output be converted to linear rec2020 (which it already is) and then it to be converted to my display profile’. But filmic still seems to use my display profile or sRGB do to its gamut mapping, even with soft proofing enabled.
For people trying to print directly from DT, this would be annoying, I’m guessing? Because you want to export in your printer profile, or at least export ‘wide enough’ and then get a preview of what your printer profile will do to the image. And like this, that is impossible, since no where will filmic use your printer profile for gamut mapping until you finally export a file to that profile.
I’m not sure I follow your interpretation from the results. So when you bring an image back in to a color managed viewer or DT that has been exported with filmic v6 to linear rec2020 why is this the only one that looks bad. If filmic is responsible for gamut mapping then the other situations should suffer maybe even worse no?? And yet using filmic v5 or sigmoid or v6 with the gamut check all seem to be able to render the image from display to export back to display and look correct??
I admit . I need coffee still today 
From the above I take it that he was not getting what he wanted exporting to smaller gamut so I suspect sRGB so he tried rec2020 and found no difference and that looked like the display render with filmic turned off… at least that is how I read it…