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