Sct – set color temperature | Hacker News Reader

Sct – set color temperature

tedunangst.com

150 pointsingve53 comments

Note that the dependencies aren't because of setting the colour temperature, but to get your location information (see geoclue in the list). geoclue has several providers, but a common one for desktop machines is to connect to a network service that does geoip. Consequently most of the dependencies arrive due to that (eg proxies, crypto, glue code for object models to do all that, and some innocent bystanders).

The location information is used so that redshift can alter the colour temperature during the day (less needed) and dusk, evening and night (very needed).

Wait, what? Why does it need to know location? If you want to know what time it is, why not just call localtime()?

It doesn't want to know the time - it wants to know the natural light levels outside. It wants to know the location to know what the light is like outside at the given time.

Thank you, that makes sense.

Because it uses sunset times to change your colour temperature around dusk. Localtime is not sufficient to work out dusk with any degree of accuracy.

Those of us using Redshift are not doing so for a one off colour temperature set, but because it is continually updated through the day and night.

You can tell it your location manually or have it done automatically.

Redshift is open source. It does not have binary blobs, patents, a business model and similar crud that f.lux does. Adjust your paranoia/expectations as needed.

This location-based setting sounds clever, but it's a crappy idea if you live further north than ~60°N. Or do you want your screen to go red at 3pm and stay that way until 10am the next day when it's winter? And then in summer it's red from 2am to 4am?

I use CF.lumen on Android and Redshift on Linux and I have to regularly shift the fake locations I give them in order to have them do what I want. At least with Redshift on Linux I can script it...

Yeah. The point should be helping me maintain the sort of circadian rhythm I want, not the one dictated by Earth's rotation.

Do you think the idea of basing the timing on location is just bad altogether, or could the implementation be improved? Like mention to users above that latitude that they should set their bedtime, and then factor that into the timings.

Hell, I live at 53N and I definitely don't want the circadian rhythm dictated by sunrise/sunset. Sunrise right now is 8:00AM and sunset is 4:35PM. At solstice it'll be almost 9AM and just after 4PM.

At least one of the authors is Danish (~55°N) so they are presumably aware of this to some degree. I am at 37°N and really do want the colour temperature inside to match that outside.

In any event it is open source, so you can change the code as you deem fit :)

”Or do you want your screen to go red at 3pm and stay that way until 10am the next day when it's winter? And then in summer it's red from 2am to 4am?”

Yep, that’s great!

Self-plug for something I wrote some time ago - you can use redshift-scheduler ( https://github.com/spantaleev/redshift-scheduler/ ) to set up a custom schedule (ultimately using redshift to set the screen temperature).

Ah, with an Arch package and everything! Will install, thanks!

>Because it uses sunset times to change your colour temperature around dusk. Localtime is not sufficient to work out dusk with any degree of accuracy.

So, why not just ask for the location instead of bundling 200MB of crap to get it?

The "crap" is primarily from geoclue which supports numerous methods of getting your location. Some of them such as geoip require making network connections. https://en.wikipedia.org/wiki/GeoClue

It would be absurd for Redshift to include its own networking (don't forget proxies and SSL), GPS, and other code. On Linux (Ubuntu especially), all those dependencies are installed by default and used by many other components. "crap" is the last thing to describe it.

OpenBSD doesn't have them by default which is why they show up. Redshift does support specifying your location on the command line or config file. gentoo has use flags where you can explicitly include (eg +geoclue) or exclude (eg -geoclue) components. I suspect OpenBSD doesn't, so it came down to whoever authored their port deciding to use geoclue by default.

It is an entirely reasonable decision. You use this software on personal machines (ie not servers), and people move around. Defaulting to something that usually works right is fine.

You are of course welcome to do a competitor, and show us all how much better it could be :-)

I don't really care either way about this, but to me, seems like a classic case of bloat, where the program is doing too many things at once.

It makes more sense to have a core app that does the basic functionality and can be run from CLI, and then separate out the the various components that perform different duties and require more dependencies etc, in a modular architecture. It's just better software design and you avoid a lot of pitfalls and hassle to end-users and integrators - just like the issue described by the OP.

That's exactly how it is. It does not want to figure out the location itself, so it consults other software, which is optional.

To expand a bit on why the localtime() is not enough, two factors are at play. First, the solar noon can be as much as two hours displaced from the timezone. This is basically time zone vs longitude. Second, depending on time of year and attitude you can go from having no daylight in the winter to no darkness in the summer.

Solar noon details here: http://blog.poormansmath.net/images/SolarTimeVsStandardTimeV...

> Second, depending on time of year and attitude you can go from having no daylight in the winter to no darkness in the summer.

Isn't this a perfect example where using more than localtime() is pointless? Just because it's dark all the time outside you don't want your screen to be red-ish all the time. And in summer you want the effect if you try to sleep, even if the sun is still relatively high.

I actually like that it's "red-ish all the time" because I'd prefer that my circadian rhythm match the outside lighting conditions. My eyes (and most others I know) adjust, and it no longer looks orange (in fact, non-adjusted screens start to look blue). Of course the lights around my apartment adjust too, otherwise the screen would continue to look off.

I generally have a hard time getting to sleep, and most mornings feel like I've been run over by a steamroller, so I don't mind a little red tint if it makes even a tiny difference in the quality of my sleep.

Saying you want your circadian rhythm match the outside light, then adding that you generally can't get to sleep while being steamrolled in the morning, sounds an aweful lot like you're not sleeping in accordance with your biological clock. Are you aware of delayed sleep phase syndrom?[0]? I have the same "issue" and it took me years to find a name for it, so I'd rather throw this at you, even if you knew.

[0] https://en.wikipedia.org/wiki/Delayed_sleep_phase_disorder

Yeah, this is why I was confused.

I can understand wanting the screen to tint reddish when it's 9 or 10 pm, because I should be going to bed soon.

I don't necessarily want it changing colors at 4pm when it starts getting dark here in the winter. At 4:00, I still need to be up for another 6-10 hours.

FWIW, until I went in manually, I was monkeying with f.lux around Daylight Savings switches specifically to make it show up the way I wanted it. 4PM is a good time for it to start for me, because it heads off eyestrain at the pass before the sun starts getting low enough and yet my work time's still ongoing. YM, of course, MV.

This is a valid question, not sure why you're being downvoted.

I almost (but not quite) voted it down. I think it's mostly the tone, especially the "wait, what?" for something that is patently obvious to some people.

And it looks like it includes redshift-gtk to give it graphical controls. Most packages I've used (Fedora, Ubuntu) split them up as redshift and redshift-gtk, and I've only never installed redshift-gtk, despite running a full Gnome desktop.

It could use a single http lookup to http://ipinfo.io instead!

You can do it with a couple of lines of shell script too, using the xcalib utility:

https://gist.github.com/hrj/e9ed0d73d2daaa98b2d2

Been using that for more than an year with great results.

I also have another version of it: https://gist.github.com/hrj/6561271

(this version cuts the green and blue equally)

Cool! Or, warm depending on parameter.

On Ubuntu includes are apparently broken, complaining about strings.h included from Xlibint.h ...

There's probably a yak to shave in that. However, if you're lazy and hit the same problem, you can compile a functional sct by lifting declarations of i and c outside their loops and dropping "-std=c99" from the command line.

I was able to compile it on Ubuntu after moving the X11 includes to the bottom of the list:

  #include <stdio.h>
  #include <strings.h>
  #include <string.h>
  #include <stdlib.h>
  #include <stdint.h>
  #include <inttypes.h>
  #include <stdarg.h>
  #include <math.h>
  #include <X11/Xlib.h>
  #include <X11/Xlibint.h>
  #include <X11/Xproto.h>
  #include <X11/Xatom.h>
  #include <X11/extensions/Xrandr.h>
  #include <X11/extensions/Xrender.h>

I also had to do some fiddling with the includes (removing the `strings.h` include got it working for me. Why is this required?

Historically, including some headers ended up including some other headers automatically, such that the author might not realize what headers the file depends on, because it compiles without them explicitly included. glibc (and maybe gcc and xlib?) have been cleaning this up where possible, slowly over time. So a file that had "correct enough" includes for an older glibc might now be caught not including a header it needed all along.

Or maybe it's a similar situation but actually related to "feature test macros" (see https://lwn.net/Articles/590381/)

Thank you, had the same problem on Debian. This made it work.

Just remove the Xlibint.h include. That's internal Xlib stuff, it's not needed.

Ah, no yak shaving was necessary, cheers.

I've been thinking of using xcalib to invert my display colors to reclaim a sane black background.

My terminal/editor have always been dark background, but eventually I had enough of the web's blinding conventions [0], and installed a browser extension. But it doesn't work as well as it should and I'm thinking a blanket inversion would be preferable.

It seems like xcalib (and associated machinery) only supports a simple RGB LUT though, which means green turns to purple etc. It's unfortunate that it doesn't have the universal approach of LUT->matrix->LUT like a calibratable monitor, so the invert could be done in say HSV space.

[0] White paper makes sense because it's a reflective medium that relies on ambient light. A glaring white background is the wrong choice for an emissive display. Notice how visual art applications (photoshop, maya, etc) default to a grey background and dark color scheme.

The redshift binary can be built without any of the GUI stuff at all, so some of the bloat complaint is a bit over-blown - more a fault of the port provider to not offer the option of a stripped down install perhaps?

Thank you for your work! It amazes me sometimes how simple such powerful tools can become.

> You start by getting information for each Canadian Radio-television and Telecommunications Commission (CRTC)

wait, hold on a minute

Not sure if Ted is Canadian, but it's a joke.

Mention the letters to CRTC to any Canadian and that's what they think about.

The letters CRTC are in some of the function calls.

It's for CRT Controller (probably after the Motorola 6845 CRTC chip that was in the original PC)

Well, maybe the documentation for the function could have mentioned that. Oh no, there was none.

And CRT is short for Cathode Ray Tube.

Thanks for this.

Over the years I've decided the gradual adjustment lat/long bits are really a negative feature. It engineer cool but it's counterproductive to the goal.

I want the monitor dim between 7pm and 630am regardless of time of year so I cronned that into redshift.

Your body clock probably wants the full blue light in the am fwiw.

I'll give sct a try to see if its more pleasing to the eye.

Another potential use case: improved accessibility to mitigate color deficiency.

"Help us Test the Adjustments for Color Deficiency"

http://blog.jetbrains.com/idea/2015/09/intellij-idea-15-eap-...

I was delighted to see this feature. One of those facepalm moments that quickly transitions from "neat!" to "why didn't I think of that?"

Having an OS level system wide setting might be useful.

https://en.wikipedia.org/wiki/Color_blindness

I wrote a small Python utility recently that provides a minimal interface for brightness and temperature: https://github.com/nicholasbishop/xrandr-slightly-fewer-tear...

It doesn't do anything fancy with geolocation, I tend to just tweak the sliders every now and then depending on what my eyes tell me :)

Does it support changing temperature gradually when it's starting to get dark outside? This is one of biggest features of f-lux and redshift I believe.

No, this is just a crude utility, and a first attempt. You could easily slap a shell/perl script around it though.

If you have redshift installed but want to use this instead of xrandr to change color temperature you could run the following as a script:

    redshift -m dummy | while read line;do sct "${line/Temperature: /}";done

This is a nice little idea; I’m cleaning it up for my own use under Linux, and I’d like to release it, but I cannot seem to find a license declaration for Ted’s code.

Anyone happen to know what license it was released under?

I asked Ted, if I was able to upload my version to Github and he allowed me to do whatever I wanted to do with it.

Here it is: https://github.com/faf0/sct

Compiles on Ubuntu 14.04.

Cool, but is there any way we can do this without sacrificing colour precision? Also, the author didn't say if the values in the array are in linear or sRGB colour-space, though I'd bet it's the latter.

Maybe I don't get what you mean, but how could you? These utilities are taking your full 24bit colour palette and intentionally removing some colours.

Don't monitors have colour calibration settings that can be set programatically? So you can change the output light intensity that corresponds to each of 0-255, i.e. change the voltage applied to the crystal at each of them?

Reply on news.ycombinator.com