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

[Steve Purcell]

On 5 May 2011, at 23:53, David De La Harpe Golden wrote:

> On 05/05/11 19:43, Steve Purcell wrote:
> 
>> I think I've been conflating sRGB and device colors.
>> What I'd be in favor of right now would be somebody changing NS
> > to use device RGB colors by default, and seeing if the world
> > falls apart
> >
> > The indications are that it would improve matters for NS emacs
> > users without upsetting anyone else.
> 
> Apple docs do seem quite insistent that the right thing to do is to
> stick to NSCalibratedRGBColorSpace.
> 
> Uh. Then I saw that iterm2 that you mentioned is GPL licensed, so, hey,
> I can see what it's doing. And, it, like emacs, seems to be using the
> NSCalibratedRGBColorSpace throughout, at least at first glance. [1]


Yes, you're right -- I double-checked, and it looks like the authors of 
precision color themes for iTerm2 have had to back-calculate color values that 
would look right at display time:

https://github.com/altercation/solarized/tree/master/iterm2-colors-solarized



> So why then would the colors be different? Well, one possibility would be 
> emaccs somehow not using the api right, but that reminded me of
> something quite important:
> 
> If iterm2 acts as a 256 color terminal emulator, it likely has a fixed
> 256 color palette, just like an x11 256 color terminal. [2]. Some
> 24-bit colors can be displayed perfectly with such a  palette, but the
> bulk get approximated to the nearest available from the palette.


iTerm2 does indeed act like that, but don't worry - I'm not running emacs 
inside iTerm.


> So, uh, what other apps did you compare emacs to besides iterm2?
> Colors shown via iterm2 are suspect!  (I realise you  mention applying
> an srgb to apply-generic-rgb transform "manually" and  it giving
> acceptable results, but I'm now wondering was that all some sort of
> unlikely coincidence)


The poster child app for comparisons is any web browser, in which a hex value 
of #nnnnnn gives the exact same color, as perceived visually and by checking 
with Apple's Digital Color Meter tool. 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.

In my case, to get the right colors for Emacs I had to fire up the arcane color 
calculator inside Apple's ColorSync Utility and then laboriously pick desired 
colors from a web page, and translate them individually to Generic RGB values 
which I could then plug into Emacs. And the results in Emacs still don't 
exactly match the original colors.


> I'd also be worried that "DigitalColor Meter" utility might lead astray
> a bit. Say it shows the about-to-go-to-device values - that would
> meaning that sure, as Erik reported with his patch, when emacs uses the
> device space, effectively a passthru, values you put into emacs exactly
> match the utility's feedback... but... does that patched emacs then
> match other common apps, and do other common apps which allow rgb entry
> match the utility's feedback? (not clear to me from the thread)


Perhaps Erik can comment on whether his device-color-patched Emacs produces 
colors that are perceptually identical?

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.

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.

Nonetheless, I think the browsers are getting it right by doing what users 
expect, and the other apps are confusing.