But since apparently the people in charge of Darktable know about this :
"which was a design mistake in the first place because you are applying a
matrice profile expecting scene-linear input on perceptually-encoded data"
are there plans to fix the design mistake ?
I know that you are offering a solution, but if you take the example of a
newcomer : she or he hears about Darktable, visits the website, downloads
and installs. Maybe reads the documentation if that's someone trying to put
things in the right order, like you with the modules ;) But then, even in
the documentation, there is nothing stating "BASE CURVES ARE EVIL, CRAP,
GARBAGE, NO-GO, DON'T TOUCH, BIO HAZARD, KEEP AWAY, HUN HUN, SURVIVORS WILL
BE SHOT AGAIN." People will just try different modules and even use base
curve, since it's on by default. If it's really broken by design, I hope
that version 2.8 will turn it off by default. Or at least explain in the
documentation. If you explain it here Aurélien, it's great for people
actively following the project, but for most users, I'm not too sure if it
can have an effect. Those people are not necessarily "asking for trouble",
since we can't even really know about it without reading the mailing list,
or I missed something in the darktable communication somewhere ? But I'm
always trying to put myself in the shoes of the very very lambda user,
instead of my own case.
Maybe you have taken all this into account and the default settings as well
as the documentation of 2.8 will be better, and you can ignore this email.
The image of Darktable is important, to gain new users. If by default,
without digging in the mailing list, you can't know what settings are
wrong, you will have a bad first experience with DT.
Just my two cents, it would be a pity to lose users because of this.
François
On Tue, May 28, 2019 at 11:02 AM 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
