This thread is fascinating to me. Are there resources out there for those who want to learn a more technical approach to editing with Darktable. As has been mentioned elsewhere, the manual kind of presents modules in isolation eg the base curve docs don't come with a warning - well maybe a hint in the tip at the end.
I am using 2.7 built from source with base curve turned off but still tend to use filmic a bit by the seat of the pants. Keep up the good work peeps. On 5/28/19 2:01 AM, Aurélien Pierre 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 >> <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 ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
