Review Request: KColorSpace::KHCY::KHCY(const & QColor) constructor floating point precision error
Michael Kreitzer
mrgrim at gr1m.org
Fri Jun 26 22:13:12 BST 2009
On Friday 26 June 2009 12:06:16 pm Matthew Woehlke wrote:
> Johannes Sixt wrote:
> > gamma() is a strictly monotonic function. Therefore, you can look at the
> > integer RGB values of QColor in order to decide which branch to take.
>
> No I can't. I consider redF() more canonical than red() (higher
> precision, and QColor might become HDR in the future).
>
> I could look at the pre-gamma-corrected values, but is that worth
> keeping more variables around (or trusting the compiler to optimize
> multiple calls to redF() and friends)?
>
Maybe something like:
qreal r = color.redF();
qreal g = color.greenF();
qreal b = color.blueF();
a = color.alphaF();
// luma component
if (r == g && g == b)
{
y = 0.0;
r = gamma(r);
g = gamma(g);
b = gamma(b);
{
else
{
r = gamma(r);
b = gamma(b);
g = gamma(g);
y = lumag(r, g, b);
}
Though, I'm not sure I see the point. It's not like the floating point
comparison is being removed. You're just removing an extra layer of math
before making it which might make a precision error less likely at best.
- Michael
More information about the kde-core-devel
mailing list