Re: [darktable-dev] Vibrance slider in the Basic adjustments tool
Modified again, thanks to a suggestion by Aurélien. I made a testing version (found on my pull request https://github.com/darktable-org/darktable/pull/3121) with 3 vibrance sliders to compare the effects of the different formulas. At the moment only on non-OpenCL version. I checked the effect on different images and I don't see lot of difference for the 3 formulas (except they aren't well balanced - some have a stronger effect). Anyway, on my test images I see no visible hue shift. I think the first one affects the most the other parameters of the image (hue, contrast), so I have a slight preference for the vibrance2/vibrance3 sliders. What do you think? >From a computing point of view, the first two should be marginally faster... Waiting for your opinions and further ideas! On Fri, Oct 11, 2019 at 6:53 PM Keresztes Barna wrote: > Pull request done! > First I wanted to make sure everything was okay. > Thanks again for the suggestions on the vibrance formula! > > On 11/10/2019 18:33, Pascal Obry wrote: > > If you want to have a little chance that this be tested please create a > > pull-request on the main darktable GitHub. > > > > Thanks, > > > > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Vibrance slider in the Basic adjustments tool
Pull request done! First I wanted to make sure everything was okay. Thanks again for the suggestions on the vibrance formula! On 11/10/2019 18:33, Pascal Obry wrote: If you want to have a little chance that this be tested please create a pull-request on the main darktable GitHub. Thanks, ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Vibrance slider in the Basic adjustments tool
Le vendredi 11 octobre 2019 à 18:22 +0200, Keresztes Barna a écrit : > Thanks Aurélien! > > Formula changed, new version on Git ready for testing: > https://github.com/kbarni/darktable > (please test especially the OpenCL kernel, as I don't have the hardware to > test it!) If you want to have a little chance that this be tested please create a pull-request on the main darktable GitHub. Thanks, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Vibrance slider in the Basic adjustments tool
Thanks Aurélien!
Formula changed, new version on Git ready for testing:
https://github.com/kbarni/darktable
(please test especially the OpenCL kernel, as I don't have the hardware
to test it!)
On 11/10/2019 16:57, Aurélien Pierre wrote:
Actually, I made a mistake. The formula I gave you will produce hue
shifts.
If you think about it, saturation means "how rich the colour is",
which translates in math by "how far the RGB components are from their
corresponding luminance", so adjusting the saturation means rescaling
the difference ({ RGB } - Y) around Y (that's what
Y+saturation*(pixel-Y) does).
The idea of vibrance is to do the same, but with a penalty for colours
that are already rich. Power-like functions are great at doing that
(for powers < 1) : you get a large correction close to 0, and small
correction close to 1. However, doing so, you need to ensure the 3
components get the same ratio of correction, otherwise hue will shift
(and the formula I gave you will likely make hues shifts to blue).
*{ RGB } = Y + saturation * ( ( Y * ({ RGB } / Y)^vibrance - Y))
*should behave as expected, and you can factorize it as *Y * ( 1 +
saturation * (({ RGB } / Y)^vibrance - 1))*. Basically, you scale by Y
before applying the power. It's the same logic as the fulcrum
contrast. You need to be sure that Y is non-zero though (but if Y == 0
at this point of the pipe, something is seriously screwed before).
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Vibrance slider in the Basic adjustments tool
Le 11/10/2019 à 13:31, Keresztes Barna a écrit :
> Thanks for the feedback, Aurélien!
>
> 1. I used this formula for the
> vibrance: http://redqueengraphics.com/category/color-adjustments/ (it
> can also be computed together with saturation).
> I changed it to your proposed formula, to be consistent with other
> software. It's also cleaner to have the two formulas in one line
Actually, I made a mistake. The formula I gave you will produce hue shifts.
If you think about it, saturation means "how rich the colour is", which
translates in math by "how far the RGB components are from their
corresponding luminance", so adjusting the saturation means rescaling
the difference ({ RGB } - Y) around Y (that's what
Y+saturation*(pixel-Y) does).
The idea of vibrance is to do the same, but with a penalty for colours
that are already rich. Power-like functions are great at doing that (for
powers < 1) : you get a large correction close to 0, and small
correction close to 1. However, doing so, you need to ensure the 3
components get the same ratio of correction, otherwise hue will shift
(and the formula I gave you will likely make hues shifts to blue).
*{ RGB } = Y + saturation * ( ( Y * ({ RGB } / Y)^vibrance - Y)) *should
behave as expected, and you can factorize it as *Y * ( 1 + saturation *
(({ RGB } / Y)^vibrance - 1))*. Basically, you scale by Y before
applying the power. It's the same logic as the fulcrum contrast. You
need to be sure that Y is non-zero though (but if Y == 0 at this point
of the pipe, something is seriously screwed before).
>
> Normally this adds a minimal computational complexity (a power
> operation for every pixel), so it shouldn't have an impact on
> processing speed. I can optimize this a bit (if only the saturation is
> changed, but not the vibrance), but I don't think it would have any
> measurable speed gain.
> Instead of:
> if(saturation OR vibrance) pixel=Y+saturation*(pixel-Y)^vibrance
> I could use:
> if(saturation)
> if(vibrance) pixel=Y+saturation*(pixel-Y)^vibrance
> else pixel=Y+saturation*(pixel-Y)
Actually, this kind of trick is good for non-vectorized code (pure C
code path), but it will slow-down computations for vectorized paths
(OpenCL and SSE2). For vector computations, the code sequence should be
independent from the pixel values, so vectors can be processed linearly,
otherwise values check are breaking points. No-branching loops are
better for OpenCL and SSE, just compute the native_powr no matter what.
>
> 2. Yep, I imagine that Basic adjustments is difficult to program (as
> it's basically several filters in one tool) and it brakes the one
> tool-one function philosophy, but IMHO it's a great help from a
> usability point of view. I missed it a lot when switched from
> AftershotPro to darktable.
>
> On Thu, Oct 10, 2019 at 10:06 PM Aurélien Pierre
> mailto:rese...@aurelienpierre.com>> wrote:
>
> Hi,
>
> 1. Vibrance is supposed to be *{ RGB } = Y + saturation * ( { RGB
> } - Y )^vibrance*, where Y is the luminance channel from XYZ
> space, and { RGB } a pixel vector. This way, you perform both
> operations at once. Also, using (R + G + B) / 3 instead of Y is
> generally not a good idea since it has no perceptual background (R
> = G = B values does not equal visual grey in every RGB space, RGB
> is just a random vector space until a proper profile is applied).
>
> 2. The basic adjustments module is a double edged sword : yes,
> it's nice to have a unified *UI* to quickely set-up pictures, but
> it's not just an UI, it's also an image operation that gathers at
> once several operations that need to be done at different places
> of the pixel pipe to get proper results :
>
> * exposure is a scene-referred operations that needs to be done
> preferable before input coulour profile, since input matrices
> are optimized approximations for mid-tones and skin-tones, in
> order to put the RGB values in this sweet spot before applying
> the profile
> * saturation needs to happen after the input matrice, when the Y
> channel is defined (actually, input matrices only profile the
> conversion from camera RGB to XYZ),
> * contrast needs to happen after any frequency filter.
>
> TL;DR the model/view/controller architecture got violated here.
>
> Cheers,
>
> Aurélien.
>
> Le 10/10/2019 à 21:21, Keresztes Barna a écrit :
>> On Thu, Oct 10, 2019 at 8:58 PM parafin > > wrote:
>>
>> Is it any different from velvia iop in darktable?
>>
>>
>> Yes, it affects colors less than Velvia. It doesn't intend to
>> emulate film.
>> The results of this slider are very similar to the standalone
>> Vibrance tool.
>> There are some important differences:
>> - The formula I use is different. It is run earlier in the
>> pipeline, in the RGB color space (Vibrance tool runs on Lab)
Re: [darktable-dev] Vibrance slider in the Basic adjustments tool
Thanks for the feedback, Aurélien!
1. I used this formula for the vibrance:
http://redqueengraphics.com/category/color-adjustments/ (it can also be
computed together with saturation).
I changed it to your proposed formula, to be consistent with other
software. It's also cleaner to have the two formulas in one line
Normally this adds a minimal computational complexity (a power operation
for every pixel), so it shouldn't have an impact on processing speed. I can
optimize this a bit (if only the saturation is changed, but not the
vibrance), but I don't think it would have any measurable speed gain.
Instead of:
if(saturation OR vibrance) pixel=Y+saturation*(pixel-Y)^vibrance
I could use:
if(saturation)
if(vibrance) pixel=Y+saturation*(pixel-Y)^vibrance
else pixel=Y+saturation*(pixel-Y)
2. Yep, I imagine that Basic adjustments is difficult to program (as it's
basically several filters in one tool) and it brakes the one tool-one
function philosophy, but IMHO it's a great help from a usability point of
view. I missed it a lot when switched from AftershotPro to darktable.
On Thu, Oct 10, 2019 at 10:06 PM Aurélien Pierre
wrote:
> Hi,
>
> 1. Vibrance is supposed to be *{ RGB } = Y + saturation * ( { RGB } - Y
> )^vibrance*, where Y is the luminance channel from XYZ space, and { RGB }
> a pixel vector. This way, you perform both operations at once. Also, using
> (R + G + B) / 3 instead of Y is generally not a good idea since it has no
> perceptual background (R = G = B values does not equal visual grey in every
> RGB space, RGB is just a random vector space until a proper profile is
> applied).
>
> 2. The basic adjustments module is a double edged sword : yes, it's nice
> to have a unified *UI* to quickely set-up pictures, but it's not just an
> UI, it's also an image operation that gathers at once several operations
> that need to be done at different places of the pixel pipe to get proper
> results :
>
>- exposure is a scene-referred operations that needs to be done
>preferable before input coulour profile, since input matrices are optimized
>approximations for mid-tones and skin-tones, in order to put the RGB values
>in this sweet spot before applying the profile
>- saturation needs to happen after the input matrice, when the Y
>channel is defined (actually, input matrices only profile the conversion
>from camera RGB to XYZ),
>- contrast needs to happen after any frequency filter.
>
> TL;DR the model/view/controller architecture got violated here.
>
> Cheers,
>
> Aurélien.
> Le 10/10/2019 à 21:21, Keresztes Barna a écrit :
>
> On Thu, Oct 10, 2019 at 8:58 PM parafin wrote:
>
>> Is it any different from velvia iop in darktable?
>>
>
> Yes, it affects colors less than Velvia. It doesn't intend to emulate
> film.
> The results of this slider are very similar to the standalone Vibrance
> tool.
> There are some important differences:
> - The formula I use is different. It is run earlier in the pipeline, in
> the RGB color space (Vibrance tool runs on Lab)
> - This slider allows negative vibrance settings (so you can fade the
> colors without totally desaturating them)
> - it's a part of the Basic Adjustments tool, it can be used easily to set
> the color "amplitude" in the image together with the saturation slider.
> - It has a larger amplitude, so the results are more visible (sometimes
> the original Vibrance tool is barely perceptible).
>
> ___
> 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] Vibrance slider in the Basic adjustments tool
Hi,
1. Vibrance is supposed to be *{ RGB } = Y + saturation * ( { RGB } - Y
)^vibrance*, where Y is the luminance channel from XYZ space, and { RGB
} a pixel vector. This way, you perform both operations at once. Also,
using (R + G + B) / 3 instead of Y is generally not a good idea since it
has no perceptual background (R = G = B values does not equal visual
grey in every RGB space, RGB is just a random vector space until a
proper profile is applied).
2. The basic adjustments module is a double edged sword : yes, it's nice
to have a unified *UI* to quickely set-up pictures, but it's not just an
UI, it's also an image operation that gathers at once several operations
that need to be done at different places of the pixel pipe to get proper
results :
* exposure is a scene-referred operations that needs to be done
preferable before input coulour profile, since input matrices are
optimized approximations for mid-tones and skin-tones, in order to
put the RGB values in this sweet spot before applying the profile
* saturation needs to happen after the input matrice, when the Y
channel is defined (actually, input matrices only profile the
conversion from camera RGB to XYZ),
* contrast needs to happen after any frequency filter.
TL;DR the model/view/controller architecture got violated here.
Cheers,
Aurélien.
Le 10/10/2019 à 21:21, Keresztes Barna a écrit :
> On Thu, Oct 10, 2019 at 8:58 PM parafin > wrote:
>
> Is it any different from velvia iop in darktable?
>
>
> Yes, it affects colors less than Velvia. It doesn't intend to emulate
> film.
> The results of this slider are very similar to the standalone Vibrance
> tool.
> There are some important differences:
> - The formula I use is different. It is run earlier in the pipeline,
> in the RGB color space (Vibrance tool runs on Lab)
> - This slider allows negative vibrance settings (so you can fade the
> colors without totally desaturating them)
> - it's a part of the Basic Adjustments tool, it can be used easily to
> set the color "amplitude" in the image together with the saturation
> slider.
> - It has a larger amplitude, so the results are more visible
> (sometimes the original Vibrance tool is barely perceptible).
>
> ___
> 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] Vibrance slider in the Basic adjustments tool
On Thu, Oct 10, 2019 at 8:58 PM parafin wrote: > Is it any different from velvia iop in darktable? > Yes, it affects colors less than Velvia. It doesn't intend to emulate film. The results of this slider are very similar to the standalone Vibrance tool. There are some important differences: - The formula I use is different. It is run earlier in the pipeline, in the RGB color space (Vibrance tool runs on Lab) - This slider allows negative vibrance settings (so you can fade the colors without totally desaturating them) - it's a part of the Basic Adjustments tool, it can be used easily to set the color "amplitude" in the image together with the saturation slider. - It has a larger amplitude, so the results are more visible (sometimes the original Vibrance tool is barely perceptible). ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Vibrance slider in the Basic adjustments tool
Is it any different from velvia iop in darktable? On Thu, 10 Oct 2019 20:44:25 +0200 Keresztes Barna wrote: > Hi all, > > I'm a happy user of Darktable! One of my favorite tools in the 2.7 branch > is the *Basic Adjustments tool*, where I can find in one place most of the > tools I need to make quick adjustments for my image. > > I would like to add a *vibrance* *slider* to this tool. It affects the > saturation of the more saturated pixels. It can be used to accentuate the > colors without becoming unnatural (as it's often the case of the saturation > tool). It also has negative values, so you can use it to make your colors > fade. > Used together with the saturation slider, you can also work on less > saturated areas of the image. Otherwise it doesn't change a lot the > inderface and it fits well in the Basic Adjustments tool. > > It is similar (and similarly positioned) as the vibrance tools in Lightroom > and Aftershot Pro (ASP) and probably other similar software. Note that it > uses a different algorithm than ASP, it's also different from the Vibrance > tool of DT. > > What do you think about the idea? > > Before pushing it to the main branch, I would like to ask you to test it! > You can find my modifications in my fork on Github: > https://github.com/kbarni/darktable > > What do you think? Do you like the results? > > The OpenCL part is untested (don’t have the hardware), so it needs to be > checked too. > > P.S. This is my first contribution to DarkTable; however I developed > several plugins for Bibble/Aftershot Pro, some of which become part of the > core tools. > > ___ > 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
