compiled emacs with srgb, separator colors are wrong
LeoLionel opened this issue · comments
Hallo!
I compiled emacs24 on my mac with homebrew and the srgb option
(https://github.com/Homebrew/homebrew/blob/master/Library/Formula/emacs.rb)
Now using powerline the colors of the separators don't match the color-theme anymore.
Is there away to get them right?
Cheers!
I have the same problem. on OS X 10.9, emacs-bzr-version: 116475.
I remember this being an issue but in not sure what the fix is.
On Feb 25, 2014 5:34 AM, "Shihpin Tseng" notifications@github.com wrote:
I have the same problem. on OS X 10.9, emacs-bzr-version: 116475.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-36007231
.
Same problem +1 to a solution
same still have problem!
Yeah, i don't have a solution to this problem. It's the fact that whatever
code is being used to generate the pixmaps is not using the new srgb stuff.
maybe there is some small code change that needs to happen elsewhere?
On Tue, Jul 29, 2014 at 9:04 AM, Ray H notifications@github.com wrote:
same still have problem!
—
Reply to this email directly or view it on GitHub
#54 (comment)
.
I have the same problem with emac 24.4.50.1
+1, using 24.4 on OS X. I didn't explicitly compile emacs with srgb but I think it's default in 24.4?
+1, 24.4 on OS X.
Known issue. Nothing we can do really unless we detect it, we currently
cannot, and then manually adjust the colors
On Mon, Oct 27, 2014 at 05:22 Jack Rusher notifications@github.com wrote:
+1, 24.4 on OS X.
—
Reply to this email directly or view it on GitHub
#54 (comment)
.
@chiangqiqi I think @jupl’s change basically makes the colors “wrong” for the rest of Emacs as well, so they match the colors used by the pixmaps.
There are many colorspaces – sRGB is one of them. Disabling the use of sRGB switches to an uncorrected colorspace, which is what the image generation program must be using as well. So, turning off sRGB will make all your Emacs colors slightly off, but at least it will match.
I had the opposite of this problem with sellout/emacs-color-theme-solarized, back when Cocoa Emacs didn’t support sRGB at all, and users would complain that the theme colors were wrong (but with an uncorrected space, the right colors had slightly different values on different machines, so fixing them for one user could make them worse for another user).
I don’t have a solution here, unfortunately. But I’ll look into it.
Oh, another workaround is to use UTF-8 separators, then you don’t have the issue with XPM colors. The best separators I’ve found are ►/◄ (#x25ba / #x25c4) – please let me know if you find others that look better!
The graphics are generated as xpm pixel maps so there's no color space encoding, that's why they don't look right in sRGB.
For anyone interested, this is the workaround I'm currently using to get the colours to look good under sRGB: http://irrationalrose.com/2015/05/29/workaround-for-srgb-colour-issue-for-powerline-on-os-x.html
emacs-mac port also works. https://github.com/railwaycat/homebrew-emacsmacport
@jupl 👍
Oh, another workaround is to use UTF-8 separators, then you don’t have the issue with XPM colors. The best separators I’ve found are ►/◄ (#x25ba / #x25c4) – please let me know if you find others that look better!
This is why I disabled separators completely, pixmap separators have wrong background colour and looks ugly on Retina display, and UTF-8 separators are missed in most fonts (I change frame font quite frequently because due to my nature things quickly bored me). Oh, by the way recently I have found that it's totally easy and OK to customize mode-line face setting height and font family different to default face.
There is a bug in the MacOS version of Emacs which draws all images using the Apple RGB color space. This was fine back in the days, but newer OSX versions default to the sRGB color space. So while Emacs uses correct colors for the text area, it uses wrong color for the XPM images used by powerline.
I have written a patch, which works around the issue by converting sRGB colors to Apple RGB colors before XPM generation. I have added an options (which is off by default) to enable the workaround. YMMV.
@jupl (setq powerline-image-apple-rgb t)
@anuragm Thanks! (setq powerline-image-apple-rgb t) works perfect for me. BTW I saw you're collecting the feedbacks for machines with P3 color space in another issue. My machine is MacBook Pro late 2017 which works really nice. Below are some screenshots.
With (setq powerline-image-apple-rgb t):
Origin behaviour (wrong powerline separator):
With (setq ns-use-srgb-colorspace nil):
In my experience the separator uses the same color as the text part, so it's perfect but not like a workaround. While non-SRGB solution makes the whole Emacs UI feels lighter and faded (also look at the background above the powerline), there's no reason to recommend it anymore.
The only confusion for me is, Is the whole powerline (both text and separator image) uses Apple RGB but not SRGB?
@darkbaby123 With the workaround, everything in powerline uses sRGB color space, which is the color space usually targeted by the theme authors . The problem arises due to Emacs using sRGB colorspace for everything except XPM image generation, where it uses the default color space. On MacOS, default is Apple RGB color space (due to historical reasons) while it is sRGB on Linux and Windows. So the same triplet of RGB values look different on screen on MacOS, but look correct on the other two OS.
To fix the issue, we can do one of the two things:
(1) (setq ns-use-srgb-colorspace nil) in which case all colors in Emacs are "wrong" but consistent.
(2) Use this patch, in which case all colors are now in sRGB color space. This is done by converting RGB values to appropriate Apple RGB color space values in XPM generation, which are then transformed back to sRGB color space by MacOS.
This problem really needs to be fixed in Emacs, and has been fixed in the Mac port (where we don't require this workaround). In that sense, it is proper to call this "fix" a workaround. When (if?) Emacs upstream fixes the issue or if MacOS changes its default color space, we'd have to turn this option off to get correct colors. I really tried tinkering with Emacs code, but nsterm.m is such a mess that it is better left alone.
Thanks for the report about the new Macbook. The default color space is still Apple RGB if the workaround is still working.
@anuragm Thanks for detailed explanation!
@Arelav finally! thank you for this it should be in the documentation!!