On Wed, Mar 6, 2019 at 5:28 AM Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Wed, 6 Mar 2019 13:44:39 +1100 > Graeme Gill <grae...@argyllcms.com> wrote: > > > Blending could convert from the device space back > > to XYZ, blend, and then convert back to device space. > > It would use whatever intent is appropriate for blending > > purposes, i.e. probably Relative Colorimetric. > > But I doubt this is the best approach. (see my previous > > post on blending.) > > Hi Graeme, > > yes, you're right. I wrote that before I understood that the > destination space can also be used for blending, it only needs to be > linearized.
If the destination color space is defined by an actual display profile (actual being a profile for someone's physical display; rather than an idealized space such as sRGB, opRGB, ROMM RGB) you have to be careful about some things. Real displays often are not gray balanced. Calibration should achieve this, often it can't. What if the display is characterized and not calibrated to force R=G=B to be a neutral. And also what is neutral? Usually the black point xy (chromaticity, CIE xyY space) is ignored and assumed to be the same as the white point xy, but what if it isn't? Also, the display profiles for displays can contain errors. In particular the case where the xy for the primaries don't add up to the white point xy; that is R+G+B!=white, which is a basic violation of physics but does end up getting baked into some ICC profiles typically because someone did adaptation incorrectly or made some wrong assumption somewhere. Firefox has some code to disqualify such display profiles and just use sRGB instead. I think colord can do this too but I don't think the metrics for disqualification are the same. Ideally I'd like to see whatever is used to set the display profile does this kind of check and immediately disqualifies the display profile with a user notification. I tend to refer to sRGB, opRGB/Adobe RGB (1998), ROMM/Prophoto RGB, as "manufactured" or "idealized" or "quasi device-independent" color spaces because they are well behaved, you can assume equal amounts of RGB will produce a neutral, you can assume they approximately perceptual linear (if you're also assuming the reference medium and reference environment their color image encodings specify, and why not assume that since everyone else is?). I'm not clear to me what is the advantage of blending in 32bpc XYZ versus blending in a 32bpc "manufactured" RGB color space. I literally can't think of anyone actually doing that. Plus aren't most blending algorithms already RGB based? So why change that? The potential to blend in such a space and end up with massively chromatic colors that can only be clipped to the destination gamut boundary when converting to displayRGB, is real. We already run into this problem, sometimes, when the blending space is linear ProPhoto RGB (same primaries as ROMM RGB, using gamma 1.0 function instead of 1.8). A possibly important side topic to understand about rendering intent transforms: it is not intelligent or dynamic. -- Chris Murphy _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel