GNU bug report logs - #8402
24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)

Previous Next

Full log

Message #53 received at 8402 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Steve Purcell <steve <at> sanityinc.com>
Cc: 8402 <at> debbugs.gnu.org, Erik Andrejko <eandrejko <at> gmail.com>,
	Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#8402: Acknowledgement (24.0.50;	Hex colors are not rendered
	correctly on OS X (Cocoa))
Date: Thu, 05 May 2011 23:53:14 +0100

[Message part 1 (text/plain, inline)]

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]

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.

To show you the quantization effect I mean, see the attached
emacs_tt_vs_gui_cols.png, it's a screenshot from my x11 system of emacs
using the same face color settings in x11 emacs and a 256-color text
terminal. On a text terminal, emacs can only pick similar but not quite
identical colors.

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)

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)

Unfortunately I don't have a mac, so right now I can't personally
compare to other apps or test anything...

> Having a customization for the NS colorspace would be a nice-to-have,

Yup.

> and the possibility of having colors displayed identically across
> all window-systems would be a laudable longer-term goal.

Indeed.


[1] 
http://www.google.com/codesearch?hl=en&lr=&q=Calibrated+package%3Ahttp%3A%2F%2Fiterm2\.googlecode\.com

[2] http://www.pixelbeat.org/docs/terminal_colours/#256

[emacs_tt_vs_gui_cols.png (image/png, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.