control profile used for filmic gamut mapping

[jorismak]

I have posted about this before in other issues and on pixls, but it's a known problem on one hand, on the other hand not :).

The problem I'm having is that the flow:

• export image from Darktable in (linear) rec2020 tif file
• open tif file in image tool of your choice with colour space conversion
• convert to sRGB (relative or perceptual...)

looks different to what Darktable exports directly to sRGB.

This is caused by the gamut mapping in filmic v6/v7 (as it only happens in bright red parts, or the orange of skies, etc..).
It also is not present when not using filmic, or when using filmicv5.

Now, in some images I like what Darktable shows on my screen (so the Darktable directly to sRGB flow).
But in other cases, I want the result that Darktable gives me when exporting to rec2020 and then converting to sRGB in an external tool.

So, my problem is, there is no way to control the gamut mapping in filmic v6/v7. It seems to always use sRGB, even when softproofing is enabled with rec2020, or even when rec2020 is selected in the output profile ('output color profile') module.

A toggle or a slider to disable the gamut mapping (to judge the effect) could also be an option.

It seems filmic v6 Always uses the display-profile for gamut mapping when previewing, and uses the output profile when exporting. And so, what filmic does with the gamut mapping cannot be previewed.

And since the gamut mapping can produce unwanted effects (like turning bright saturated red just slightly more to magenta) it's hard to edit.

Sometimes when the bright reds don't seem to do what I want, I just try to export to rec2020 by trial and error and see if that improves things. But this is of course not a real nice working solution.

For printing the same problem is present, but in a sort of reverse matter. What if I have a printer without a large colour gamut. When exporting to a profile for this printer, filmic v6/v7 will try it's best to map the image data to the gamut of the printer profile. Which is nice!
But there is no way to preview this, because filmic will always use the display profile for it's mapping (instead of the selected softproofing profile for instance).

Describe the solution you'd like
Let filmic v6/v7 use the profile selected in softproofing when it's enabled, while previewing (instead of picking display profile). That way I can preview what a rec2020 export would look like when then converted to my display profile, but for people using printer-profiles without a very large gamut, it also makes it a proper preview for what filmic will be doing when exporting to a selected printer profile.

Alternatives
I would be happy with a toggle to disable gamut mapping (or reduce its effects) in filmic v6/v7. But that's for my use case where the gamut mapping is causing issues. For people with the narrow-gamut printing situation (a lot at home, I'm guessing) this will not solve the issue of not being able to preview what the print would end up doing during export.

There was talk at some point about putting the gamut mapping in its own module, but I don't know if that's a proper solution (would still require the change outlined here about using the softproof profile, or offer UI choices to select the profile in play).

Of course, you could also try to 'fix' the issues with the gamut mapping algorithm, but I think that sounds like a fairy tale :). Gamut mapping is inherently 'trying to put something large in something small, which means something has to give'. And a way to preview the 'something has to give' sounds like a logical thing to have in my mind.

[jorismak]

I'm probably doing a lot incorrect (don't know the Darktable code base at all),

but this at least seems to work and give me the effect I want :).

darktable/src/iop/filmicrgb.c

Line 2147 in 68782dd

const dt_iop_order_iccprofile_info_t *const export_profile = dt_ioppr_get_pipe_output_profile_info(piece->pipe);

    const dt_iop_order_iccprofile_info_t *export_profile = dt_ioppr_get_pipe_output_profile_info(piece->pipe);

    if (darktable.color_profiles->mode == DT_PROFILE_SOFTPROOF) {
        export_profile = dt_ioppr_add_profile_info_to_list(darktable.develop, darktable.color_profiles->softproof_type, darktable.color_profiles->softproof_filename, darktable.color_profiles->softproof_intent);
    }

diff --git a/src/iop/filmicrgb.c b/src/iop/filmicrgb.c
index 3e0835477c..201e24b36f 100644
--- a/src/iop/filmicrgb.c
+++ b/src/iop/filmicrgb.c
@@ -2144,7 +2144,11 @@ void process(dt_iop_module_t *self,

   const dt_iop_filmicrgb_data_t *const data = (dt_iop_filmicrgb_data_t *)piece->data;
   const dt_iop_order_iccprofile_info_t *const work_profile = dt_ioppr_get_pipe_work_profile_info(piece->pipe);
-  const dt_iop_order_iccprofile_info_t *const export_profile = dt_ioppr_get_pipe_output_profile_info(piece->pipe);
+  const dt_iop_order_iccprofile_info_t *export_profile = dt_ioppr_get_pipe_output_profile_info(piece->pipe);
+
+  if (darktable.color_profiles->mode == DT_PROFILE_SOFTPROOF) {
+    export_profile = dt_ioppr_add_profile_info_to_list(darktable.develop, darktable.color_profiles->softproof_type, darktable.color_profiles->softproof_filename, darktable.color_profiles->softproof_intent);
+  }

   /** The log2(x) -> -INF when x -> 0
    * thus very low values (noise) will get even lower, resulting in noise negative amplification,

Like I said, this is probably very wrong, or leaks, or uses the wrong references, etc...

But I find it weird that a pixelpipe seems to have a regular output profile set, when softproofing is enabled.
So any module that wants to know 'what is the final output profile' during softproofing, will not get the softproof profile but the regular colorout profile. Doesn't seem right, does it?

And I have no clue how to do the same in OpenCL :(.

[SoupyGit]

Another possible alternative, instead of always gamut mapping to srgb, can filmic always map to the profile selected in output profile?

[jorismak]

Another possible alternative, instead of always gamut mapping to srgb, can filmic always map to the profile selected in output profile?

Well, it already is, except for the regular display/preview. During preview it ss using your 'monitor' profile, and during export it seems to use the profile for export / output.

Another very simple case I thought of.
What if I have a 100% Adobe RGB monitor, but I want to export sRGB for the web. How can I preview filmics gamut mapping during working on the image ? You can't right now.
It will always use your monitor as a target, but only during export will it use sRGB as a target (and the reds-skew-to-magenta appears).

[Christian-Bouhon]

I would be happy with a toggle to disable gamut mapping

This is an excellent idea, personally I don't use filmic V6/7 any more because of the gamut mapping.
This solution has already been used for highlights.
Greetings from Brussels,
Christian

[jorismak]

I would be happy with a toggle to disable gamut mapping

Well, I would be happy but it's not a proper solution to the problem. The problem is that an effect is applied which you cannot preview before exporting, so it's a gamble on how it will turn out.
That gamble needs to be removed from it. And the proper way, is to use the softproofing tools that are already in Darktable.

The use case where you are working on a higher gamut display than you are exporting (something that has good AdobeRGB coverage, and you are exporting sRGB for the web, for instance. It is a very realistic use case) there you want gamut mapping to apply. But you do want to preview how it looks before exporting and don't get any nasty surprises.

(DxO Photolab switched around a while back from something that is 'display referred' and a narrow AdobeRGB working space, to something that is a wider gamut working space like rec2020 / prophoto... and they also have gamut mapping, and people also don't understand it and there are a lot of questions about it :). But it's controllable by a slider, and they added softproofing so you can preview what your export will look like. Their gamut mapping is simpler (lowering chromacity it seems) but they run into a lot of the same issues :)).

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[jorismak]

bump to unmark as stale, still waiting on response

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[jorismak]

bump to unmark as stale, still waiting on response

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[jorismak]

bump to unmark as stale, still waiting on response