Chrome and Electron render colors differently

[teleclimber]

• Electron version: 1.7.8
• Operating system: Mac 10.12.6

Expected behavior

Colors set in CSS should render the same in Electron as they do in Chrome.

Actual behavior

Colors look different. See image:

How to reproduce

Set the background-color of an element of an Electron app to rgb( 126, 183, 253 ). Compare the color rendered by Electron to the same color as rendered in Chrome.

In your Electron app do not set vibrancy, and do not set background color via the BrowserWindow API.

Notice as well that if you take a screenshot and draw a rectangle of the same RGB in a drawing program it will match Chrome's color, not Electron.

Consequences

Please note this is not a trivial issue for those of us using Electron to create apps intended for design. Something that looks "right" to the user in an electron-based design app can look subtly different and "wrong" when they export their design and open it in a regular browser.

Thanks :)

[teleclimber]

Confirmed that this problem does not occur on Windows:

[thomastvedt]

same problem here..

[esprehn]

This sounds like color profile support not being hooked up properly, though I'm not sure how. ccameron (at) chromium.org can probably help.

[ccameron-chromium]

Chrome as of 61 started (finally!) respecting the color profile that the OS specifies on all desktop platforms. As a consequence, CSS specification of the color ##ABCDEF, when drawn to the screen, will not necessarily be ##ABCDEF -- it will depend on the monitor that you draw it on.

If you don't want this behavior, the following document shows how to delete your OS color profile settings (which gets you back to the old behavior), and also how to tell Chrome to ignore your OS color profile settings:
https://docs.google.com/document/d/1jMokB_OBkZVELu22li8vnHxAUoL1eGnLedP-1Gttv40/edit

[Augus]

same problem here...

[codebytere]

As chromium 61 is now in the latest master, this problem should be resolved. I'm going to go ahead and close this, but please feel free to @ me if it should persist.

[deanylev]

@codebytere doesn't seem to be fixed. Here is the color #1D89CB. Left is Electron 2.0.0-beta.7, right is Electron 1.6.6, and bottom is Chrome 66. All are totally different.

[teleclimber]

Not sure. It might be fixed. Here is what I get:

Method: set background colors on Electron and Chrome via devtools. Screenshoted and opened in Sketch to add a control rect using the same color. I opened Electron by clicking on it after downloading. I did not set any flags.

@deanylev any ideas how you got the result you got?

[Skeukry]

On Linux, in electron v1.8.6 colors are correct, but in v2.0.0 they are off.
By correct I mean IntelliJ, Inkscape and Chrome 66 render this way.

[ryran]

For the record, one more Linux user (Fedora) here who has the funky colors in Electron 2 (after updating atom to latest beta).

[jasonrudolph]

As chromium 61 is now in the latest master, this problem should be resolved. I'm going to go ahead and close this, but please feel free to @ me if it should persist.

@codebytere: Based on the recent comments, and the reports we're seeing related to Atom using Electron 2.0 (atom/atom#17356), this problem seems to still be alive and well. 😬 Would it make sense to reopen this issue?

[redders6600]

@codebytere - 2.0 introduced problems for us.

I think part of the issue is that we don't seem to be able to control the chrome flag that existed in chrome 61 (enable-color-correct-rendering) - see screenshot from virtualbox with chrome 61 installed below.

I have tried both of the below but neither seem to have an effect.

app.commandLine.appendArgument('--enable-color-correct-rendering=disabled');
app.commandLine.appendSwitch('--enable-color-correct-rendering=disabled');

Am I doing something wrong? Is there a way to see what flags are set for the renderer processes?

[redders6600]

To answer my own question (I think?) - I think I should have been doing:

app.commandLine.appendSwitch('enable-color-correct-rendering', 'disabled');

But also I don't think this will work, because it appears these switches are blacklisted?

I'm pretty sure there are quite a lot of electron-based applications where people will want to use these switches - is there any chance we can update this?

[codebytere]

I'll check into this!

[ccameron-chromium]

app.commandLine.appendSwitch('enable-color-correct-rendering', 'disabled'); is not a valid flag

There is no "disabling" color management in Chromium -- you can tell Chromium to ignore your system's color profile by specifying --force-color-profile=srgb

[ccameron-chromium]

This document discusses the underlying issue
https://docs.google.com/document/d/1jMokB_OBkZVELu22li8vnHxAUoL1eGnLedP-1Gttv40/edit

I think that the issue that electron hit is the the fact that the flags for "I don't want to think about color" changed from Chrome 61->62 -- it's discussed in the last paragraph of the doc.

Let me know if you have any follow-up questions.

[quadband]

using app.commandLine.appendSwitch('force-color-profile', 'srgb'); corrected the issue for me on Windows.

[ccameron-chromium]

The "force-color-profile" command line option will be supported forever (that should have been the supported scheme starting in Chrome 61, but I messed up there).

[redders6600]

Also confirm this fixes the problem on Linux. I had assumed because electron 2 uses chrome 61 that the force-color-profile option wasn't available (I thought that was 62 onwards). Thanks for the pointer!

[jasonrudolph]

@ccameron-chromium: Thanks for sharing the context on this change. 🙇

I've read the Google doc and all the documents that it links to, and I understand that the new (Chrome 61 and later) color rendering is considered the correct behavior, and that the confusion is due to people being used to the wrong behavior (from Chrome 60 and earlier).

I'm trying to reconcile that philosophy with the behavior described in this post from the Atom forum, comparing Atom 1.27.1 (using Chrome 58.0.3029.110) and Atom 1.28.0-beta1 (using Chrome 61.0.3163.100). (Please see the screenshots below.) Is there something about color profiles that would make this the expected/correct behavior?

Atom 1.27.1 (Chrome 58.0.3029.110, Electron 1.7.15)

Hex value in CSS matches rendered hex value.

Atom 1.28.0-beta1 (Chrome 61.0.3163.100, Electron 2.0.1)

Hex value in CSS matches differs from rendered hex value.

[ccameron-chromium]

The color picker should be returning sRGB colors.

There was a bug with the color picker not returning sRGB colors, but it was (mostly) fixed in Chrome 61.0.3163.71:
https://bugs.chromium.org/p/chromium/issues/detail?id=756329

If you're using the "disable color correct rendering" flag, you may end up not opting out of the display->sRGB conversion there, which will get you non-sRGB values (not what you want). So, for Chrome 61, if you're disabling color correct rendering, you want not to be using that code block.

After Chrome 61, none of that applies anymore.

[yourfavorite]

Thanks @poiru for your previous work on this and for taking another look.

And as one more note to anyone battling with this, I highly recommend that you check your colors on a handful of different screens because you actually might not want to disable this feature. I spent entirely too long looking into this tonight only to realize that while I liked the fixed colors (color correct rendering disabled) on my Acer monitor better, it made the colors on my Macbook Pro look awful. So after all of this, I'm going to revert back to the default and not use this switch as it seems to be the lesser of two evils.

If you'd like a good explanation on color-correct-rendering, I recommend checking out this thread on designer news where @marcedwards has several great comments (not sure how much may or may not be out of date): https://www.designernews.co/stories/86411-google-chrome-rendering-colors-inaccurately

[seebs]

At least in the case where this was biting me (Discord on Linux), the impact of the "color-correct" rendering was that it desaturated things badly and looked awful. I don't care about "a handful of different screens", as a user, I care about the screen I actually have. I got a fancy S-IPS display with good color calibration because I wanted to be able to display a broad color gamut well, and have highly saturated colors stay highly saturated. This feature, for me, is basically emulating a ten-year-old TFT display, and I am pretty sure I never want it.

[marcedwards]

@yourfavorite Yep, the situations is pretty much the same as when I commented on Designer News. Safari and Chrome treat CSS, SVGs, and untagged images as sRGB and convert them to the display’s profile. Firefox still shows CSS, SVGs, and untagged images in the display’s profile without conversion (looking too vibrant on wide gamut displays). Electron should definitely follow Chrome’s default behaviour.

@seebs CSS, SVGs and web colours in general are sRGB, as per their spec. This isn’t just about colour appearance being preserved across different devices, it’s also about having specs and behaviour that can be reasoned with. You’re obviously welcome to set up your computer however you want, but in terms of defaults for Electron, given the current market and trends, there is no sensible path forward without colour management.

[seebs]

Since when does "color management" mean "corrupt every color badly and be unable to display many colors at all"?

I am all in favor of color management, but corrupting colors so that a swatch of "#32dad3" is displayed as "#82dad3" is not working color management. Maybe the real problem is "the color management being used is mind-numbingly bad". I'm pretty sure other things I use have color management that allows some kind of consistency.

Thought experiment: I have "color management". I have an app running Electron. I screenshot part of the app's UI. I post the screenshot in the app. Should the screenshot as displayed by the app at least resemble the UI it's next to? I think it should, and right now, I get that if I force srgb, and I don't if I don't force srgb.

Maybe just to clarify: Is that the expected/desired behavior? If it's not, is there a fix more nuanced than "disable the malfunctioning component entirely"?

[marcedwards]

@seebs The entire point of colour management is to preserve appearance, by altering the values. That’s precisely what it does, and how it should work.

I have "color management". I have an app running Electron. I screenshot part of the app's UI. I post the screenshot in the app. Should the screenshot as displayed by the app at least resemble the UI it's next to?

Yes, the screenshot should match the UI. However, it’s entirely possible and likely that other parts of the chain aren’t working as they should be. That’s one issue with colour management — everything needs to be behaving, or it won’t work.

I can think a reason why your situation could be as you describe. If the screenshots you’re taking aren’t embedding the ICC profile for your display, they’ll be assumed to be sRGB (the standard behaviour in most browsers, OSs, and other tools is to assume sRGB if there’s no profile). That will mean they’ll probably look desaturated, because you’ll have a wide gamut capture being assumes to be sRGB. The intensity of colours will be reduced.

[seebs]

I'm not talking about how they look if I display the screenshot. I'm talking about the pixel values stored in it.

If Discord is displaying a thing which is #32dad3, and I screenshot Discord, the screenshot contains, for those pixels, #82dad3. This isn't "how it is displayed", but "the raw RGB values stored for those pixels, before any color processing".

And that's very close to exactly what Discord is, in fact, displaying. It's also exactly what Discord displays for the names of users whose role color is #32dad3. And this is sort of where the problem comes in, because I can't imagine how any part of a "color management" system would think that it is more accurately displaying a relatively saturated color by desaturating it so strongly. And for the role colors, it can't be "the color profile embedded in the image". (Come to think of it, I should probably do some more experiments with the role colors to get more data on this.)

Is there any kind of user-visible or tweakable way to get more insight into this? I would love to have better color correction, but right now, it's spectacularly bad. I don't seem to have similar problems with anything but Discord; it may be some weird edge case interaction. I don't see a way to inquire as to what color profile values Discord is using, or where it got them, or otherwise what it thinks it's doing. If I force it to srgb, I get pretty good color reproduction. If I don't, I get something incredibly washed out and undersaturated, with no vivid colors at all. It's seriously like looking at a low-end TFT panel.

[marcedwards]

@seebs I don’t want to derail this thread any further. Please just know that bright red #ff0000 in sRGB is #ea3323 in Display P3. Mapping a colour in one colour space to a colour that looks the same in another colour space will alter the values. I can’t comment about your specific setup or Discord, because I don’t know enough about how it’s all set up.

[poiru]

FYI, I opened a PR to fix --disable-color-correct-rendering in recent Electron versions: #23787

[electron-triage]

see #10732 (comment)

[castroCrea]

On electron 11.2.3 I still have a difference on RGB green

I tried

  app.commandLine.appendSwitch('force-color-profile', 'srgb');
  app.commandLine.appendSwitch('--disable-color-correct-rendering');
  app.commandLine.appendSwitch('disable-features', 'ColorCorrectRendering');
  app.commandLine.appendSwitch('disable-color-correct-rendering');
  app.commandLine.appendSwitch('--enable-color-correct-rendering', 'disabled');
  app.commandLine.appendSwitch('enable-color-correct-rendering', 'disabled');
  app.commandLine.appendSwitch('--enable-color-correct-rendering=disabled');
  app.commandLine.appendArgument('--enable-color-correct-rendering=disabled');

Any help on this ?

[LeaVerou]

Co-editor of the CSS Color specification here. 👋🏼 A bit late to the party.

There seems to be some confusion in this thread regarding hex colors and color management. In CSS, hex colors should always be resolved in sRGB, per spec. It's not implementation-dependent, and has nothing to do with OS or user settings. It is not that Chrome, Safari and Firefox have decided differently, Chrome and Safari have both changed their behavior to follow the specification years ago, while Firefox still hasn't (though it can be enabled via a config flag, and will eventually become the default).

It is understandable that if someone is only accustomed to specifying color through hex colors, it may be frustrating to them that if these are processed correctly, they cannot be used to specify about one third of their screen’s colors (since most screens today are roughly P3). There are however other color formats in CSS that are not gamut-restricted, such as Lab and LCH colors. And there are Display P3 RGB colors too for those who want to use RGB coordinates.

However, all specified CSS colors are device independent. There is no color format that just throws raw RGB coordinates at the screen, and this is by design. This ensures portability, i.e. that colors specified on my device are the same on everyone else's devices (assuming the device is capable of displaying them). Having a setting that makes CSS colors render incorrectly defeats the purpose, and it's even worse if that's the default value!

[nornagon]

@LeaVerou FWIW I believe some users—Figma and perhaps VS Code—still want to disable color-correction due to https://crbug.com/634542 and https://crbug.com/711107 being outstanding (i.e. that these features aren't controllable in WebGL/Canvas). No idea if that's a correct intention or not but that's the stated reason why @poiru is maintaining a patch for it!

[codingedgar]

On electron 11.2.3 I still have a difference on RGB green

I tried

  app.commandLine.appendSwitch('force-color-profile', 'srgb');
  app.commandLine.appendSwitch('--disable-color-correct-rendering');
  app.commandLine.appendSwitch('disable-features', 'ColorCorrectRendering');
  app.commandLine.appendSwitch('disable-color-correct-rendering');
  app.commandLine.appendSwitch('--enable-color-correct-rendering', 'disabled');
  app.commandLine.appendSwitch('enable-color-correct-rendering', 'disabled');
  app.commandLine.appendSwitch('--enable-color-correct-rendering=disabled');
  app.commandLine.appendArgument('--enable-color-correct-rendering=disabled');

Any help on this ?

@castroCrea did you manage to fix this?

Edit

  app.commandLine.appendSwitch('disable-color-correct-rendering');
  app.commandLine.appendSwitch('force-color-profile', 'srgb');

worked for me for electron v11.0.1

As chromium 61 is now in the latest master, this problem should be resolved. I'm going to go ahead and close this, but please feel free to @ me if it should persist.

@codebytere this is still an issue today

Also, I don't see any of the flags mentioned in this thread documented here: https://www.electronjs.org/docs/latest/api/command-line-switches, can someone please point me to where they are documented?

[castroCrea]

@codingedgar for me adding only

  app.commandLine.appendSwitch('disable-color-correct-rendering');

works on electron from 11 to 15

[LoboTheDark]

It is possible that it is be broken again in 16.0.7? It looks like that if the switch is active, electron converts data and uses sRGB to displaySpace even if the image data are still in displaySpace.

[archfz]

I am using Cypress with Electron 94. The colors are displaying correctly in browser. But once screenshot is taken, using the browser, the colors are washed out. The same is happening with Chrome 98. disable-color-correct-rendering has no effects on this behavior.

On the other hand Firefox 97 displays the colors correctly and screenshots have the same colors as well.

Is it the case that disable-color-correct-rendering doesn't translate to the builtin screenshot capturing tool?

EDIT: This behavior with screenshots in chromium is consistent while running browser outside of Cypress as well.

[archfz]

Correction screenshots from firefox also are off in color, but not that much as from chromium.
EDIT: Correction to correction. Actually the colors of the screenshot from firefox seem to be ok. The OS image viewer confused me and I taught there was a difference (probs this one is also using color correction).

1. screenshot with OS from chromium render
   
2. screenshot from firefox, builtin
   
3. screenshot from chromium, builtin
   

[archfz]

I've dived a bit deeper. The issues with screenshots is not affected in any way by the disable-color-correct-rendering or the force-color-space options. The idea is that:

• if you take screenshot using Page.captureScreenshot command or by running window.webContents.capturePage(), colors will be washed
• if you take screenshot using devtools [ctrl+shift+i] [ctrl+shift+p] and search Screenshot, colors are ok

Now figuring based on this my hunch is that:

1. either electron does some processing in first case
2. or the chromium devtools does additional processing on image before saving, or different params for generation

I've cloned chromium and attempted to find some information about this, but couldn't. Question is where should I open a bug? In electron or chromium. Need the input of someone who can look around in chromium.

[Flashwalker]

It's all about the color profile of the monitor, as mentioned here #10732 (comment)
Disabling this option makes colors the same

Also in Chrome you can play with chrome://flags/#force-color-profile

[krema]

Electron fixed/patched the disable_color_correct_rendering with release v18.3.6.
#35050