Can you explain a little more what you did… I recall there was a user that modified the filmic code to remove the gamut check some time ago… at least in v6… Your modification sounds different…
I think this little adjustment is informative… so again I don’t have the d3400 but I downloaded the 100 iso test shot from imaging resources… I open my images with traditional wb and no tonemapper to start with always just to introduce as little as possible… so here is that test shot
Red looks quite magenta to me on my screen… you can also see the histogram shift… lots of blue gets removed… and the dots show what the colors should look like when corrected…
Now after just running the correction in CC using the max delta E… none neutral and average were similar by the way…
you get this
Looking more correctly red… so I it might be worth checking on this for your images…
1 Like
Your images with this CC preset opened with classic as shot wb and exposure bump 0.7 not filmic or other… note blue channel
After
I’ll check the others later…have to run off…
2 Likes
Oh my god thank you, I wasnt aware of this ressource. I believe thats it. It does help a lot and I have the peace of mind that I didnt have to judge the color accuracy myself while pushing sliders! Plus you saved me 50 bucks for my own color checker.
Thanks a lot for your help everyone!
3 Likes
Of all the useless stuff I have acquired in more than thirty years of photography the colorchecker is not on that list. I have had access to all kinds of color charts over the years, but having the colorchecker passport in my bag with me helped on so many occasions. I am even considering getting the new DUO version with the large grey bars to have patches that work well with the waveform display in darktable. Just my 2cts.
3 Likes
For sure having your own card so that you can run this exercise in the light of your shots would be even better of course… It’s an amazing little routine to add a set of channel mixer adjustments to fine tune color…In fact it also recommends an exposure setting for accuracy…
1 Like
Yeah. The effect I use it for is very similar, but I think there is still a big flaw / miss in that filmic doesn’t do anything with soft proofing. Which basically means that ‘something will happen on export, and you cannot preview it’ and that’s not OK in my book.
Filmic requests the ‘output profile’ to do its gamut checking. During export this is the profile used for export, during regular Darktable, work this is the display profile.
So, filmic will always do gamut mapping to the display profile while editing.
My problem with this: Imagine you have a wide-gamut display, and you want to export to sRGB. You will not see the gamut mapping that will be there once you export to sRGB.
Or, you want to print to something with a smaller gamut than your regular monitor. Same thing.
When you export to a smaller gamut than you are previewing, you can not preview the filmic gamut mapping that will occur on export.
In this case, it’s kinda of the other way around. We see the gamut mapping happening, but we don’t like the effect and would like it to go away. This time.
So, what I did was nothing but a few lines at the start of the filmic process() (and OpenCL variant) functions, where the output profile is received from the pipeline.
I do a little check there, ‘if soft proofing is enabled, use the profile selected for soft proofing’. Done.
That means that you can now enable soft proofing, select ‘linear rec2020’ as the soft proof profile, and you will get no gamut mapping. Filmic is mapping from linear rec2020 to linear rec2020 (from working profile to soft proof profile). If I like it better this way, I set the output profile for that image to (linear) rec2020 and convert it afterwards. If I don’t like it, I leave things as is.
I don’t know the Darktable code base well, so
- I expect to do things horribly wrong
- This to be the complete wrong way to do this
- It will probably leak memory somewhere somewho
- All other kinds of disclaimers
… but I run it on my builds :).
diff --git a/src/iop/filmicrgb.c b/src/iop/filmicrgb.c
index 3e0835477c..51669d4e15 100644
--- a/src/iop/filmicrgb.c
+++ b/src/iop/filmicrgb.c
@@ -2144,7 +2144,19 @@ 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 = NULL;
+
+ if (darktable.color_profiles->mode == DT_PROFILE_SOFTPROOF) {
+ export_profile = dt_ioppr_get_profile_info_from_list(
+ self->dev,
+ darktable.color_profiles->softproof_type,
+ darktable.color_profiles->softproof_filename
+ );
+ }
+
+ if (export_profile == NULL) {
+ export_profile = dt_ioppr_get_pipe_output_profile_info(piece->pipe);
+ }
/** The log2(x) -> -INF when x -> 0
* thus very low values (noise) will get even lower, resulting in noise negative amplification,
@@ -2435,9 +2447,21 @@ int process_cl(struct dt_iop_module_t *self,
// fetch working color profile
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 = NULL;
const int use_work_profile = (work_profile == NULL) ? 0 : 1;
+ if (darktable.color_profiles->mode == DT_PROFILE_SOFTPROOF) {
+ export_profile = dt_ioppr_get_profile_info_from_list(
+ self->dev,
+ darktable.color_profiles->softproof_type,
+ darktable.color_profiles->softproof_filename
+ );
+ }
+
+ if (export_profile == NULL) {
+ export_profile = dt_ioppr_get_pipe_output_profile_info(piece->pipe);
+ }
+
// See colorbalancergb.c for details
dt_colormatrix_t input_matrix_trans; // pipeline RGB -> LMS 2006
dt_colormatrix_t output_matrix; // LMS 2006 -> pipeline RGB
(Issue at control profile used for filmic gamut mapping · Issue #14652 · darktable-org/darktable · GitHub btw)
As far as the original poster of this thread and the original problem: Export your image to (linear) rec2020, open it in a color-managed image viewer (heck, open it back into Darktable, just make sure no modules are then enabled on it) and see if that improves things.
If it does not, your problem is not in the gamut mapping, and probably looking at calibration / input-profiles / doing hue-changes yourself in Darktable is the way to approach this.
If it does fix your issue, I go back to my original answer: Use filmic-v5 with the preserve mode set to ‘no’, use sigmoid, or just be happy with the rec2020 exported file, and convert that to sRGB or whatever you wish.
3 Likes
And what do you use to do that? Does that tool simply clip out-of-gamut colours, or manage it somehow?
Yes, I use ‘good’ v4 ICC profiles, but most likely it still clips. So you lose ‘detail’ in the colour gradients. But often I like that better than turning the red to magenta. Choosing between two evils.
I don’t like to completely disable the gamut mapping, since often it’s doing good things. I had a time when I always exported to linear rec2020, but I got some nasty surprises the other way around. Since it suddenly wasn’t doing any gamut mapping that I was seeing on my editing screen, the output was different to what I liked. A sky with a bit of orange glow in it being suddenly way more orangey / saturated is what I remember.
For me, I can now quickly use the soft proofing toggle to see if there is a noticeable change, and if I want to act on it.
Quickly masking the problem bits and doing a subtle hue change away from magenta towards more red can work just as good, of course. And then you might preserve some colour details there. You can also use the gamut compression in the ‘color calibration’ module, but by the time the magenta is gone you are probably loosing a lot of the saturated-red-look you expected. Depends on the person editing, of course.
@flannelhead once said somewhere that the gamut mapping isn’t perfect (of course), and that bright red is one of the problem areas. Maybe there will be some improvement here, but before that time I bypass it sometimes like this.
It the case of this camera’s default profile I think the default matrix might just be off here. So for sure sometimes we are looking at filmic and or color calibration doing some of this but I think by default gamut compression is turned off in DT’s input profile and so opening these images with just as shot WB and no filmic or CC still has them way towards magenta… Then using the color checker it corrects nicely back to red so here I don’t think the usual sort of filmic or other color corrections are the source of it… I wonder can it be as I have read that DT for many camera’s uses the default adobe coefficients. These are said to often yield very weak red from what I have seen reported and when using the DCP files in RT the base and look tables greatly alter the colors in the image. If that is the case then is DT essentially starting with the weak red as there will be no look table or other HueSat adjustments that would be part of the DCP file… In that case the correction available in DT using a colorchecker could be very important to improve the color offered by the default input profile for some camera’s…
1 Like
Minimal processing in darktable, exported as Rec2020, gamut compressed with a toy I had written.
DSC_0153.NEF.xmp (13.0 KB)
Heading home for the day so interested to see how this looks at home on my calibrated monitor. On my work PC its still a pinkish red but then my color vision is not 100% either…
I simply picked the white balance (in colour calibration) from the white number, so I have no idea if the starting colour was correct. The gamut compression maintains LCh lightness and compresses C, so it desaturates colours. Thus, a red to pink shift is rather probable.
I think this camera needs a correction out of the gate for the reds… so wb on neutral just doesn’t seem to fix it
I’ve tried with @ggbutcher 's D3500 SSF profile (according to DPR, the D3500 is the same as the D3400, in a revised body). I’ve also disabled gamut compression in color calibration. I moved exposure above input color profile to avoid clipping. I think the result did not change much.
I see more difference due to how the resizing was done (initially, in Gimp; for this version, in darktable’s export module) than due to the profile.
Left: standard matrix; right: Glenn’s profile.
I’ll be away from my desktop until late August. Have fun, folks! I may chime in from the mobile.
1 Like
To me this one shows the real issue and it might be the correct vs perceptual vs how the hell you or I have my screen set… but if I don’t use the CC correction the shell logo on the door looks washed out and the car still looks less red than I would image it to be…but again such a massive subjective thing… Below is what I get and I find it more as to what I would think it might look like… This is simply WB set to reference and the CC module as determined from that test image of a D3400 color checker test shot that I used following the method shown by AP. No filmic or any other module but the standards for scene referred to start with…
Adding my preferred filmic v 5 gives this
V7 instead of v5 filmic pull out a little red but actually hangs in there…
DSC_0153.NEF.xmp (6.1 KB)
Adding a CB preset on top you can really make it jump nicely with yellows and reds…
Last one crank the vibrance with that CB preset and exclude the grass… the car is now going so… much faster… 
EDIT I guess to complete the group taking the last one as described and switching back to filmic v5
2 Likes
To the best of my understanding, yes, you could do a snap under sunlight, and that would be fine for most stuff except some artificial lighting.
I’d say no - my D7100 has similar tendencies. It’s just a case of different profiles I think. I wonder if the D3400 may have a similar sensor to my D7100? 24mp I think in both cases. I’m away from home at present, but in a few days I could share a shot of my ColorChecker from the D7100. Might be interesting to try using as a calibration shot for your camera.
If I’m ever in Austria I’ll remember that! Let me know if you drop in to south est NSW Australia - I can tell about the best rally events 
2 Likes
In all my messing around in addition to using the CC/channel mixer correction I tried RGB curves and tweaked the red to the Ferrari red of 255 40 0 and I also found that actually a simple 5% hue rotation to shift from magenta to red gave that nice ferrari red as well… I am not sure how universal that might be for images on that sensor/DT starting profile combination…maybe only for images with the reds yellow oranges… maybe only a fluke on this one but it might be interesting to go back and try that on a few of your images if they tend to magenta… I feel like you were exploring colors on some rally cars a while back and you had a post with a red and or orange car… at that time I think a lot of the tweaking and massaging discussion was around filmic… but maybe a simple hue adjustment out of the gate might help…anyway its just a musing
3 Likes
Thanks for giving that a shot for me even though it made no difference. Strange that these two cameras dont act similar then, you would think them to be pretty much identical.
that aligns pretty much with how I remember the color being
I gotta say rally is definitely the most photogenic of motorsports, loved the pictures on your website!
It does help, tho at that point again id have to rely on my eyes to judge whether or not the other colors are off and i dont trust them lol.
2 Likes