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
> <rese...@aurelienpierre.com <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 <para...@paraf.in
>> <mailto:para...@paraf.in>> 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
>> <mailto:darktable-dev+unsubscr...@lists.darktable.org>
>
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
