On Tue, Feb 6, 2018 at 9:17 AM, Máirín Duffy <duffy@xxxxxxxxxxxxxxxxx> wrote: > 3) Green as a color for digital display is somewhat problematic as it is the > color with the poorest coverage in the sRGB color gamut, meaning across > various displays it can appear very different, making it an inconsistent > color for branding. (see [7], figure 4 for a diagram of the gamut) There are different reasons why each color can fail to render as expected, but the number one reason is the lack of display compensation, i.e. transform original content from sRGB into custom RGB values based on the currently selected display profile. Second guessing how a color will render wrong in a world without display compensation, is folly. We're more sensitive to hue error in blue than red, and more sensitive to hue error in red than green - and even CIELUV underestimates the problem in particular in blue. And more sensitive to hue error in achromatic color than chromatic color. So there's really all kinds of ways for color matching to fail and just avoiding greens isn't going to improve the chance of a color match. To improve color matching, UI elements need to be assumed to be sRGB, and those RGB values converted on the fly to RGB values for the display in use. *shrug* Everything else is a crap shoot. Apple's been doing this for a long time. Windows can do it as an opt in. And while a fair chunk of infrastructure work is present for this to be possible on Linux, right now GNOME would have to do this itself on its own just like any other application does, because there isn't a standard API or compositor that an application can use to opt into display compensation more automatically, or for free. -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
