Not sure about what you mean on the last paragraph.
You won’t be feeding log directly to the screen (that paragraph seems to imply it) unless you’re displaying HDR content.
For typical SDR content you have to use a specific transfer to cancel the display non-linearity.
EDIT: I wasn’t clear: I meant that you’re not going to display log encoded intensities because the screen’s DAC non-linearity will sort of cancel it. Log encoded is not what your eyes going to receive, your eyes want linear intensities akin to the original scene’s ratios.
If you send linear directly to the screen tha DAC will bend it with a 2.2 power and that will turn out too dark. That’s why “gamma correction” is needed in a display-referred image like a regular JPG. To “cancel” screen’s non-linearity (CRT’s non-linearity in the past and modern screen’s DACs, that mimic CRT non-linearity because it’s still convenient for low bitdepth delivery).
This is the color chart from @phweyland with my log profile centered in 50 % and gamma correction disabled by hacky means in darktable code, and no other correction. It seems that log looks good when you don’t reapply a gamma on top.
This is the same chart with no log but the default gamma correction in darktable :
Moving from linear mode (exposure output) to log mode (unbreak output) the colorchecker histogram changes as follow :
The points distribution is compressed to the right giving the expected dull aspect to the image. Middle grey values follow the same path and it seems completely normal to see the middle grey patch much lighter.
On the other hand, if you disable the gamma correction as you did just above, the output of unbreak appears normal (as you show) but the ouput of all other dt modules will appear darker turning dt unusable …
No. These are 2 different workflows. Gamma and log fulfiil the same needs in 2 different ways and shouldn’t be used in the same time. The fact that darktable applies the display gamma is wrong : it breaks the softproofing (technically, it works, but the values are wrong), it’s not consistent, it messes up the color picker and prevents you from seing the actual data.
Tonight, I have done a change in the output color profile module to allow users to choose between the gamma way and the linear way. I still need to fix some problems with LittleCMS, but the results are better.
I tried the saturation option and thought the results were visually pleasing, though there was quite a bit of clipping in the shadows of the particular image I picked as a sample image.
My sample image was a red apple, shot raw, no other processing in darktable beyond the bare minimum to interpolate the raw file, and specifically no “make it pretty” options such as the base curve or sharpening, and using the default dcraw camera input profile.
Would it be possible to add some sort of saturation mask to the algorithm to help reign in any otherwise resulting out of gamut/clipped channel values when using the saturation slider?
I think darktable allows adding a mask as a separate step, but I was thinking about something like a checkbox to apply or not apply an automatically generated saturation mask. There are ways to construct a pretty good sat mask using just RGB, but I don’t remember the procedure - an internet search would probably turn up the calculations.
If I understand properly, to see the output of unbreak I choose the ouput linear way, while to see the output of color balance (or any other classical dt module) I choose the gamma way. Is that correct ?
darktable has that already within the parametric blending options.
I think what you are looking for is the vibrance module, it does exactly that.
As a temporary hack, yes, but my fix to get the true readings has been merged in master today so you don’t need to do that anymore, as long as you don’t use LittleCMS, the readings will be right in both cases. That one with LCMS is harder to fix.
What does grading involve? I think by grading you mean applying a look to the scene-referred image/footage? Perhaps using a LUT?
And I think you are saying grading is done?/is best done? on log-encoded data rather than linearized data?
What does “display-ready transfers” mean? I think you are talking about taking the already-graded image/footage and applying a LUT to map the graded output to make it suitable for display on a preselected display device?
Hi @anon41087856, thanks for the link! Very informative. I think it would be very interesting to see how this translates into a darktable workflow using the new tools that you are developing. A little demo would be a great way of highlighting the advantages over a more “traditional” (“display referred”? “wrong”?, I don’t know how to call it actually approach.
For my part, I tried to work with the tools that I know, which is essentially just RawTherapee. Here’s my way of trying to emulate what is shown in the tutorial you posted (just to be clear: without any ambition of being comparable!):
do you know the proper way of doing that? I simply added the link, pixls did the rest… but if there’s a trick to make it work, let me know and I’ll edit the post.
It translates in darktable straightforward, the only difference is the 2.5 D color wheels of Resolve are 3 × 1 D sliders in darktable. I hade even embedded a default style to produte just that teal-orange look.
I’d still love to see it in action… do you have examples that show to the uneducated (that would be me) the benefits? I’m trying to understand. I know you posted some examples earlier (or maybe in a previous thread) but iirc there was no raw/source pic attached to try things out. thanks in advance!
@phweyland, are you using colord or xatom to fetch the system display profile ? I think I have spotted a bug with xatom that applies the gamma correction of the display twice on the same picture. Using colord, I still get wrong color picker values (but that’s expected, and I know why - bad but under control), but the image looks as it should. Can you reproduce ?
@agriggio sorry, no time for that at this point, feature freeze is coming, and big colorimetric errors need to be fixed asap. Critical stuff (at least for me).
no worries, I understand. fwiw, I just implemented a basic log compression in (my copy of) RT, so I can experiment while trying to understand what’s going on… I’ll report here when I have something if anyone is interested
Sorry, I don’t know and I cannot check for few days. Not sure that I can choose on Windows, but in any case I’ve kept the default value. I’ve tried to select the specific monitor profile but dt doesn’t retain it from one session to the other.
approach.
