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 314 users

Issue metadata

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

Blocked on:
issue 705611

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
Project Member

Comment 75 by, Jul 23

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
I don't think that there's much of a use case for this after Night Light ships (which looks like it's happening in M69). Let me know if I'm missing something.
Labels: -Restrict-AddIssueComment-EditIssue
Status: Untriaged (was: WontFix)
Pasting comment from email:

"Use cases outside of the native night light implementation are: manual calibration of your display, loading ICC profiles for your display, and customized user-space implementations of night light that behave differently than the native implementation.

I have a display that needs a custom ICC profile loaded to be color-accurate. I can only accomplish this on Windows and Mac OS, not Chrome OS."

I think that loading custom ICC profiles is a bit broader than what was initially discussed here. It'd probably be better at this point to have a separate bug that tracks letting users specify custom profiles.
Status: WontFix (was: Untriaged)
support for ICC profiles is being tracked/implemented elsewhere (e.g.  issue 495196 ).  i agree with Dan that it's not really relevant to this topic as this is only about color temp and the night light feature already accomplishes this.
+marcheu@, +mcasas@, +dcastagna@ to assess the impact of giving extensions the ability to load ICC profiles and transform the display colors.
this bug was started & finished as a means to implement a night-light feature.  imo, if people want to expand/support ICC profiles in the extension APIs, please start a new bug instead.  the target audiences are wildly different.
Status: Available (was: WontFix)
The request here is tangential to either ICC profiles or nightlight. The desire is to give third parties a way to deliver functionality above and beyond what nightlight provides.

There are many reasons why this would be challenging and we might not ever be able to deliver it, but we should keep the feature request open.
mmm, no, that's not what comment #0 or follow ups or blocking bugs were focusing on.  it was entirely about the nightlight scenario.

if you want to expand the scope of the bug, then you prob want to change the summary and drop the Blocked on list, and then prob find an owner.  as it stands, there doesn't appear to be any interest in the expanded feature set you're describing.
Chrome OS's night light feature hasn't made this bug obsolete. This bug is about (a) providing extensions the ability to customize Night Light settings, and (b) allowing extensions to go beyond what Night Light can do in order to provide more targeted night-time affordances.

I'm not saying this bug is about opening up arbitrary color profiles, but *we haven't accomplished the core request in this bug* -- namely, letting extensions adjust the color temperature of the screen. I think there's still room to provide an API for f.lux-like software to take advantage of.
"there doesn't appear to be any interest in the expanded feature set you're describing": that's because this bug had Restrict-AddIssueComment-EditIssue until 3 hours ago.

We've removed that label, so external contributors should feel free to explain how they would like to use extensions to adjust the screen temperature for night-time use.
As a member of the public who starred this issue looking for the Night Light feature, I consider this Fixed (Added as OS Feature). Any messing around with extensions would be extraneous.

The ICC profile concern is valid, but there's already a bug for that.
If people want fancy time-based control for Night Light, there could be a extension / user script interface to talk to the code for NL.
> "there doesn't appear to be any interest in the expanded feature set you're describing": that's because this bug had Restrict-AddIssueComment-EditIssue until 3 hours ago.

that doesn't stop any Chromium project members from picking this up and working on it.  external requests don't matter if no one is going to implement it.
Yeah, if you read the initial comment and first replies, the feature request was always "have color temperature adjustment for night time usage, like f.lux", and it was just assumed a long time ago that the best way to achieve this was to add an extension API so that users who wanted this could install an extension to do it because few people wanted it. Now that the world has changed and way more people want this, it got implemented as a native feature, and that's probably enough for the vast majority of users.
I may as well chip in before this gets closed: as a user of Chrome/ium, I would like a way to make Night Light on my Chromebook behave the same as Redshift on my PC (same colour temperatures, same transition times, same gradual transition over a long period). I haven't played around with Night Light enough to tell if this is currently possible, but I suspect it's not.
Night Light allows you to control the start/end times and the color temp.  it's easy enough to turn on the flag in your profile then log out/in and see.

i don't believe there are any knobs to control transition times/length or plans to add them any time soon (if ever).  for reference, Android doesn't have these either.

(ftr, i smooth out the transition period on my Linux laptop, but i can live with the simpler mode that CrOS/Android offer as it gets me 90% of the way there)
I am the co-inventor of f.lux, and I care very deeply about the effects of light on human health. I think supporting third parties in a feature like this is an important way to find out what works, and is an important step for a platform. 

Lighting and bright screens after dark are a public health issue. There are proven links to cancer, obesity, mood disorders, ADHD, and other conditions in the literature from exposure to light at the wrong biological time. These things happen with light levels similar to those from a typical laptop.

So far, none of the OSes are shipping an intervention that lives up to the claims they make about sleep - the interventions are rather small, they do very little, and today, our devices are still keeping us up all night. But since companies like Apple say they may have solved sleep, everyone else now says it too. And the circular problem here is, if you say "good enough" is when your marketing about sleep convinces people there is no problem, then why would you ever do better?

I think this should be about health outcomes, not satisfying a demand for a different UI color. What if you could help reduce teen suicide or reduce cancer or obesity? It would be important to work hard at it, and to validate what you're doing.

To be sure, we surveyed tens of thousands of people to answer if people want reduced eyestrain or if they want improved sleep, and the message from our users is very clear: >90% they want a solution that is effective at improving sleep, insomnia, and mood. People care a lot about these things, more than something that looks nicer.

Meanwhile, we have been connecting our software to lighting systems and buildings, we're adapting the timing to help people adjust to their work hours throughout the seasons, and updating our recommendations about light levels at different times. For instance we're working with people who do shift work schedules, large fleets of machines, connected building lighting, and three separate standards bodies. These are complicated and detailed models with very unique schedules that require a lot of expertise.

But then, if you have a screen at the end of the day that doesn't know about any of those systems or recommendations, you can easily disrupt a teenager's circadian system using one laptop, and *no*, it doesn't matter if you tune the color temperature a little bit.

There is a large movement in the lighting industry to understand circadian timing and physiological outcomes, measuring alertness, ciradian sleep/wake, productivity. It is the major topic at every lighting conference this year. People are taking this seriously, trying to get the standards and numbers right, to pick the right models and schedules. They know these choices will last 100 years, and they're important.

The light levels that screens make are important also, and adjusting them in a beneficial way is not a thing you do simply because someone asked for it. When you're doing this right, you're programming dozens of brain regions in a person's head, not changing the way a UI looks. It is pretty important for people in the tech industry to be aware of what's going on biologically, also, to take this seriously, and I will ask you to remember that users asked for this because we invented it a decade ago.

I think it is important for research in this area to be easier to do, rather than more restricted. And it is also important for third parties to be able to try new things and test them. Calling the demand "satisfied" when the health outcome is not likely to change for millions of people is a pretty serious problem.

The very least that Google could do is to enable (and allow) experts in this field to make progress.

From the Web Platform perspective, we should aim at defining a Web
API, not an extension API because: extensions only work in Chrome-ium,
and in this case it's just a roundabout way of talking to the OS. If
a given API cannot be clearly framed in an OS-agnostic way, it's just
not going the right way. (The only extension APIs that should survive are 
those that are meant to be used from DevTools/telemetry).  With that 
idea in mind, I'd say the place to discuss this API would be the WICG
This isn't about chrome for the web, it's about chrome os, which just
happens to be built with web technology. Waiting for a standard is asinine
when progress has already been made natively. Not to say a standard
shouldn't be pushed for, but, we shouldn't let the lack of one hinder
further progress.

Shading your browser when the rest of your desktop on a non-chrome os
platform is not is a bit pointless.
Michael, have you considered releasing an Android version of f.lux for Chromebooks? (Last I checked, f.lux required root, but other apps don't -- is that necessary for the sort of adjustments we're talking about here?)
Android f.lux already works on Chromebooks, the only issue is, it doesn't
shade the shelf, but that's not a problem with f.lux, I don't think...
Otherwise, it works fine. At least, it used to, now I just use the built in
"night light".
Sorry, I take that back... the one I used is called "Twilight: Blue light filter":
If we're allowing extensions throw up a tinted overlay, we should also allow the screen to be dimmed beyond the "lowest" setting, by using a darkened overlay. Even the lowest backlight setting is pretty bright while in total darkness. Backlight control aside, on an external monitor, Chrome OS can't dim the display... but with Twilight, one can... in effect.
To my knowledge, there is no such API for Android either, unless you can talk to surfaceflinger directly (which is why we need root).

Overlays don't help very much, except for darkening the screen.

If you alpha blend a red rectangle, it reduces contrast by a lot while not changing the intensity of white by even half (which is why we still don't have an overlay app).

If there were "overlays" that could use shaders or matrix transforms, anything is possible, but you would want the platform to support these kinds of things.

Sign in to add a comment