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 > <mailto: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 <mailto: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 >> <mailto:darktable-dev+unsubscr...@lists.darktable.org> > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > <mailto:darktable-dev%2bunsubscr...@lists.darktable.org> > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
