[Digikam-users] Re: digiKam raw converter default gamma curve

[Pentti Rautio]

2011/3/1 Elle Stone <l.elle.stone at gmail.com>:
> Pentii, not knowing what a Nikonian gamma curve is (in Canon there are
> "picture style" curves, but they are applied post-processing), I would
> like to ask, what it is that you want to have happen when you decode a
> raw file, that perhaps isn't happening with the digikam raw converter?
>

The problem with digiKam is that when a novice user tries to use
Raw-processing the results are not good enough (usually a bit too dark
or dull) and the user don't know what to do to make it look good. When
using color profiles it is the same for novice users (results are a
bit too dark usually then too and you must know how to  correct it
manually).

There are manufacture specific correction curves in the program
Darktable that are automatically selected by the program. They work
well for at least for Nikon and Pentax cameras (haven't tried others).
The different camera correction curves can be seen in a "basic" (my
translation) window. I don't know if this curved-correction is done in
raw calculation or in post-processing.  Maybe it could be tried to use
these curves in digikam post-processing similarly as camera specific
default?

Other things that new cameras do to the jpg are some levelling and
correction for highlights or darks and that makes sometimes the camera
jpg:s to look better than when done directly from RAW or at least you
should do those corrections later before comparing RAW-processed image
to camera-jpg. What I would like to have implemented in RAW-processing
is some kind of highlight blending.

Pentti


> Gilles, when you say "gamma curve" do you mean the gamma curve on the
> post-processing tab? because that is not the gamma that I'm talking
> about.
>
> I'm talking about the "gamma curve" in the code below ("ts" stands for
> "toe slope" - if it isn't 0, it isn't really a gamma curve):
>
> dcraw code:
> void CLASS gamma_curve (double pwr, double ts, int mode, int imax)
>
> Code from libkdcraw (line starting with double gamm[6]):
> (this section of code appears in another document, but it's the same
> both places)
>
> LibRaw:: LibRaw(unsigned int flags)
> {
>    double aber[4] = {1,1,1,1};
>    double gamm[6] = { 0.45,4.5,0,0,0,0 };
>    unsigned greybox[4] =  { 0, 0, UINT_MAX, UINT_MAX };
>    unsigned cropbox[4] =  { 0, 0, UINT_MAX, UINT_MAX };
>
> In the above libraw code gamm[6] has 0.45 as the "power" value and 4.5
> as the "toe slope" value.
>
> dcraw uses the same defaults as  what is hard-coded into the LibRaw
> code snippet above. UFRaw defaults are close visually, but I don't
> know what scale or math-model UFRaw uses in the gui for allowing the
> user to set the toe slope (toe-slope is called "linearity" in UFRaw).
>
> In UFRAW and in dcraw the end user, that is, the person using the
> programs to decode raw files, can specify OTHER values, such as "0"
> for the toe slope, to get a true gamma curve DURING interpolation.
>
> Gamma applied post-processing canNOT make up for whatever gamma was
> applied during raw rendering. Especially not if a non-zero toe-slope
> was used during raw rendering.
>
> Are you saying that the libraw api doesn't allow the digiKam raw
> converter programmer ( the person writing the code behind the digiKam
> raw converter - I think that is you, Gilles, yes?), to give the end
> user (the person actually using the program to decode a raw file) a
> choice of power and toe slope? That the libraw api ONLY lets the
> programmer provide the hard-coded defaults to the end user?
>
> The reason I am asking, is all my camera input profiles use a true
> gamma curve of either 1 (linear gamma) or 2.2. So the respective
> gamm[6] toe-slope value needs to be 0. I don't mind altering the
> libkdcrw source code and recompiling libkdcraw for my own personal
> use.
>
> But if the programmer gave the end-user access to setting their own
> power and toe-slope, like dcraw and UFRaw do, it would be really much
> nicer.
>
> Elle
>
> On 2/28/11, Gilles Caulier <caulier.gilles at gmail.com> wrote:
>> The gamma curve is computed automatically by libraw. Ther is no tune
>> available from libraw api to adjust curve.
>>
>> Only some gamma adjustments are possible from libraw, not a fulll curve.
>>
>> This is why; i added a full curve correction in post processing
>> settings. There is 2 way to use it :
>>
>> - let's post processing computed by libraw to adjust gamma
>> automatically, and process fine adjustment from digiKam postprocessing
>> curves.
>> - disable libraw gamma processing and adjust whole gamma curve from
>> digiKam post processing.
>>
>> Gilles Caulier
>>
>> 2011/2/27 Pentti Rautio <pentti.j.rautio at googlemail.com>:
>>> Hi Elle, hope that you tell what are your conclusions about gamma
>>> correction (when and where and how?)
>>>
>>> By the way : could there be a manufacturer specific correction
>>> somewhere in the code so for example nikon NEF uses a "nikonian" gamma
>>> etc.
>>>
>>> Pentti
>>>
>>> 2011/2/26 Elle Stone <l.elle.stone at gmail.com>:
>>>> Never mind, kfind and geany to the rescue. I found the code section.
>>>> Elle
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> Digikam-users at kde.org
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> Digikam-users at kde.org
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>> _______________________________________________
>> Digikam-users mailing list
>> Digikam-users at kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>