New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiled emacs with srgb, separator colors are wrong #54

Closed
LeoLionel opened this Issue Feb 25, 2014 · 25 comments

Comments

Projects
None yet
@LeoLionel

LeoLionel commented Feb 25, 2014

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!

powerline-srgb

@deftsp

This comment has been minimized.

Show comment
Hide comment
@deftsp

deftsp Feb 25, 2014

I have the same problem. on OS X 10.9, emacs-bzr-version: 116475.

deftsp commented Feb 25, 2014

I have the same problem. on OS X 10.9, emacs-bzr-version: 116475.

@milkypostman

This comment has been minimized.

Show comment
Hide comment
@milkypostman

milkypostman Feb 25, 2014

Owner

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/milkypostman/powerline/issues/54#issuecomment-36007231
.

Owner

milkypostman commented Feb 25, 2014

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/milkypostman/powerline/issues/54#issuecomment-36007231
.

@klobucar

This comment has been minimized.

Show comment
Hide comment
@klobucar

klobucar Jul 29, 2014

Same problem +1 to a solution

klobucar commented Jul 29, 2014

Same problem +1 to a solution

@rymndhng

This comment has been minimized.

Show comment
Hide comment
@rymndhng

rymndhng Jul 29, 2014

same still have problem!

rymndhng commented Jul 29, 2014

same still have problem!

@milkypostman

This comment has been minimized.

Show comment
Hide comment
@milkypostman

milkypostman Jul 31, 2014

Owner

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)
.

Owner

milkypostman commented Jul 31, 2014

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)
.

@gizmomogwai

This comment has been minimized.

Show comment
Hide comment
@gizmomogwai

gizmomogwai Aug 4, 2014

I have the same problem with emac 24.4.50.1

gizmomogwai commented Aug 4, 2014

I have the same problem with emac 24.4.50.1

@jacobj

This comment has been minimized.

Show comment
Hide comment
@jacobj

jacobj Sep 15, 2014

+1, using 24.4 on OS X. I didn't explicitly compile emacs with srgb but I think it's default in 24.4?

jacobj commented Sep 15, 2014

+1, using 24.4 on OS X. I didn't explicitly compile emacs with srgb but I think it's default in 24.4?

@jackrusher

This comment has been minimized.

Show comment
Hide comment
@jackrusher

jackrusher Oct 27, 2014

+1, 24.4 on OS X.

jackrusher commented Oct 27, 2014

+1, 24.4 on OS X.

@milkypostman

This comment has been minimized.

Show comment
Hide comment
@milkypostman

milkypostman Oct 27, 2014

Owner

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)
.

Owner

milkypostman commented Oct 27, 2014

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)
.

@jupl

This comment has been minimized.

Show comment
Hide comment
@jupl

jupl Dec 1, 2014

You can turn off sRGB to make the colors look right.

(setq ns-use-srgb-colorspace nil)

Source

jupl commented Dec 1, 2014

You can turn off sRGB to make the colors look right.

(setq ns-use-srgb-colorspace nil)

Source

@qiushihe

This comment has been minimized.

Show comment
Hide comment
@qiushihe

qiushihe Dec 12, 2014

Thanks @jupl that worked for me.

qiushihe commented Dec 12, 2014

Thanks @jupl that worked for me.

@chiangqiqi

This comment has been minimized.

Show comment
Hide comment
@chiangqiqi

chiangqiqi Mar 11, 2015

@jupl This works for me too, but can u basically explain why?

chiangqiqi commented Mar 11, 2015

@jupl This works for me too, but can u basically explain why?

@sellout

This comment has been minimized.

Show comment
Hide comment
@sellout

sellout Apr 28, 2015

Contributor

@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.

Contributor

sellout commented Apr 28, 2015

@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.

@sellout

This comment has been minimized.

Show comment
Hide comment
@sellout

sellout Apr 28, 2015

Contributor

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!

Contributor

sellout commented Apr 28, 2015

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!

@jasonm23

This comment has been minimized.

Show comment
Hide comment
@jasonm23

jasonm23 Apr 28, 2015

Collaborator

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.

Collaborator

jasonm23 commented Apr 28, 2015

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.

@qiushihe

This comment has been minimized.

Show comment
Hide comment
@qiushihe

qiushihe May 29, 2015

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

qiushihe commented May 29, 2015

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

@jupl

This comment has been minimized.

Show comment
Hide comment
@jupl

jupl commented May 29, 2015

@darker0n

This comment has been minimized.

Show comment
Hide comment
@darker0n

darker0n commented Aug 16, 2015

@jupl 👍

kissge added a commit to kissge/.emacs.d that referenced this issue Nov 10, 2015

@geraldus

This comment has been minimized.

Show comment
Hide comment
@geraldus

geraldus Feb 25, 2016

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.

geraldus commented Feb 25, 2016

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.

anuragm added a commit to anuragm/powerline that referenced this issue Jun 24, 2017

Fix broken sRGB colors on MacOS.
Fixes #54.

Adds a custom option 'powerline-broken-image-srgb', which should be
set to 't' to enable the workaround. This is not needed on Emacs-mac
port, or when Apple RGB colors are used by setting
'ns-use-srgb-colorspace' to nil.
@anuragm

This comment has been minimized.

Show comment
Hide comment
@anuragm

anuragm Jun 24, 2017

Contributor

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.

Contributor

anuragm commented Jun 24, 2017

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.

anuragm added a commit to anuragm/powerline that referenced this issue Jun 28, 2017

Fix image colors on MacOS
Fixes #54.

Adds a custom option 'powerline-image-apple-rgb', which should be set
to 't' to enable the workaround. When the option is set, powerline's
XPM images are generated using equivalent Apple RGB colors, instead of
the regular sRGB colors.

This is not needed on the Emacs-mac port, or when Apple RGB colors are
used by setting 'ns-use-srgb-colorspace' to nil.

anuragm added a commit to anuragm/powerline that referenced this issue Jul 8, 2017

Fix image colors on MacOS
Fixes #54.

Adds a custom option 'powerline-image-apple-rgb', which should be set
to 't' to enable the workaround. When the option is set, powerline's
XPM images are generated using equivalent Apple RGB colors, instead of
the regular sRGB colors.

This is not needed on the Emacs-mac port, or when Apple RGB colors are
used by setting 'ns-use-srgb-colorspace' to nil.

@milkypostman milkypostman closed this in #141 Jul 8, 2017

milkypostman added a commit that referenced this issue Jul 8, 2017

Fix image colors on MacOS (#141)
Fixes #54.

Adds a custom option 'powerline-image-apple-rgb', which should be set
to 't' to enable the workaround. When the option is set, powerline's
XPM images are generated using equivalent Apple RGB colors, instead of
the regular sRGB colors.

This is not needed on the Emacs-mac port, or when Apple RGB colors are
used by setting 'ns-use-srgb-colorspace' to nil.
@Arelav

This comment has been minimized.

Show comment
Hide comment
@Arelav

Arelav Sep 21, 2017

@jupl (setq powerline-image-apple-rgb t)

Arelav commented Sep 21, 2017

@jupl (setq powerline-image-apple-rgb t)

@darkbaby123

This comment has been minimized.

Show comment
Hide comment
@darkbaby123

darkbaby123 Nov 19, 2017

@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):

apple-rgb-fix

Origin behaviour (wrong powerline separator):

wrong-separator

With (setq ns-use-srgb-colorspace nil):

non-srgb-fix

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 commented Nov 19, 2017

@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):

apple-rgb-fix

Origin behaviour (wrong powerline separator):

wrong-separator

With (setq ns-use-srgb-colorspace nil):

non-srgb-fix

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?

@anuragm

This comment has been minimized.

Show comment
Hide comment
@anuragm

anuragm Nov 20, 2017

Contributor

@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.

Contributor

anuragm commented Nov 20, 2017

@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.

@darkbaby123

This comment has been minimized.

Show comment
Hide comment
@darkbaby123

darkbaby123 Nov 24, 2017

@anuragm Thanks for detailed explanation!

darkbaby123 commented Nov 24, 2017

@anuragm Thanks for detailed explanation!

tejasbubane added a commit to tejasbubane/dotemacs that referenced this issue Jan 30, 2018

tarsius added a commit to tarsius/moody that referenced this issue Mar 7, 2018

moody-slant-apple-rgb: New function
This is a wrapper around `moody-slant' that manipulates the colors
so that they use the equivalent Apple RGB colors instead of the
regular sRGB colors.  This appears to be necessary because Emacs
on macOS uses a color space for XPM images than for other things.

Usage: (setq moody-slant-function #'moody-slant-apple-rgb).

Re #2.

This is a port of the equivalent hack used by Powerline.
See milkypostman/powerline#54
and milkypostman/powerline#141.

tarsius added a commit to tarsius/moody that referenced this issue Mar 7, 2018

moody-slant-apple-rgb: New function
This is a wrapper around `moody-slant' that manipulates the colors
so that they use the equivalent Apple RGB colors instead of the
regular sRGB colors.  This appears to be necessary because Emacs
on macOS uses a color space for XPM images than for other things.

Usage: (setq moody-slant-function #'moody-slant-apple-rgb).

Re #2.

This is a port of the equivalent hack used by Powerline.
See milkypostman/powerline#54
and milkypostman/powerline#141.
@diego898

This comment has been minimized.

Show comment
Hide comment
@diego898

diego898 Sep 2, 2018

@Arelav finally! thank you for this it should be in the documentation!!

diego898 commented Sep 2, 2018

@Arelav finally! thank you for this it should be in the documentation!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment