A raw "picture" is just a text file filled with RGB code values. These code values are not data and need to be decoded, by the software but also by the user, to be turned into data (meaning : colors). The software can do some of the low-level decoding, but at the end, only the user knows if the 80 % luminance in his picture is supposed to encode white or grey, and do the proper exposure compensation accordingly.
The original approach of darktable was to give users an image that looked already good, meaning all the decoding was done in software, and the high-level part was done using assumptions (based on cameras manufacturers default look). The result is : open the darkroom, what you see is (almost) what you got on the camera display. Problem 1 : begin tweaking one thing or another, and it will blow up in your face. Problem 2 : having a truly all-purpose default look is an impossible quest. I personally think darktable should default to a neutral look (dark and ugly), but not all the dev team agrees. I guess having a very neutral picture (only demosaiced) as a default starting point in the darkroom would freak out most users. (Just see how many don't understand why dt's preview doesn't look the same as the camera's one…). So, as of now, the neutral default is an option in parameters (in darktable 2.7/git master). For some reason, there is also far less education in color science amongst photographers than in the cinema industry. So, while your average VFX artist or videographer can build his own pixelpipe using nodal editors and gets the XYZ/RGB/Lab/LUT/spectral stuff, your average photographer struggles to understand that a pixelpipe has an order that matters and you don't just fiddle around modules depending how you feel today. It's not simply a matter of upgrading the doc to use the soft (which not many people read anyway), there are theoretical things to understand as well, and people need to do their homework (not on Youtube). Retouching is not bounded to any kind of software, you can do it with film and paper, and learning how to use the soft won't teach people how to actually retouch (e.g. what needs to be done on the picture). Anyway, there will be discussions in a few days at the Libre Graphics Meeting about the pixelpipe, so we will see what can be done to fix that. Dealing with compatibility and legacy while improving is never simple. Le 28/05/2019 à 11:16, François Tissandier a écrit : > 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 <mailto: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 >> <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 > <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
