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