While I really like the idea behind filmic module, still it's not always easy to get the colors I want with it. I guess, depending on the camera, base curve might give better colors by default, but will make much trouble in other departments. Obvious point that it's not that easy as just using filmic is the fact that it has "preserve the chrominance" toggle, so it's not very clear what "real" colors really should look like.
On Tue, 28 May 2019 11:01:42 +0200 Aurélien Pierre <rese...@aurelienpierre.com> wrote: > Sure, there are people who want to fight the theory of signal processing > to complain about the consequences, and people who do the right thing at > the right time in the pixelpipe. Surprisingly, the latter get better > results faster. > > Filmic is simple to use if you understand what exposure means in the > scene-referred space and in the display-referred space. It just remaps > scene-referred exposure (in ]0 ; + inf[) to display-referred one (in > [0.0 ; 1.0]), by letting users control what is considered white, black > and grey in the picture, and to what values they should be mapped on the > display. But it does so at the end of the pipe, leaving your pixelpipe > linear before, to preserve the consistency of every physically-bounded > filter : > > * blur == optical diffusion -> needs linearity, > * denoising == gradient smoothing -> needs linearity, > * color profile == linear algebra -> needs linearity, > * etc. > > Base curves do exactly the same (look at the shape of the curves… S > curves with raised mid-tones), but too early in the pipe, and with > pre-baked curves done by reverse-engineering raw->JPEG conversion from > cameras manufacturers. Thus, you cross the non-linearity wall too early > in the pipe, and get a one-size-fits-all look. No matter how you put it, > call it different retouching approaches or masochism, it's wrong. I > don't care about opinions or styles, this is signal processing, not > democracy. > > Why ? Because photons live on a linear scale of energy, and good-looking > filters do nothing but simulate numerically on RGB channels what > would/should have happened on photons in real life. So, blurring, > sharpening, masking and denoising need scene-linear RGB code values. > Whereas every tone/base-curve (including filmic) is raising the > mid-tones and adding more contrast (S curve) to reproduce our > logarithmic scale of *perceived* energy. You go from scene-linear to > perceptual space with a logarithm, so you rescale the gradients of > energy (EVs are a log scale, perceptually uniform). > > Once you have crossed that wall of non-linearity, you can kiss your > color accuracy good-bye if you try to apply physically-bounded filters > in a perceptual space. That's exactly what people see with the "wrong > profiles" inconsistencies in this thread. The profiles are not faulty > here, proof is made by using dcraw with the same matrices. But the input > profiles are applied *after* the base curve in the pipe, which was a > design mistake in the first place because you are applying a matrice > profile expecting scene-linear input on perceptually-encoded data. > > As of now, I will stop answering messages from people complaining about > color artifacts while using base curves. They are asking for trouble, > they get it. I have offered an alternative, if people don't want to > listen, it's not my problem. ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
