Re: [darktable-dev] DT bad on skin tones?

[Florian W]

@Paul

Appart from the manual, there's several people on youtube either presenting
what you can do module per module and what effect on an image can be
expected for each slider (technical approach), or doing screen recording of
photographs edit (retouch/artistic approach) for a full processing or
targeted to a specific issue (a common one : noise reduction). Some do
both. It is advised to watch these in 1080p quality.

Sometimes seeing the effect in live on several photographs of different
type (portrait, street, architectural...) is really a good complement of
the textual + photo description of the manual.

Checkout (if not already done) Robert Hutton (english), Rawfiner , carafife
and Aurélien Pierre (french if you speak it). Aurélien has a some video on
filmic that are really helpful to understand the technical aspect of the
module, which can be a good help for getting the result you want with it. I
would be surprised that none of these resource have no equivalent in other
languages too.

For the retouch process, more based on what you want to improve rather than
the tool to perform it, there's also a lot of information targeted to
Lightroom users in textual and videos on the internet.

Florian Wernert
Software engineer INSA
In-training Neuroscience researcher
https://www.linkedin.com/in/wernertflorian



Le mer. 29 mai 2019 à 07:00, Andreas Schneider  a
écrit :

> On Wednesday, May 29, 2019 5:48:30 AM CEST paul sorenson wrote:
> > 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.
>
> As always there are several ways to contribute to a Free and Open Source
> project. If you're not writing code, writing documentation is a very good
> way
> to contribute!
>
> --
> Andreas Schneider a...@cryptomilk.org
> GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
>
>
> ___
> 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

Re: [darktable-dev] DT bad on skin tones?

[Andreas Schneider]

On Wednesday, May 29, 2019 5:48:30 AM CEST paul sorenson wrote:
> 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.

As always there are several ways to contribute to a Free and Open Source 
project. If you're not writing code, writing documentation is a very good way 
to contribute!

-- 
Andreas Schneider a...@cryptomilk.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] DT bad on skin tones?

[paul sorenson]

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 > > 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
>> 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
>> 

Re: [darktable-dev] DT bad on skin tones?

[Aurélien Pierre]

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
> 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 

Re: [darktable-dev] dt master branch → Debian Next deps

[Timur Irikovich Davletshin]

Thank you for this comprehensive reply.

Cheers,

Timur.

On Tue, 2019-05-28 at 11:55 +0200, parafin wrote:
> Basically it was decided that depending on just fonts-roboto is the
> right thing to do. In oldstable Debian it's the only package that
> exists
> and it contains the actual fonts, in other Debians it's a meta-
> package
> that depends on actual package (-hinted in stable, -unhinted in
> newer). Looks like that in testing and unstable -hinted package is
> dummy and doesn't contain anything. So your original request to
> depend
> on all variants makes sense only for stable, but you mention Debian
> Next, which I assume is testing. I'm not sure what's this whole mess
> with -hinted and -unhinted is all about, but anyway it doesn't look
> like packagers should care about it, fonts-roboto is the right thing
> to
> depend on.
> 
> As for requires vs recommends dependency there was a disagreement.
> pmjdebruijn chose "recommends" for his Ubuntu packages, darix on the
> other hand thinks that "requires" is the right thing to do. I don't
> think we managed to convince him otherwise, it's his decision in the
> end after all.
> 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] dt master branch → Debian Next deps

[parafin]

Basically it was decided that depending on just fonts-roboto is the
right thing to do. In oldstable Debian it's the only package that exists
and it contains the actual fonts, in other Debians it's a meta-package
that depends on actual package (-hinted in stable, -unhinted in
newer). Looks like that in testing and unstable -hinted package is
dummy and doesn't contain anything. So your original request to depend
on all variants makes sense only for stable, but you mention Debian
Next, which I assume is testing. I'm not sure what's this whole mess
with -hinted and -unhinted is all about, but anyway it doesn't look
like packagers should care about it, fonts-roboto is the right thing to
depend on.

As for requires vs recommends dependency there was a disagreement.
pmjdebruijn chose "recommends" for his Ubuntu packages, darix on the
other hand thinks that "requires" is the right thing to do. I don't
think we managed to convince him otherwise, it's his decision in the
end after all.


On Sun, 26 May 2019 13:02:34 +0300
Timur Irikovich Davletshin  wrote:

> On Sun, 2019-05-19 at 19:50 +0200, parafin wrote:
> > 
> > I have forwarded this thread to darix on IRC, so consider him
> > informed.
> >   
> 
> Hi parafin!
> 
> Any update from darix?
> 
> Timur.
> 
> ___
> 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

Re: [darktable-dev] DT bad on skin tones?

[Florian W]

"

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.

Thanks for trying to make my point a different one than what I expressed in
order to dismiss it.

I expressed that doing the internet equivalent of shouting by writing in
capital is neither a particular strong way to make a point, to exchange
with people, nor to help at the current issue with colors.

I appreciate your work on filmic and I'm aware that basecurves are color
inacurrate BTW. It doesn't allow you to lack some basic respect in your
exchange with people you don't know anything about the background when it
comes to signal processing, independently of how good you can be at it.

Cheers and good luck in fixing the initial issue.
Florian


Le mar. 28 mai 2019 à 11:19, Aurélien Pierre  a
écrit :

> Hi !
>
> That falls back to the difference between Lightroom and Capture One
> colors… If the in-camera software has been tweaked for warmer skins, you
> won't get the same result with an all-purpose matrice alone.
>
> In color balance, push the highlights slider towards magenta (opposite of
> green) with a small saturation, that should do the trick. Maybe do the same
> in mid-tones, and push the shadows to green (to soften the shift).
>
> A.
> Le 28/05/2019 à 10:52, Christian a écrit :
>
> Hello,
>
> :-)
>
> So I did a quick re-test on the X-T3 RAF.
>
> basecurve vs tonecurve (basecurve off) vs filmic (basecurve off).
>
> So, filmic is better but I could not completely get rid
> of the green tint.
>
> Chris
>
>
>
> Am 28.05.2019 um 09:33 schrieb Aurélien Pierre:
>
> 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.*
>
>
> ___
>
> 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

Re: [darktable-dev] DT bad on skin tones?

[Moritz Mœller]

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  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  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  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 

Re: [darktable-dev] DT bad on skin tones?

[parafin]

While I really like the idea behind filmic module, still it's not
always easy to get the colors I want with it. I guess, depending on the
camera, base curve might give better colors by default, but will make
much trouble in other departments. Obvious point that it's not that
easy as just using filmic is the fact that it has "preserve the
chrominance" toggle, so it's not very clear what "real" colors really
should look like.


On Tue, 28 May 2019 11:01:42 +0200
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.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] DT bad on skin tones?

[Aurélien Pierre]

Hi !

That falls back to the difference between Lightroom and Capture One
colors… If the in-camera software has been tweaked for warmer skins, you
won't get the same result with an all-purpose matrice alone.

In color balance, push the highlights slider towards magenta (opposite
of green) with a small saturation, that should do the trick. Maybe do
the same in mid-tones, and push the shadows to green (to soften the shift).

A.

Le 28/05/2019 à 10:52, Christian a écrit :
> Hello,
>
> :-)
>
> So I did a quick re-test on the X-T3 RAF.
>
> basecurve vs tonecurve (basecurve off) vs filmic (basecurve off).
>
> So, filmic is better but I could not completely get rid
> of the green tint.
>
> Chris
>
>
>
> Am 28.05.2019 um 09:33 schrieb Aurélien Pierre:
>> 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.*
>>
>
> ___
>
> 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

Re: [darktable-dev] DT bad on skin tones?

[François Tissandier]

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 
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. 

Re: [darktable-dev] DT bad on skin tones?

[Aurélien Pierre]

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  > 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
> 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', 

Re: [darktable-dev] DT bad on skin tones?

[Bob Tregilus]

On 5/28/19, François Tissandier  wrote:
> 
>
> Indeed the first thing I'm doing is applying a style either switching to
> the base curve, or disabling the module to use filmic. I love what I can
> get out of filmic often, but to be honest Aurélien, filmic is also a bit
> complex to use. I'm trying the presets, but often I have to change the
> settings manually. I can't say that I understand the effect of each
> parameter well enough. I guess it must mean that I don't understand the
> theory enough. But Darktable isn't only for experts, maybe a tutorial would
> help a bit ? Or maybe I just need to learn all the theory better...
>
> In any case, even with my poor skills, I can get photos out of filmic that
> I could never get with the old modules. So it's surely a great improvement
> !
>
> François

---

François

Just found this YouTube tutorial. Hope it helps:
https://www.youtube.com/watch?v=d9LEEj5nNiw

Bob
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

[darktable-dev] Re: Suggestion for a different module to correct fisheye distortion

[Torsten Bronger]

Hallöchen!

Iain Wood writes:

> [...] 
>
> Using this method gives un-natural distortion near the
> corners. Fish-eye hemi preserves shapes outside the central
> area. This is most obvious with faces.

All projections make compromises.  Lensfun’s projections are
optimised for architectural photography.  If you want to preserve
faces, you may use stereographic projection, however, this does not
yield straight vertical lines.

Fisheye-hemi uses cylindrical projection.  You can simulate it with
the following patch in Lensfun:

diff --git a/libs/lensfun/mod-coord.cpp b/libs/lensfun/mod-coord.cpp
index c435756a..aa20e21a 100644
--- a/libs/lensfun/mod-coord.cpp
+++ b/libs/lensfun/mod-coord.cpp
@@ -868,7 +868,7 @@ void lfModifier::ModifyCoord_Geom_ERect_Rect (void *data, 
float *iocoord, int co
 float x = iocoord [0];
 float y = iocoord [1];
 
-double phi = x * inv_dist;
+double phi = asin (x * inv_dist);
 double theta = -y * inv_dist + M_PI / 2.0;
 if (theta < 0)
 {

Then, select "equirectangular", and you get cylindrical instead.
This plus perspective correction seems to yield Fisheye-hemi’s
results, however, without the new Lensfun supported by DT, I cannot
realy tell.  FWIW, I get *very* close without PC already.

This could mea to add the cylindical projection to Lensfun.  It
would be good to make more tests, though.

Tschö,
Torsten.

-- 
Torsten Bronger

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] DT bad on skin tones?

[rawfiner]

It is not a matter of digital development choices here, nor of one's own
tastes or choices, it is a matter of trying to know whether the input color
profiles are well applied in darktable.
We can't compare colors if we use modules that are messing the colors (and
we know base curve does that).
So this has nothing to do with approaches of digital development.
The only question is, with only color accurate modules, are the colors ok
with standard color matrix, or is the colorin module broken

Cheers,
rawfiner

Le mar. 28 mai 2019 à 10:05, François Tissandier <
francois.tissand...@gmail.com> 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  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 
>> 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

Re: [darktable-dev] DT bad on skin tones?

[François Tissandier]

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  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  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

Re: [darktable-dev] DT bad on skin tones?

[Florian W]

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  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

Re: [darktable-dev] DT bad on skin tones?

[François Tissandier]



Indeed the first thing I'm doing is applying a style either switching to
the base curve, or disabling the module to use filmic. I love what I can
get out of filmic often, but to be honest Aurélien, filmic is also a bit
complex to use. I'm trying the presets, but often I have to change the
settings manually. I can't say that I understand the effect of each
parameter well enough. I guess it must mean that I don't understand the
theory enough. But Darktable isn't only for experts, maybe a tutorial would
help a bit ? Or maybe I just need to learn all the theory better...

In any case, even with my poor skills, I can get photos out of filmic that
I could never get with the old modules. So it's surely a great improvement
!

François

Le mar. 28 mai 2019 à 09:33, Aurélien Pierre  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

Re: [darktable-dev] DT bad on skin tones?

[Aurélien Pierre]

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-dev] Suggestion for indexing new files in the Buongiorno database

[Lorenzo Fontanella]

Hi, when searching for new files in folders to be able to index them in the
database.  It would be useful to insert a flag / filter to force the search
to jpeg files only

Thanks

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Re: Suggestion for a different module to correct fisheye distortion

[Iain Wood]

> On 28 May 2019, at 12:35, Torsten Bronger  
> wrote:
> 
> Hallöchen!
> 
> Iain Wood writes:
> 
>> [...]
>> 
>> Yes, true, but it still wouldn't do the fisheye-hemi
>> thing. Whatever order they are applied in, the combination of
>> perspective and lens correction can't achieve the transform
>> necessary to do the fisheye-hemi effect. I'm fairly sure of
>> this. Some sort of free transform is needed as per the photoshop
>> guide in the original post.
> 
> What Lensfun can achieve:
> 
> - Vertical lines are straight and vertical
> - Image cropping is minimal
> - Horizon is straight even if not in the centre
> 
> What is missing?
> 

Using this method gives un-natural distortion near the corners. Fish-eye hemi 
preserves shapes outside the central area. This is most obvious with faces. 
Fisheye-hemi allows fish-eye use for portraits which lensfun usually doesn't. I 
often photograph divers using a fisheye lens because I need to be close to make 
use of the limited light and poor visibility. If I run the images through 
fish-eye hemi then I get useable portraits. Other correction methods just don't 
 seem to work no matter what I try. I can run the processing on some samples to 
demonstrate what I mean if you like, but the rockwell review and the 
fisheye-hemi page both cover it quite well.  

https://www.kenrockwell.com/tech/fisheye-hemi.htm 

https://imadio.com/products/prodpage_hemi.aspx 


Iain


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org