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
