I couldn't have said it better than Aurélien. I have a default setting for
basecurve that matches any input and is always linear. This essentially
makes the the module do nothing. And I have this since I started using DT.
Caveat: I'm a VFX professional. I know a bit about this topic. ;)
.mm
On May 28, 2019 11:02:35 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.
Le 28/05/2019 à 10:04, François Tissandier a écrit :
The base curve can be still used with the standard one instead of the
camera one, colours are quite fine then. I was doing that before the
arrival of filmic. So the base curve can be kept. And indeed it's good to
have the choice.
Le mar. 28 mai 2019 à 10:00, Florian W <flo.wern...@gmail.com> a écrit :
Not everyone has the same approach of digital development (eg. Film like
response vs more creative curve editing, with its disadvantages) and one of
the strong advantage of Darktable is allowing all these use cases. Starting
a war about this won't get us anywhere in the issue at hand here.
Le mar. 28 mai 2019 09:33, Aurélien Pierre <rese...@aurelienpierre.com> a
écrit :
For the last time :
BASE CURVES ARE EVIL, CRAP, GARBAGE, NO-GO, DON'T TOUCH, BIO HAZARD, KEEP
AWAY, HUN HUN, SURVIVORS WILL BE SHOT AGAIN.
I wouldn't have taken 2 months of my life to develop filmic if base curves
had worked as expected. Base curves are a broken design and will always
destroy colors. I have repeated that multiple times in the past years, it
would be great if people started to listen.
In darktable 2.8, there will be a global preference to have the base curves
disabled by default because they really harm, especially for the newest HDR
cameras. Until then, the first thing you need to do while opening a raw
picture is to disable that god-forsaken module manually.
Thanks for confirming it has nothing to do with matrices though. That means
everything works as expected.
Aurélien.
Le 28/05/2019 à 09:00, Florian Hühn a écrit :
If RawTherapee is really using the same matrices, it would be interesting
to find out what's being done differently (or additionally)...
RawTherapee uses dcraw for import. I took the A7RIII testchart raw and ran
it through 'dcraw -v -w -o 1 -T DSC00157.ARW', then imported the .ARW and
the TIFF created by dcraw into DarkTable. The TIFF lokes more natural to
me. Especially the skin color of the guy on the right looks somehow a bit
yellowish / ill in the .ARW but more natural in the TIFF from dcraw.
BUT: When importing the TIFF no base curve is applied. When I disable base
curve on the .ARW and instead use levels and tone curve manually i can get
a look that is closer to the TIFF (i.e. the dcraw variant).
Maybe it comes down to different default settings in DarkTable importing
vs. dcraw. At some point I'd like to double-check that the matrix
calculations done by DT are indeed carried out as intended, but so far I
didn't find a way to artificially create a raw-file for this purpose.
___________________________________________________________________________
darktable developer mailing list to unsubscribe send a mail to
darktable-dev+unsubscr...@lists.darktable.org
___________________________________________________________________________
darktable developer mailing list to unsubscribe send a mail to
darktable-dev+unsubscr...@lists.darktable.org
___________________________________________________________________________
darktable developer mailing list to unsubscribe send a mail to
darktable-dev+unsubscr...@lists.darktable.org
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
