Hi,
HSL/HSV are only meant to be GUI convenience space to allow the user to
quickly define an RGB parameter. They are not supposed to be used to
actually push pixels, since they are neither physically-referred or
perceptually-referred. No image should ever be converted to actual HSL
space (aside from geeky play violating psychophysics).
So, I wonder where this is a problem in a scene-linear (unbounded)
workflow. Only the saturation is implicitely "bounded" (or, more
exactly, will be negative if pmax and pmin > 1 or NaN if pmax = pmin =
1, wich – good catch – needs to be solved). Even if you are defining
parametric masks in HSL, the only component relevant to pull a key is H,
since the 2 others are meaningless pixel gibberish.
One could try a cylindrical HSY for parametric masking, at least the
luminance and saturation would have some perceptual connection. But the
hue would still be half-garbage. And please, let Lch/Luv where they
belong : in museums. This space is built around the implicit that the
image has 6.5 EV dynamic range (assumed to be the static DR of the
retina in 1976), so it is really not suited as a working space when your
average sensor blasts easily 12 EV DR at base ISO.
Cheers,
Aurélien.
Le 10/04/2020 à 11:27, Harold le Clément a écrit :
> Hello,
>
> In colorspaces.c there is the following code to convert between RGB and HSL:
>
> void rgb2hsl(const float rgb[3], float *h, float *s, float *l)
> {
> const float r = rgb[0], g = rgb[1], b = rgb[2];
> float pmax = fmax(r, fmax(g, b));
> float pmin = fmin(r, fmin(g, b));
> float delta = (pmax - pmin);
>
> float hv = 0, sv = 0, lv = (pmin + pmax) / 2.0;
>
> if(pmax != pmin)
> {
> sv = lv < 0.5 ? delta / (pmax + pmin) : delta / (2.0 - pmax - pmin);
>
> if(pmax == r)
> hv = (g - b) / delta;
> else if(pmax == g)
> hv = 2.0 + (b - r) / delta;
> else if(pmax == b)
> hv = 4.0 + (r - g) / delta;
> hv /= 6.0;
> if(hv < 0.0)
> hv += 1.0;
> else if(hv > 1.0)
> hv -= 1.0;
> }
> *h = hv;
> *s = sv;
> *l = lv;
> }
>
> Due to the way the saturation is computed, it looks like this function
> expects the RGB values to be limited to the range [0.0,1.0].
>
> When using the filmic module and exposing for the middle gray with the
> exposure module, we have (in the default iop order) a set of modules
> (those between the exposure module and the filmic module) that may
> have, as input RGB, values higher than 1.0. This may cause the
> conversion to HSL to produce inaccurate values, right?
>
> Some examples of functionalities that could have issues: channel
> mixer, color picker (used in the blending and modules like the color
> balance), some blending modes.
>
> Some questions:
>
> - Is this a real issue or is this a bad usage of darktable? I.e. shall
> we never have RGB values higher that 1.0 in the pipe?
>
> - In the case this should ideally be fixed, I see three possibilities,
> are there others?
>
> 1. Use another hue/saturation/lightness estimator: HSV (although value
> is really different than lightness) or LCh (probably a lot more
> computationally intensive), ...
>
> 2. Scale the RGB values based on some definition of "white" (maximum
> luminance) using additional graphical widgets, but this would probably
> overwhelm the users with options and sliders
>
> 3. Scale the RGB values based on some definition of "white" (maximum
> luminance) using the "processed_maximum" value in the pixel pipe, but
> it looks like some modules do not update it: e.g. filmic, rgb curve
> and base curve
>
> - What is the best way to keep the backward compatibility in the case
> algorithms are changed?
>
> Thanks a lot in advance for your feedback,
>
> Harold
> ___________________________________________________________________________
> 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
