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

[David De La Harpe Golden <david@harpegolden.net>]

On 10/04/11 23:38, Chong Yidong wrote:
> Steve Purcell<steve@sanityinc.com>  writes:
>
>> what's the color behavior on other window-systems? I haven't had the
>> opportunity to compare. It does seem like your fix would be more
>> likely to give the results a user would want.
>
> On X, we just pass color names to Xlib functions like XParseColor as
> simple RGB,

To nitpick:  AFAIK we pass the /color string names themselves/ to 
XParseColor() to resolve them, don't we? -  color name -> color mapping 
is not internally handled by emacs on X11.

You can even define your own named colors on x11 over and above the 
familiar historic rgb.txt set if you fiddle about e.g.

$ cat ~/.xcms.txt
XCMS_COLORDB_START 0.1
Blobby	rgb:7fe2/ffe1/331a
XCMS_COLORDB_END
$ export XCMSDB=/home/david/.xcms.txt
$ emacs

- Now "Blobby" is an additional named color like "green".

> i.e. not specifying any particular color space, letting that
> be chosen by X.

We-ell. See the XParseColor() manpage, section COLOR NAMES [1] - you
can explicitly specify various device-independent colorspaces, and they 
do in principle work if you put them into a color field in emacs on x11, 
because emacs just passes the string straight on through as mentioned 
above. You just need to use the right syntax as per the manpage (or 
define them as named colors similar to above).  But the 
"rgb:<red>/<green>/<blue>" (or "#RRGGBB") syntax in particular is 
defined to use the device space.

None of the device-independent colorspaces documented as standard by 
XParseColor() are sRGB though, that came later, which is a tad 
inconvenient in the modern era of wide use of sRGB. OTOH, CIEXYZ is 
available and there are forward and reverse transforms that can be 
applied. [2]

HOWEVER... the Xcms [3] scheme predates ICC and isn't really the color 
calibration system people tend to use nowadays AFAIK, people use xicc 
[4] which uses the same ICC profiles as found on windows etc., so the 
chances of a "CIEXYZ:X/Y/Z" color passed to XParseColor() actually 
winding up mapped to the right CIE XYZ point, well, AFAIUI, that would 
depend heavily on a user having actually bothered to set up a reasonable 
Xcms calibration via xcmsdb [5], not just having setup xicc calibration. 
  I suppose some sufficiently advanced tool might exist to extrapolate 
the Xcms calibration from a now-standard ICC calibration, but that 
sounds tricky to me (then again, I'm not an expert).

**  So if you want NS emacs to treat "#RRGGBB" values like x11 emacs 
currently does, it does sound to me like the thing to do is 
colorWithDeviceRed. colorWithCalibratedRed uses the 
NSCalibratedRGBColorSpace, which AFAICS isn't actually sRGB but isn't 
the device space either [6][7].

** It would be also presumably be possible to extend ns emacs to 
internally support some explicitly spelled out device-independent 
colorspace specification in the color spring like XParseColor() and 
therefore x11 emacs supports. If doing that, I do suggest using the same 
syntaxes as x11 for them...

** OTOH it's possible to imagine the emacs project deciding - rather 
backward incompatibly for x11 users mind you - that, say, "#RRGGBB" 
syntax color strings in emacs on all platforms are actually to be 
considered to be in the sRGB colorspace henceforth, like they are 
officially in html/css.

But #RRGGBB couldn't then be passed straight through to XParseColor() 
anymore on x11, because #RRGGBB there is defined to be a backward 
compatibility way of writing colors in the device space also available 
via "rgb:<red>/<green>/<blue>". They would need to be processed into 
CIEXYZ and passed to XParseColor() (in the probably vain hope the user 
has set up Xcms calibration), or (likely yielding better results in the 
modern era in practice AFAIUI) converted via application of an ICC 
profile found via xicc into the device space with a library like 
littlecms [8], which is what GIMP and the like now do.

So a more backward-compat friendly thing to do than using #RRGGBB for 
srgb, might be to add support within emacs for an 
"sRGB:<red>/<green>/<blue>"  syntax by analogy with the standard 
XParseColor() ones, and handle it internally (I guess it's unlikely at 
this stage the xlib maintainers will add such a thing as standard to 
XParseColor(), but I suppose they might...)

Yeesh,that got long. Hope I wasn't talking nonsense.


[1] http://linux.die.net/man/3/xparsecolor

[2] http://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation

[3] http://insar.stanford.edu/~lharcke/programming/Xcms/

[4] http://burtonini.com/blog/computers/xicc

[5] http://linux.die.net/man/1/xcmsdb

[6] 
http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/DrawColor/Concepts/AboutColorSpaces.html#//apple_ref/doc/uid/20000758-BBCHACHA

[7] 
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSColorSpace_Class/Reference/Reference.html#//apple_ref/occ/cl/NSColorSpace


[8] http://www.littlecms.com/