Chrome and Electron render colors differently #10732
Comments
|
Confirmed that this problem does not occur on Windows: |
|
same problem here.. |
|
This sounds like color profile support not being hooked up properly, though I'm not sure how. ccameron (at) chromium.org can probably help. |
|
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: |
|
same problem here... |
|
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 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. |
|
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? |
|
On Linux, in electron v1.8.6 colors are correct, but in v2.0.0 they are off. |
|
For the record, one more Linux user (Fedora) here who has the funky colors in Electron 2 (after updating atom to latest beta). |
@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? |
|
@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 ( 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? |
|
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? |
|
I'll check into this! |
|
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 |
|
This document discusses the underlying issue 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. |
|
using app.commandLine.appendSwitch('force-color-profile', 'srgb'); corrected the issue for me on Windows. |
|
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). |
|
Also confirm this fixes the problem on Linux. I had assumed because electron 2 uses chrome 61 that the |
|
@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. |
|
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: 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. |
|
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"? |
|
@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.
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. |
|
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. |
|
@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. |
|
FYI, I opened a PR to fix |
|
see #10732 (comment) |
|
On electron 11.2.3 I still have a difference on RGB green I tried Any help on this ? |
|
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! |
|
@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! |
@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
@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? |
|
@codingedgar for me adding only works on electron from 11 to 15 |
|
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. |
|
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. On the other hand Firefox 97 displays the colors correctly and screenshots have the same colors as well. Is it the case that EDIT: This behavior with screenshots in chromium is consistent while running browser outside of Cypress as well. |
|
Correction screenshots from firefox also are off in color, but not that much as from chromium.
|
|
I've dived a bit deeper. The issues with screenshots is not affected in any way by the
Now figuring based on this my hunch is that:
I've cloned |
|
It's all about the color profile of the monitor, as mentioned here #10732 (comment) Also in Chrome you can play with chrome://flags/#force-color-profile |
|
Electron fixed/patched the |
|
This has caused me heartaches, I'm using cypress |
|
I encountered this issue with the latest Electron, alongside a recent Chromium, on linux (Debian testing). The application is rendering with WebGPU with a Vulkan back-end. Chromium on the left, Electron on the right: I found that forcing srgb colour profile worked around it: app.commandLine.appendSwitch('force-color-profile', 'srgb'); |
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
BrowserWindowAPI.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 :)
The text was updated successfully, but these errors were encountered: