Prologue: my knowledge in these topics is fairly limited, so please feel free to point out the mistakes or the not-so-clear points, and bear with me for the oversimplicity of the language used.

I was recently caught in a discussion with a bunch of friends regarding the real benefit of using the so-called "blue light filter apps" on our electronic devices, particularly when it comes to smartphones. For those of you who are unfamiliar with this subject, there are several studies that dealt with how blue light affects sleep, by tricking the brain into thinking that it is still daytime (and therefore blocking secretion of melatonin, which in turn induces sleep). You can read more here: [1]

As a consequence, several applications were created to help reducing this phenomenon. The approach is pretty standard: shift the color tones of what's displayed to a (much) warmer spectrum, so that colors are "less blue", the "still daytime" effect on the brain is weaker and the sleep cycle is not disrupted.

There are two ways of doing that. The first one operates at the video driver level, directly controlling the color spectrum of what is to be drawn on screen, typically shifting it to a warmer tone. Another approach, on the other hand, overlays a "trasparently red layer" on top of the screen in order to reduce the blue-ish colors coming out of the display; please note that this is a software-rendered layer, not an actual physical film that is applied to the device.

So, here goes the question. Do these approaches produce the same effect/outcome when it comes to reducing the blue light emission of the display? Is there some kind of difference that stems from having more control on the video driver, rather than simply placing a red overlay?

When looking for an answer, please consider these points: - assume the brightness of the display is set to a fixed level in all possible scenarios of comparison - if you want some examples, take a look at f.lux [2] and Twilight [3]

Screenshot taken from the Twilight app for Android

  • 2
    $\begingroup$ I'm not too sure this is really a question about physics as much as a question about computer functionality. $\endgroup$
    – Danu
    Commented Feb 2, 2016 at 15:41
  • 1
    $\begingroup$ it seems more about physics, given it asks about the light emission itself $\endgroup$ Commented Feb 2, 2016 at 15:47
  • $\begingroup$ What is the difference in both cases? Since in both cases you are changing the emission of the screen (say pixel A will have a different color) it looks to me that the difference will be in the actual algorithm, but you could have the same result by both cases, depending on the tuning of the parameters. $\endgroup$
    – rmhleo
    Commented Feb 2, 2016 at 16:21
  • $\begingroup$ @rmhleo I use f.lux on my laptop and Twilight on my phone. Besides the fact that the former shifts to a more orange-ish tint and the latter to a more red-ish tint, it still looks keener on my eyes than straight-up, normally-saturated display light. What I'm asking is precisely if there is a difference in terms of the approach used. Just what might be an absurd example: what if applying a red overlay does not actually reduce the blue part of the emitted light, for some reason? $\endgroup$
    – Sebastiano
    Commented Feb 2, 2016 at 16:29
  • $\begingroup$ @user36028 I imagine the result of each method is a change on the color of each pixel, so if we pass equal images to each code, each will provide a transformed output where each pixel is changed, probably adding more red and removing some blue in RGB values per pixel. So the difference, if there is one, does not lay on the method, but on the results, since both methods can be tuned to give equal results. So the difference will be in how each code uses daytime and pixel information to generate the conversion matrix for the image, and not on the methods themselves. $\endgroup$
    – rmhleo
    Commented Feb 2, 2016 at 16:35

5 Answers 5


I make f.lux, and I've chosen not to ship an overlay app for Android because I think it is a poor approach. It's hard to watch people say that these approaches are the "same" in any way, but I will try to bring numbers to the discussion, so maybe I will convince you.

Measuring "melanopic response per lux" answers the question: at the same visual brightness level, what's the impact to the melanopic action spectrum? Here's what you see on a Nexus 4 (an LCD panel):

  • Nexus 4 (no filter): 0.93 m-lux/lux
  • Nexus 4 (Twilight at 1500K): 0.83 m-lux/lux
  • Nexus 4 (f.lux at 1900K): 0.31 m-lux/lux

Measuring color temperature on a white page:

  • Nexus 4 (no filter): 7110K
  • Nexus 4 (Twilight at 1500K): 5072K
  • Nexus 4 (f.lux at 1900K): 2122K

For darker pixels, Twilight and other overlays make things brighter, not dimmer. So the more important thing is that overlays dramatically reduce contrast. Again, some measurements:

  • Nexus 4 (native): 937.5:1
  • f.lux 2700K: 425:1
  • f.lux 1900K: 365:1
  • Twilight 1500K (default): 70:1
  • Twilight Bed Reading 1000K: 24:1

Our spectral data for these measurements uses a well-calibrated reference spectroradiometer and is Creative Commons licensed. You can see it here:


Finally (and I hope the numbers explain this), my opinion is that transparent overlays are mostly blue-light theater, and dimming a display is much much better when you can't do a real color transform. I do not want to make screens have lower contrast, because I think it makes them harder to read. Otherwise, I'd have shipped this!


There is the question you asked, and the question you might have asked... and they are slightly different. I will answer both (I had answered the second before you clarified that you meant to ask the first... seems a shame to delete the second answer)

First - the question you asked (about electronically controlling the display properties). There are (at least) three different ways to control the color of a pixel electronically: you can set an RGB value, you can (on some systems) adjust the display properties (gamma, color temperature), and you can bypass the operating system and go straight to the video driver where you control the intensity of the "blue", "green" and "red" channels of the display. Obviously, only if you completely turn off the blue and green channels can you be sure you have only output from the red channels - otherwise, there are intermediate processing steps that control them. In other words, just because you instruct the OS to display a "red" color doesn't guarantee that the blue pixel won't be turned on ever so slightly (because someone had created a color conversion table that requires a little bit of blue to get the red "just right"). That means that only control at the video driver level will guarantee that you only get light from the pixels you want. But that doesn't guarantee that you have no blue light from your display... and that's the crux of my second answer. Read on.

To appreciate the difference between electronic and physical control of the output spectrum (that is, using a physical filter that lies on top of your screen and absorbs some wavelengths), you need to know the spectral properties of the phosphors used in your screen. This differs from one phone to another.

For example, from this page I extracted the following plot of backlight spectrum for three different models of phone (with different display technologies):

enter image description here

Next, you need to know the properties of the filters (inside the display, per-pixel) used to turn this into the RGB channels for your particular phone. These are "notch" filters, but not terribly narrow. The resulting output is the light that reaches our eyes. Again, I found a few spectra that are representative, but not an exhaustive set of all displays (compiled from this page):

enter image description here

If your application turns off the green and blue components, leaving you only red, then you have a well-shifted spectrum with very little blue component (although it's not zero - there is a "bump" at 450 nm). If you only suppress the blue channel, then depending on the display you use, there could still be a significant blue component if you use the iPhone 4s (circled in red on the "green" spectrum: showing that the filter used on the green pixels lets through a significant blue component).

On the other hand, if you use an external (physical) filter overlay, then the properties of the transmitted light are no longer (just) a function of the display - it becomes a function of the physical filter characteristics.

I found a site that describes a lot of physical filtering options - many of them are glasses with different filtering properties. A particularly effective one appears to be

enter image description here

It is clear that a physical filter can be better than video (electronic) control alone, because you can cut the blue component independent of the characteristics of the display itself. Wearing glasses such as the ones shown may be one way to reduce your blue exposure later in the day. It's still a bad idea to be on your phone until you go to bed...

  • $\begingroup$ I guess my question is not specific enough. The "red overlay filter" that I'm talking about is done via software: it is not a physical film that you apply over the display. Or did I misunderstand your answer? $\endgroup$
    – Sebastiano
    Commented Feb 5, 2016 at 15:28
  • $\begingroup$ No - I misunderstood your question. In my mind, a physical filter is a (very good) thing that cuts out the wavelength emitted. If you just change the RGB channel intensity, you will be stuck with whatever spectral "leakage" you have, and over which you have no control electronically. My answer shows that the effectiveness of an electronic solution depends on the actual display characteristics (which vary from display to display). $\endgroup$
    – Floris
    Commented Feb 5, 2016 at 15:30
  • $\begingroup$ I see. However, leaving aside the "leakage", can we say that one approach results in a more aggressive reduction of the blue wavelength emitted than the other? The reason being, taking advantage of the control over the video driver rather than relying on the blending that is done by the operative system itself. (I will update my question to make clear that I'm always referring to software-level filters). $\endgroup$
    – Sebastiano
    Commented Feb 5, 2016 at 15:34
  • $\begingroup$ Yes, if you "hard turn off" the green and blue channels, you can be sure they are turned off. If you specify the color in some other manner than RGB, you allow the OS to "optimize" the output (adjust color temperature of the display etc) which means it may leave more blue in the output. $\endgroup$
    – Floris
    Commented Feb 5, 2016 at 15:36
  • $\begingroup$ It figures. It can't be said, however, that the "overlay filter" is not effective at all. It may be less effective, but at least effective to a point, since you're still somehow shifting the color spectrum to the red tone. Am I correct in this conclusion? $\endgroup$
    – Sebastiano
    Commented Feb 5, 2016 at 15:42

My attempt of answer will be based on my non-specialized knowledge of programming and computers workings, because the links you provide don't seem to give out the details on the workings of the code. I'm a physicist with a non-academic conceptual and practical understanding of computers.

Whatever layers your software might have, the display will react equally under equal input signal received. At some point a final digital dataset (DD) is created and passed to whichever module converts it into electronic signals. So our comparison only cares about the differences before this moment, after which equal DD should yield equal color-brightness response of the display.

If a software works at the video driver level, the above means that the DD is built by it using some input describing the screen content, and using embedded code which takes into account daylight info to render the final DD.

If the software works by "superimposing a filter", the above statement would mean that in the input information sent to the video driver, the presence of the filter is encoded in the input describing the screen content, and the video driver builts the DD without caring about daylight info.

Whatever the specifics of either case, the final result will be a DD which tells each pixel of the display the RGB content and brightness and they will respond in consequence.

Whichever the case, the proper testing of the effectiveness of the method should be measuring and characterising the light emission of the screen (in color-content and brightness). And a successful result should be that the final result, the emission, complies with the adequate color content and brightness found by the studies of the human eye/brain response.

So conceptually it doesn't matter how you build the dataset because of two reasons:

  • Both cases should be able to provide desired screen emission profile, I mean theoretically there should be a set of parameters for each of them, such that both methods can provide equal emission results, whatever these results were to be.
  • If they are to protect your sleep routine, as they promise, they should comply with the same requirements set by optical/brain studies by providing similar screen emission/perception results.

To answer your question

  • Do these approaches produce the same effect/outcome when it comes to reducing the blue light emission of the display?,

it is important to keep in mind the "normalization" hypothesis you make (assume the brightness of the display is set to a fixed level in all possible scenarios), which says that the emission spectrum of the screen in both cases should be normalized (to 1).

In scenario A, the blue part of the spectrum is simply reduced. Because of normalization, the green and red part increase.

In scenario B, the red part of the spectrum is increased (by adding a "red transparent layer"). Because of normalization, the blue (and green) part get reduced. Without the renormalization, this scenario would be silly: your eyes would see the same number of blue photons as before, and production of melatonin would be untouched.

The actual answer depends on the details, but I would say that yes, the 2 approaches can achieve the same result in terms of reducing blue emission.


Disclosure: I got to see your question because one of the replays refers to my article on blue light filters (glarminy.com).

There is one important though, at first glance, subtle difference between approach 1 (f.lux) and 2 (Twilight). It is that approach 2 reduces contrast considerably more than approach 1. I'll get back to this point.

First on blue light reduction: - software "filters" do not really filter anything, what they do is change colors to emit those with lower blue light content - you'd have to measure blue light emissions using the same screen to know for sure which app "filters" more blue light - then it will depend on your settings (both flux and twilight let you adjust the % of blue light they "filter" (see fluxometer for specific data on how much blue light is "filtered" given different f.lux setting) -a pixle emiting red color has the minimal amount of blue in it (see LedMuseum spectral readings of red, blue, green and white screens). Save black, all other colors have higher blue light content. So maybe you could conclude that Twilight takes out more blue light because the filter is red, than f.lux (yellowish filter)... but than you can put on Darkroom Mode in f.lux and it will turn all your whites in black and blacks in red, and you'd probably have difficult time finding an app that could beat that in blue light reduction - though, unfortunately fluxometer provides no data on Darkroom Mode setting. - possibly I've forgotten something?

Now as far as contrast goes this is very important if you spend extended periods of time working with your digital display, buecause low contrast equals eye strain. Check out this snipped from the image you posted above:

contrast reduction

note how in the part covered with the red filter the contrast is much lower. This is because the "filter" is applied uniformly to all collors - the same effect you would get wearing red eyeglasses.

With f.lux contrast reduction is much lower, because it discriminates between pixles with more blue light content and those with lower blue light content. So if you have black text on white background, only the background will become yellowish. The text will stay black, because you can't make a pixle emit less blue light than when it is black. And black on yelowish white is higher contrast than would be yellowish black on yellowish white (or reddish black on reddish white in the case of Twilight).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.