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…
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.
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??
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…
Thought about this a bit, now a bit less worried about it. Lifting pixels with a non-linear tone curve will desaturate colors, by definition. Restoring that color is desired in some cases, so including an associated operation to do that isn’t really such a bad thing. I’ve been doing something like this of late, putting a simple HSL saturation right after demosaic and feeding that result to my filmic curve, works like a treat. Yeah, using a “rat-piss yellow” operator, don’t care, so don’t call me on it…
What I do still have an issue with is any expectation that such an operation should replace the display/export transform. That transform is intended to accomodate the capabilities of the rendition medium, and if one is to continue using ICC display profiles for that it needs to be segregated from a “look” operation on the color earlier on. Further, if one is going to rely on embedded color profiles in their JPEGs for others to display their wares color-managed, the profile needs to describe the color and tone state of the image, and replacing that with some upstream operation vexes that expectation.
All this changes if you’re using an ACES workflow with something like OCIO, so look elsewhere for an expression of that angst…
Filmic v6 changes the way it works depending on the output profile ‘in play’.
So while previewing an image, the output profile ‘in play’ is my display profile. Or ‘sRGB’ in your case.
When exporting to linear rec2020, the linear rec2020 output profile is ‘in play’. Filmic changes its gamut mapping based on this profile ‘in play’, and thus changes it results.
I don’t know which is the correct or wrong one, or ‘more correct’ or ‘more wrong’ one…
But the image being displayed (even without any display profile in use!) is different to what is exported (even if that export is converted to sRGB through some other tool).
This means that yes, even in DT, if you do one export with filmic v6 to sRGB, and one export to linear rec2020, and you then load them both back into DT, they are different.
It’s a similar result to disabling the gamut-checking step in that test-patch @bnpndxtr did.
And I guess some people will like result #1, and others result #2, and it depends on the image… my main issue is that the export doesn’t match what is displayed in the app.
(PS, why I think the sRGB-output is ‘more correct’, is because if I use ‘color calibration’ to just apply a lot of gamut compression, the colours are more in line with what filmic v6 outputs in sRGB mode… while the linear rec2020 output looks more like the image without any filmic applied to it at all… unless you start compressing the gamut to >= 8.0 :). Again, I’m not sure which is really correct, but from the description of the OP the filmic v6 sRGB output (so with gamut mapping working) is more like the reality).
This is the basis of my angst. Filmic gamut mapping is done for one reason, and display/export gamut mapping is done for a separate reason. Darktable seems to want to combine the two…
When you edit, you should be looking at a rendition that corresponds to the color and tone capabilities of the display, converted to the display’s gamut. If that color is unsatisfactory, then one should be doing an upstream edit that does it’s thing and feeds the display transform, so what you look at is the cumulative effect Of Two Separate Operations, Done For Two Separate Reasons…
HA HA …its all just too much gamut mapping… and other factors I guess. I don’t use color calibration for wb. I would I guess if I wanted to mask or had weird lighting and I have been using v5 filmic as I prefer the way it works and how I can control it …. In the end not breaking it down to the technical angle it seems like for me in all cases and at least with this image. As long as I don’t use filmic v6 an image exported as linear rec2020 (again not something that I do) is matching the display preview in DT and all of my Win applications that are color managed and then if I use v6 it doesn’t match… so functionally in this situation its not working , technically it might be 100% correct… In any case time to put it to bed on my end as I have no current use case impacted by this….
Surely this is desirable and appropriate? Indeed the reason filmic exists?
The ideal situation is having a display for editing that is wider gamut than any output medium. By necessity you’re editing in the dark when outputting for a wider gamut than your display. In that use case you have to trust the software. The intent behind filmic was that that your edits could survive ouput to very different media. It obviously can’t look the same on paper and on a hdr display but the intent (however optimistic) was that you could wouldn’t change the edit and it would magically be adjusted. At least early discussion went along these lines.
My view is that in practice you will have to do different edits for different media but perhaps I’m pessimistic.
So I tried using std DT, and I can see now that filmic v6, the colors are shifted strongly to magenta. The weird thing though is that usually if this kind of thing happens to due to filmic squashing the colors, you can back off on the exposure and see the colors transition back to normal looking. However with this image it doens’t work. You can turn down the exposure quite a bit, but things always have that weird magenta look. v5 looks much more normal. And if I look at the embedded jpg in the raw file, it looks more like what you get using filmic v5 or my modified v6 without the RGB gmaut mapping step.
If I export to a tif file using sRGB and then again using linear rec 2020, there is slight difference in how they look when opened in a viewer, but I’d expect that. So the one outputted with linear rec 2020 is kind of “unbounded” on my sRGB-ish laptop so it kind of just becomes a little more saturated and then hits the ceiling of what can be reproduced. The image exported using sRGB just looks normal no matter how I view it. Opening them both in std DT, the differences I see are similar to what I see in a viewer.
So after all of these trials for me the really the weird thing I’m seeing is what filmic v6 does while I’m in the editing session:
The chromaticity of the foreground flowers is a deep, saturated magenta. So saturated that it isn’t representable in sRGB (or a display profile close to sRGB). So what you see in the editing session is that filmic v6 reduces the saturation in order to not skew the color, bringing it right to the edge of the gamut footprint. In the embedded jpg the color is skewed to red - this is most probably the result of clipping destination (sRGB) components individually to zero when they would have had negative values.
@bkv also said in the initial that the deep magenta displayed in the darkroom looks correct, and the problem was in the exported output file.
Also, be wary of posting and comparing screenshots from the darkroom. For comparing things, this is probably inaccurate, since the image is color managed for each persons own display. I think screenshots won’t account for that. At least @bnpndxtr’s screenshot doesn’t contain an embedded profile and is thus interpreted as sRGB which is wrong because the darkroom image was rendered for their display profile.
@bkv: do you have the display ICC profile available that you use for the laptop display? It would be very helpful in diagnosing the original issue you reported.
Its all good when it works I guess. When something looks weird it seems like you have to understand the code a bit better… There is a choice to clip gamut in the input profile , in color calibration if you use that. I think maybe color balance might also do some… for sure it has the two color space options under masking at least that would impact gamut and then filmic if you use it and then the output profile… The standard gamut warning seems to use what is set for the softproofing profile and the overexposure which can be set to a range of options including full gamut seems to use the histogram profile so with all these possible settings modules, profiles and indictors it is really clear to convey how things are set for sure when trying to sort out any issues like this…
I get uncertain when gamut mapping comes up, as here, so I’m referring to the manual. It has this in the Filmic section -
If colors are left unmanaged and are allowed to escape gamut, they will be clipped to valid values at the time of conversion to display color space. The problem is that this clipping is generally not hue-preserving and definitely not luminance-preserving, so highlights will typically shift to yellow and appear darker than they should, when evaluated against their neighborhood.
To overcome this, filmic has used various strategies over the years (the so-called color sciences) to desaturate extreme luminances, forcing a zero saturation at minimum and maximum lightness and a smooth desaturation gradient. These strategies were all intended to minimize the hue shifts that come with gamut clipping.
Since all of these strategies were approximations (and often over-conservative ones) v6 (2022) introduces a more accurate and measured approach. It performs a test-conversion to display color space, checks if the resulting color fits within the [0;100]% range, and if it doesn’t, computes the maximum saturation available in gamut at this luminance and hue, finally clipping the color to this value. This ensures a minimal color distortion, allowing for more saturated colors and better use of the available gamut, but also enforces a constant hue throughout the whole tone mapping and gamut mapping operation.
A key bit is “computes the maximum saturation available in gamut at this luminance and hue, finally clipping the color to this value.”
So the very basic thing I’m confused about is on the one hand the above implies Filmic V6 output should all be in gamut with respect to the display/output profile, whereas we know in practice it’s very easy to have OOG areas.
Can someone explain pls?
Does the manual need tweaking?
Am I completely misunderstanding something?
For the matrix profiles, it’s not a clip. For the relative_colorimetric intent, It’s a translation along the “hue line” (my term) drawn between the out-of-gamut color’s coordinates to the white point, to a place just inside the destination gamut. There’s no gradation inserted, so the out-of-gamut colors of the the same hue just pile up in the same place. Not a clip. Manual needs a tweak…
IMHO what filmic color tools should do is to allow adjustment of the chrominance of highlights that are pushed to desaturation with the tone curve. That objective, serves a different purpose than the gamut transform to the rendition spaces.
Thinking about it, the ACES workflow would have similar constraints. They have defined Output Device Transforms (ODTs) that serve various rendition destinations, and any intermediate chrominance manipulation should respect the same considerations I described for the ICC workflow.
Well rats, I completely flipped around the description of the original problem. I had been under the impression that the magenta cast was incorrect, not correct. That’s what I get for rushing in and speed reading the posts.
But wow then, those roses must be way, way out of gamut! If I use filmic v5 or the v6 version without the final RGB gamut mapping, the foreground roses are red again. Assuming this is due to migration towards red primaries due to gamut clipping with deeply saturated high luminance colors, if I progressively reduce the exposure and watch the colors carefully, they never change to magenta-looking but just stay the same “red”. They just appear to get darker. So…does this mean that these foreground flowers are out of gamut at any luminance? In the past when I suspected this was happening at high luminances, I’m pretty sure I could reduce the exposure and see the colors become corrected (i.e. move away from pure primaries, if that was in fact happening at the higher luminance). But perhaps this is an example where there literally is no luminance value where the true hue comes into the gamut of sRGB or the display profile.
