I know exactly what you mentioned. No, not grey, black but washed out. Difficult to describe, but very ugly.
I don’t want to bash filmic, sometimes again it is better then sigmoid. But it is great to have an alternate module. I have photos of squirrels, no chance to get correct colors, despite of intensive studying / trying color calibration module. It’s great, but “the reds needs more cyan”. Weird. One can get crazy trying adjusting colors.
After editing about 1 month completely without filmic/sigmoid (just using the tone eq for the final tone curve), I came to the conclusion: more than 95% of my edits I can reproduce quite similar either in filmic or in sigmoid or even without both.
It’s more of a “which tool suits your workflow / editing style best”.
And one more thing… the real workhorse isn’t the final tone curve, but the dynamic compression earlier in the pipeline. Usually another tone eq instance in some preservation mode (eigf/gf) and with appropriate mask. This instance prepares the tonal range, so that the final curve (be it filmic or sigmoid) “only” has to stretch the proper contrasts in the dynamic range.
So, If you are unhappy with the shadows (or the highlights, or the contrasts in some area), your problem probably lies somewhere earlier in the pipeline. Not in the final curve.
Just my two cents.
4 Likes
Is this really correct? My understanding (and experience) has been that both sigmoid and filmic has a tone mapping and a tone curve function. Tone eq and exposure will shift tones and help move detail around within the output but the tone mappers are still working away maintaining the overall tones within output. Skipping the filmic/sigmoid step makes for a lot more manual work.
Sigmoid and the new highlight handling has made dt really very good. I’m primarily a RT user but have edited a few sets with dt again. The thing, that filmic never achieved due to colour shifting, is that suddenly exposure is a magical tool. You can shift exposure around massively and the result will remain good even when you “should” have shifted stuff into oblivion. Things will get compressed at either end but sigmoid does this in a way that is usually photographically “natural”.
4 Likes
Remember: it is the person behind the post-processing. Tools are only tools, not your savior or significant other.
2 Likes
I use filmic to try and spread my tones over the entire output range, that’s it. If I don’t like some particular part I use exposure or Tone Equalizer until I do.
3 Likes
Don’t get too silly based on the look of those wooden posts… the extra contrast by default in sigmoid needs to be accounted for and for sure default filmic should not just be filmic activated but filmic with the auto white and black at least given this is the intended look of the curve… otherwise set sigmoid at contrast of 1 and see how that looks… I think for me the gamut mapping in v6 causes issues at times otherwise I reckon very easily I can get exactly the same look from sigmoid and v5 filmic with chroma pres set to no…
Or skip them both 
2 Likes
For me, it really depends on the picture. Most of the times, I want my highlights to desaturate smoothly and naturally, which is what sigmoid’s per-channel mode does well. But some of the time I want those highlights to retain color, often with colored artificial light in the scene, which is where the rgb-ratio color preservation shines.
As for the tone curve, I frankly don’t see a massive difference between filmic and sigmoid. It’s only a starting point for me anyway, typically augmented by the tone equalizer and rgb tone curve.
1 Like
That is at least my experience. I would concur to what Mica said.
And to this point:
This is not the case (edit: at least for a lot of images - there are of course also images which are pretty hard to do without… for example this, here I used sigmoid Backlit, hardcore flaring, vintage lens fun. - #33 by qmpel ). In many images, the final sigmoid/filmic curve can be replaced by a tone eq with preserve=no and a simple contrast function (a sinus wave). If you have a photo with high dynamic range, it is more fiddly, to get a pleasant curve - but I still wouldn’t call it a lot more work.
If you want proof, look at my history. (edit: Nearly) all play raws in the last month or so are not using filmic/sigmoid. Now you might say, my edits look shitty … then the case is clear also 
.
1 Like
Why should this not work? IIRC, Aurelien’s thesis about this topic was, that each modern camera sensor is capable of delivering HDR data, or more precisely, the dynamic range of the image can be larger than the one of the output medium. However, not every scene is a HDR scene, and even if, in many cases, burned-out highlights and/or black shadows are perfectly acceptable for an image. For the other cases, sure, there are alternatives to using filmic or sigmoid, e.g. base curve, RGB curves, or tone eq.
IMHO, filmic and sigmoid modules are helpful to have (1) some default rendition that is closer to the final expectation than the pure demosaiced linear data, (2) a tailored handling of HDR data, (3) tailored controls to fine-tune the output transform, and (4) to ease adaption to different output formats (different dynamic ranges), at best with no need to change settings. So why should we no use these in our workflow, as long as we can get the desired results?
3 Likes
Yes, the waveform does provide stellar information. Only one small peeve: the top of the diagram is hard to see since the background merges nicely into the desktop …
I’v hacked with with css and altering the histogram.c file in the source to allow it to be nice and bright… by default it is painted to the screen to dull it down a bit… I bumped it up to 0.95
// The alpha of each histogram channel is 1, hence the primaries and
// overlaid secondaries and neutral colors should be about the same
// brightness. The combined group is then drawn with an alpha, which
// dims things down.
cairo_save(cr);
cairo_push_group_with_content(cr, CAIRO_CONTENT_COLOR);
cairo_translate(cr, 0, height);
cairo_scale(cr, width / 255.0, -(height - 10) / hist_max);
cairo_set_operator(cr, CAIRO_OPERATOR_ADD);
cairo_set_line_width(cr, DT_PIXEL_APPLY_DPI(1.));
for(int k = 0; k < 3; k++)
if(mask[k])
{
// FIXME: this is the last place in dt these are used – if can eliminate, then can directly set button colors in CSS and simplify things
set_color(cr, darktable.bauhaus->graph_colors[k]);
dt_draw_histogram_8(cr, d->histogram, 4, k, d->histogram_scale == DT_LIB_HISTOGRAM_SCALE_LINEAR);
}
cairo_pop_group_to_source(cr);
cairo_set_operator(cr, CAIRO_OPERATOR_ADD);
cairo_paint_with_alpha(cr, 0.95);
cairo_restore(cr);
Excuse my ignorance …is there a fix at this time … do you have a revised css?
Sorry I assumed high DR images or plenty exposure pushing because with low DR the tone mapping should basically be a no op with any visible difference coming from the tone curve part of sigmoid/filmic so basically just a base curve?
No I just set the background to as close to black as I can and set the channel colors to be brighter…this you can do with css… the alpha to brighten the whole thing has to be changed and then compiled… you can find the lines that control the various things related to the histogram in darktable.css
Hi!
I just want to share some observations, I think it would be a good idea restoring the luminance after the rgb tonemapping.
The issue is that rgb per channel tonemapping becomes a little destructive when the saturation increase.
An example:
This is an image tonemapped with rgb tonemmaping
If we desaturate the already tonemapped image we obtain this
If we desaturate the original hdr image and we do the tonemapping after, we could get a more detailed image
Now the idea is to remove the luminance from the rgb tonemapped image and add the luminance tonemapped image
(Note that this particular image has issues with out of gamut colors)
A simple way in pseudo code to obtain this without actually decomposing the image is :
i=Original_image
Lum= get luminance from i
tm_lum=tonemapping lum
tm=tonemapping i (with or without hue preservation)
Lum2= get luminance from tm
tm_luminance_restored=tm/lum2*tm_lum
1 Like
Interesting idea, some questions.
Has anyone else done this that you can link to?
Is the bottom image processed exactly as described?
What to do with colors that get pushed out of display gamut?
We will have the same problem as rgb ratio with no gamut mapping even though there will be a desaturation of bright pixels. Have a feeling that f ex skies will look desaturated even after this operation.
I don’t think
Yep
Good question, ideally I think that extreme saturation should be fixed before tonemapping with something like a proper dual illuminant profile
1 Like
Let the display transform deal with them.
After more testing with very OOG flowers this could produce little color banding artifacts, I see this problem only with flowers photography.
Using CIE lab or the simple ycbcr color spaces solves the problem.