New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 348 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: 0
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature

Blocked on:
issue 705611

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Let extensions adjust color temperature of screen

Reported by, Oct 4 2012

Issue description

Chrome Version     :  22.0.1229.33 (Official Build 154878) beta
OS Version         :  2723.63.0 (Official Build) beta-channel lumpy
Type of computer   :  Lumpy

* What new or enhanced feature are you proposing?

A setting to adjust the color temperature of the device's screen.

Right now the color temperature of ChromiumOS appears to be fixed, and it is a very blue (high temperature) setting. At night, many users prefer to shift their screen's color temperature down to a lower range to allow their eyes to adjust better to low-light conditions. As the sun sets, their screen's blue content matches the outside lighting.

An even better feature would be to automatically set this based on time and geographic location. Several software packages do this at the OS level: and being prime examples. There is also a Chrome extension which attempts to do this:, but the extension has several issues.

1) it's not automated
2) its effect doesn't seem to work as well as native color temperature adjustments
3) it doesn't affect the rest of the OS such as settings and notification panels
4) it slows down rendering of all pages (this is the dealbreaker)

* What goal would this enhancement help you achieve?

I use redshift to automatically adjust all of the screens in my apartment to a lower color temperature at night. At night, my Chromebook sticks out like a (blue) sore thumb. This causes eyestrain, especially if reading long-form text. Much like ChromiumOS's automatic brightness detection, automatic (or even manual) color temperature adjustment would make the Chromebook experience that much more seamless
Status: Assigned
Being a setting I can only see a subset of users useing, this could be an API platform apps provide so somebody could write this extension on the OS level. Over to Rahul to prioritize.

Comment 2 Deleted

Labels: -Pri-2 Pri-3 Feature-Extensions
Adding Sriram (apps) and Peter (extensions) to weigh in.  I don't see this as a high priority for the core platform team, hence bumping to P3.  

However, we do have a pretty distributed process for adding new APIs to the platform in cases such as this (since we can't predict all use-cases). So if someone outside the extensions/apps teams wants to write such an API, go for it.  

Comment 4 by, Jan 11 2013

I think supporting full ICC profiles (and enabling color calibration) would be a good way to solve this problem. Though there would still need to be an API of some sort.

Comment 5 Deleted

Comment 6 Deleted

Bouncing this back to Alex.  From the apps/extensions standpoint, this seems relatively low priority.  However, I could imagine that for ChromeOS that you guys might want to make this happen sooner.  If so, it would be someone on your side of the fence who would need drive it.  If you and Zel aren't interested, just mark it available and we'll leave it open for someone who's passionate about this to pick it up.

Comment 8 Deleted

This is not just about reducing eyestrain or improving user experience - it is actually a potentially serious health issue that more and more people are becoming aware of:

Comment 10 by, Mar 29 2013

I support this feature request.
Zel, is there somebody who would be interested in making this API happen? 

I know quite a few people who e.g. use tools that adjust the temperature based on the day and exposing this API does sound reasonable to me. I agree, it is probably not a super high priority at this point but if somebody is passionate about it.
Labels: M-28
Summary: Let extensions adjust color temperature of screen (was: Adjust color temperature of screen)
Regarding ICC profile support: We should already be shipping correct color profiles (although in different format than ICC) for device's internal panels.  This appears to be the case for Mario, Alex, and Lumpy.  These profiles are loaded at boot via ply-image.

I agree (as a happy user of redshift on Linux machines and as someone who has made changes to support very dim backlight levels on Chrome OS) that adding an API for this should be a low priority.  I'm not sure whether the profile should just be applied in the compositor, or whether we'd want to set it via X (I think that XF86VidMode is maybe disabled now, though), or ...

Comment 14 by, Apr 1 2013

Author of f.lux here. Seems better to expose gamma LUT (at least) as it's pretty general, free power-wise, and what other OSes do. People will want to run calibration software and do other things with it.

We would prefer full ICC or even a global pixel shader for f.lux, but display calibration should be the first priority. It's very hard to make f.lux convincing on a miscalibrated display.
Sent from Mailbox for iPhone
Adding a color transform at the compositor level is fairly straightforward, but will have a fairly high performance cost (need a "render surface", i.e. an extra full-screen compositing pass).

It's worth looking at whether or not we can expose the hardware gamma ramp somehow.

Comment 16 by, Apr 1 2013

Is there a root fragment shader? It would be so cool if you guys did ICC in hardware (e.g. for wide gamut displays) for the whole OS.
Sent from Mailbox for iPhone
@#16: like I said, applying a color transform would need an extra compositing pass that I'd rather avoid (perf/power).
I'd love to make this happen... And that way we could release ALL of the Google apps in "Google Blue" mode, not just GMail.
But to be less "April 1st" about this, I think piman is probably right here: if we have to apply an extra compositing pass to make this happen, then it's probably not worth it.  If we can do it via the hardware gamma ramps, then it's probably right to give it a try.
So, we have the capability to do gamma correction in hardware. For better portability the xrandr API is what you're looking for, not the DRM API. See

That said there is ground work required first. On x86 the gamma ramp is used in a very primitive way and setup at boot and then left alone. On ARM it isn't implemented. On Link we (ab)use the gamma ramp to implement adaptive backlight.

Comment 22 by, Apr 1 2013

You can wrap an api to compose the two pretty easily...

Gamma[x] = userramp[systemramp[x]] 

with some interpolation maybe, assuming the system setting is mostly used for calibration and brightness.
Sent from Mailbox for iPhone

Comment 23 Deleted

Comment 24 Deleted

Comment 25 Deleted

Comment 26 Deleted

Comment 27 Deleted

Comment 28 Deleted

Comment 29 Deleted

Comment 30 Deleted

Comment 31 Deleted

There is a proposal for a DRM color manager:

Might be relevant.

Comment 33 Deleted

Comment 34 Deleted

Comment 35 by, Nov 21 2014

Labels: -Restrict-AddIssueComment-EditIssue -Hotlist-GoodFirstBug
This feature request hasn't gone anywhere, but here's a dev-mode workaround from xx.3nvy.xx@:

"Since I am in dev mode on my chromebook, I was able to install crouton. Within the crouton chroot, f.lux is able to change the color temperature of the entire X server, including the display ChromeOS runs on. Unfortunately I can't seem to get it to run in the native shell, which means I have to run an entire extra window manager, even when I'm just browsing in ChromeOS."

(Removing GoodFirstBug since implementing a new extension API is non-trivial.)
agree, I'm finding this feature more and more essential.

For those who want a solution now and who don't mind looking like some kind of indoor-hunter-dork you can try these:

Comment 37 by Deleted ...@, Nov 30 2014

Dear God, PLEASE create a similar F.lux type APP for the chromebook.  G.lux just doesn't cut it.  A true color temperature modifying APP for the chrome OS would make chromebooks sooooooo much more desirable for those of us that prefer to minimize eye strain late in the evenings.

Comment 38 by, Nov 30 2014

Author of f.lux here: Given the crouton success, sounds like access to a few X APIs would help quite a bit.

For single displays (most chromebooks?), we can get by with xf86vidmode access.
For multiple ones, we use randr, which is more rare.

Comment 39 by, Nov 30 2014

G.lux creator here. I'm just a guy, I am not (yet) a professional web developer. The project as an alternative to f.lux is exactly that; an alternative because I didn't see any other way of getting my screen dimmer. However, my work does not likely represent the limitations of Chrome extensions, as I am a young developer just beginning my understanding of JavaScript. I just put a filter over the page after it loads. I understand that even small changes could help a lot of people, such as having the filter apply during loading so as not to get the bright white screen between pages. I'm not keen to spend any time on the extension if there's going to be a fix at the OS level right around the corner (and like any of us, I've got lots of projects on the go). At the same time, this has been going on for years and I am being bombarded with emails asking for more features.

I would imagine there are short term solutions to improve the Chrome extension. As you know, Chrome extensions like G.lux are inherently open source, but at the same time I've tried to engage invested parties on the public repo to no avail.

Make no mistake, G.lux has thousands of active users, which leads me to believe that this is a big deal for people.  I don't think it's a stretch to say that this will literally sell more Chromebooks and ChromeOS devices on the basis of having the ability to choose screen temperature.

I'm willing to work with anyone who wants to solve the problem, and that doesn't mean it has to be the continuation of G.lux. I just need to know how to proceed, because I don't have a team and I don't feel like I have much support from Google in supporting this community.
To chime in as a user, this is one of the features I miss the most now that I spend a lot of time on my Chromebook. 

It's the only reason I still fire up my 8-year old laptop running Ubuntu in the evenings, because the Chromebook just doesn't cut it for night time. I like my eyes well rested :).

To the G.lux creator above in comment #39, believe me the community is thankful for your efforts, and at least from my side, I'm aware with the limitations you have to deal with.

Labels: Restrict-AddIssueComment-EditIssue
Back to Restrict-AddIssueComment-EditIssue. :-/

An xf86vidmode-based approach would be of limited use due to the freon project.
Blockedon: chromium:348239

Comment 43 Deleted

Labels: M-50
Let's look at this after the ICC stuff comes in.
 Issue 571318  has been merged into this issue.
I would love to do (and see) this but don't have time at the moment -- can we re-triage if there's somebody who would want to pick it up?
Labels: -M-50
A large portion of  bug 495196  has landed, possibly enough to make this work. michaelpg@ you're welcome to put together an API proposal for exposing that to extensions if you want.

It's also worth noting that once the tech in is shipped, Android apps that do this SHOULD work on supported Chrome OS devices. That's not a solution for everyone who wants this, but it might offer a workaround for some people.
Components: UI>Accessibility
Just chiming in from an accessibility standpoint. We really do need this feature on Chrome OS. As a low vision user, I rely heavily on finding ways to reduce the bright blue light on the screen to reduce eye strain, but I need solid contrast so reducing overall brightness is not an option for me. I also personally know 5-10 other low vision users who rely on similar accommodations due to light sensitivity, so I'd imagine this to be a large trend impacting a great number of people (as there are 246 million low vision people in the world). It would be amazing to be able to highlight this to our assistive technology users, perhaps even in accessibility settings. 
Labels: -Pri-3 M-54 Pri-2
Planning to target M-54.

Based on #50 and this now being in the UI team's purview, bumping to Pri-2.
Project Member

Comment 52 by, Jun 17 2016

Labels: Hotlist-Google
Based on recent discussion, I'm unlikely to get to this even as a Pri-2. Albert, is there anyone with cycles to get this started? Or do we want to bump up the priority and make it work?
Labels: -M-54
I'd love to do this, but everyone is spread thin at the moment.  I'll keep it on my plate for now and see if there's a way I can get it unblocked.


Would any of the color profile work being done in the media stack apply here?
 Issue 658567  has been merged into this issue.

Comment 59 by, Feb 15 2017

re #55
Yes, full ICC profile color management is coming to chrome, slowly but surely.
As displays start supporting wider gamuts and HDR, it will be required or chrome will look very bad.


Labels: NewComponent-Accessibility NewComponent-Accessibility-Browser
Blockedon: -348239 705611
EstimatedDays: 0
NextAction: 2017-05-25
targeting deployment in M60 dev. 

PRD: go/cros-nightowl

Labels: -newcomponent-accessibility-browser -newcomponent-accessibility
The NextAction date has arrived: 2017-05-25

Comment 65 by, May 25 2017

Labels: -MovedFrom-28
NextAction: ----
Owner: ----
This bug is about letting extensions adjust the color temperature. If that happens at some point, it might share some of its implementation with the Night Light feature, but it's not the same thing as Night Light.

I suspect that Night Light will satisfy almost all of the underlying demand for this bug. If we don't plan to add an extension API, we should WontFix this bug (or dupe it into a Night Light bug).
This wouldn't be very hard to add on top of the color management being enabled in the compositor in M61.

This feature is also getting to be standard, so we should find a way to enable it on CrOS.
Mergedinto: 705611
Status: Duplicate (was: Available)
The bug that this is duped into is the launch bug for night mode / night light, which will be shipping in M60 in CrOS.
Status: Available (was: Duplicate)
The Night Light launch bug doesn't mention extension support and that's not something that is being worked on for a future release AFAIK.

At the very least, we can expose the CrOS settings to extensions via the ChromeSetting API:


That wouldn't enable anything a user can't already do, it would just make it more convenient to adjust the setting gradually, change on/off times, and so forth.

afakhry/ovanieva: Is this something someone could start on, or are there other considerations/future changes before we can open these settings up to extensions?
The feature was punted to M-61. We need to finalize the implementation first before we expose things to extensions.
afakhry: Is the implementation finalized now, at least to the point where we know which settings we can expose to extensions?
Yes, the feature is currently stable.
Components: -UI

Sign in to add a comment