Subject: Re: bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa))

From: David De La Harpe Golden <[email-masked]>
Date: Fri, 06 May 2011 20:59:43 +0100

On 06/05/11 08:00, Steve Purcell wrote:
 > The poster child app for comparisons is any web browser,

No, that's the one kind of app that I consider invalid for fair
comparison, as standards-compliant browsers are simply required to use
sRGB by default, regardless of any platform-specific conventions.

 > I'd hope that Digital Color Meter displays about-to-go-to-device
 > values; I presume that those color values are the important ones,
 > since all correctly calibrated devices will display those colors
 > identically.

Uh, no, devices can have all sorts of gamut, color values about to go
to the device would be in a post-any-software-transform
pre-any-hardware-LUT-transform form, that may or may not coincide with
sRGB.  Think of how much extra you can pay for a "wide gamut" display
capable of colors well outside sRGB [1] - and how annoyed you'd be if
your OS wasn't sending them.

 > In other words, the system's color picker yields hex colors which,
 > when put in a web page, show up as the desired color. I'd naïvely
 > expect every app to work like this.

I still don't know exactly what DigitalColor Meter is doing.  But maybe
it actually takes steps to always report in sRGB so that it reliably
gives the same value [s]RGB value for the same color shown via
different devices. That  would kinda  make sense, though it would mean
you'd presumably get an  error or clipped answers (or maybe it would
switch to scRGB [2] or something) on wide-gamut displays.

Though it is does seem strange they'd make the system color tool report
in sRGB if they're also telling apps to use Apple Generic RGB, or at
least not offer values in both in it (AFAICS, having seen a screnshot,
it's got a dropdown list of a few spaces to report in) and make it
clear what space its "RGB" really is (by the sounds of it, sRGB...),
but OTOH, maybe it's geared mostly to web dev needs in the first place
- I expect graphics pros are more likely to use photoshop [3].

i.e. the DigitalColor Meter utility might just be doing what browser
users, particularly the web developer types likely to use it, naively
expect.

 > In the interests of fairness,
 > I'll also note that TextMate (an extremely popular non-free editor on
 > OS X) interprets color values in its themes as being in the Apple
 > Generic RGB color space, so I guess internally it's using
 > colorFromCalibratedRed, just like Emacs.

It does sound to me like TextMate is just following the Word Of Apple
like iterm2, then. And emacs is after all an app in the exact same
class as TextMate [3]

 > Nonetheless, I think the browsers are getting it right by doing what
 > users expect,

Er. I think that's sorta the wrong way round, what's happening is that
browsers are starting to generate user expectations for other apps -
like yours. Browsers, again, are flat-out required to use sRGB [5]. Web
folk of course are a major group of emacs users, so it's IMO worth
catering to their needs.  But I'm not sure it's sufficient reason to
switch the default on its own, more of an argument for adding the
switching capability previously discussed.

Though if emacs were to wholeheartedly adopt a standard interpretation
of intraemacs color strings on all color-management-capable platforms,
then Apple Generic RGB would obviously be a hopeless basis (though could
still be provided for with a prefix, say, "AppleGenericRGB:r/g/b").

Perhaps it could be semiseriously argued that emacs, as it is capable
of acting as a quite usable web browser via w3 or emacs-w3m, should use
sRGB and the web named-colors values.

[1] http://www.eizo.com/global/products/coloredge/cg221/index.html

[2] http://en.wikipedia.org/wiki/ScRGB

[3] 
http://blogs.adobe.com/jnack/2008/02/make_photoshop_sample_colors_outside_the_a.html

[4] TextMate is even the first text editor in quite a while to do 
anything particularly interesting from the emacs community perspective - 
right now, you have to add the sorta-kludgey "mumamo" found in the 
"nxhtml" suite for emacs to catch up with it in some areas.

[5] http://www.w3.org/TR/css3-color/#rgb-color