Black Light is a macOS app to apply color effects on a screen. From its original task of inverting the screen, the app slowly expanded and added more settings over the years. And with Black Light 3, possibilities in term of effects and how to trigger them have expanded a lot.
New settings in Black Light 3 include Clipping, which encompass underexposure and overexposure, and Gamma Shift, which gently pushes grays towards white or black.
But more important is that the app will store many effects and you can easily switch between them. Or Black Light can switch automatically based on time or which app is frontmost.
Effects can also hold separate active and inactive configurations. How the inactive one works depends on what you choose in the app’s settings. Black Light can track inputs and after a certain time switch to the inactive configuration, but it can also track the location of the mouse pointer and make screens inactive whenever you move your mouse to another screen.
If you have more than one screen, the choosen effect will apply to all of them. But each effect can hold a different configuration per secreen if you choose so.
Many things in this new version of Black Light are comming from Black Light Pro, but have been repackaged in an way that is easier to use. This also marks the discontinuation of Black Light Pro, which for the most part has been merged into Black Light.
Black Light 3 is available for $18.99 USD directly on this website and via the Mac App Store. A free 30-day trial is also available.
Stu Maschwitz observes that Apple has enabled the display HDR content on many older Macs models. Until now I thought this was a feature only for the very pricy Apple XDR Display hardware, but it looks like support also exists for the far more “ordinary” screens of some older Macs.
I downloaded the two HDR clips he shared and did a little experiment. And I think there’s one detail wrong in this paragraph from Stu’s blog:
Think of it this way: This EDR display philosophy is so important to Apple that they are willing to spend battery life on it. When you map “white” down to gray, you have to drive the LED backlight brighter for the same perceived screen brightness, using more power. Apple has your laptop doing this all the time, on the off chance that some HDR pixels come along to occupy that headroom.
I’m pretty sure it’s wrong to say they’re making the LED backlight brighter all the time. My observations support that the display brightness and color mappings change dynamically when some HDR content appears on screen. Those are reverted back to normal once the HDR image disappears. So no compromise on battery life until you put HDR content on your screen: the display is only made brighter while HDR content is visible.
Here’s how I came to that conclusion.
First of all, I have a late 2014 Retina 5K iMac, which appears to support EDR. (Wow!)
When I select one of Stu’s HDR video with the Finder in column view, it shows a preview in the rightmost column. When the preview first appears on screen, it is rendered normally, in SDR. It then progressively becomes brighter over the span of one or two seconds. Brighter than the surrouding white. This appears to be the EDR system firing up: slowly cranking up the display brightness at the same time as it darkens the standard white point for everything but the video. Those two operations are done in tandem so well that you don’t perceive any change on screen other than the video becoming brighter.
There are however some small side effects you can observe. I’ll take my free app Sim Daltonism to do some observations. Set it so it does not filter anything (the “normal vision” setting), and all it’ll do then is continuously take a screenshot and render it its window. As EDR is firing up you can observe those screenshots of the video in the window slowly becoming overexposed. That’s because Sim Daltonism screenshots comes from an EDR image that gets truncated to SDR. Here’s what it looks like:
Another thing you might notice while EDR is activating (or when it’s shutting down) is occasionally some of the frames in Sim Daltonism can be black, sometimes only for some windows in the screenshot. It’s as if the window server fails to produce a screenshot during the process of activating or shutting down EDR.
Note that for EDR to work (on this hardware) you can’t have your screen at full brightness. And thus when at full brightness, Sim Daltonism will not show you overexposed screenshots and you won’t see any black glitches. EDR cannot do anything at full brightness on this monitor, so there are no side effects so see.
On macOS Big Sur, when in dark mode, I noticed some white text labels are sensitive to EDR. (This looks like a bug.) When the video becomes visible on screen and EDR activates, those white text labels will slowly brighten at the same time as the video. I’ve located two of those labels for now: Safari’s active tab text (while the window is frontmost), and Gamma Control’s text label below the tabs (when the palette is set to translucent dark appearance). There’s also the checkmark for checked items in menus that appears affected. When you close the window with the video, they’ll slowly fade back to normal white. It can be a bit hard to see though.
Another Big Sur issue: running an app that tweaks the gamma curve can break this EDR system temporarily. If you open and then quit Gamma Control, or do the same with Apple’s Calibration Assistant, the image of the HDR suddenly lose its EDR-enhanced brightness. It’ll regains its brightness the next time you open an app (any app). At least it does that on my iMac. If you’re at Apple, see FB8929660.
This has been tested on macOS Big Sur 11.0.1 and Catalina 10.15.7.
As the new version of macOS is around the corner and the first Macs with a new processor type will be shipped soon, I want to state that my apps are already fully compatible with both. Here’s the current state of things and what’s to expect in the near future.
macOS Big Sur makes many changes, visual ones especially, but those changes aren’t causing any problems to my apps.
The M1 chip in the new Macs uses a different instruction set than Intel processors in the previous models. But macOS can run most apps built for Intel by translating them using Rosetta. As a user, this happens without you noticing anything. I already tested all my apps and can confirm they all run fine using Rosetta.
There’s one thing I couldn’t verify myself in advance though: whether the new hardware supports setting the gamma correction curve. This is needed for Gamma Control, Black Light, and Black Light Pro to do what they do. I’ve been specifically told it should work. And given that some parts of macOS also depend on this I’m not expecting any problems.
I plan to update all my Mac apps in the coming weeks. They’ll get a nice new icon for Big Sur and some will gain interesting new features. They’ll also become universal so they can work natively on M1 without using Rosetta.
Back in 2016, I converted the filter algorithm in Sim Daltonism 1.x to OpenGL shader code so it’d run on the GPU and have better performance. This also made it possible to bring it to iOS as a real-time filter for the camera. A bug slipped through however.
On a filtered color wheel we can observe that a region of deeply saturated blue becomes purple. This makes no visual sense: purple light is blue light + red light, and this purple area showed up even for protanopia (no red cones). This also wasn’t happening with version 1, and it wasn’t happening on the Color Laboratory on which Sim Daltonism’s filter algorithm is based.
I dug up the code for version 1 and tried to find differences. I did not have much success at finding accidental algorithmic differences. So I finally tried to clamp some values within the 0…1 range they were supposed to be in; theoretically the result of the calculation shouldn’t be out of this range but that doesn’t account for rounding errors in floating point calculations. GPUs are quite fast, but they sometimes sacrifice precision to achieve that speed. And that did the trick.
So now there’s a new version of Sim Daltonism with a corrected filter on both Mac and iOS. And I want to thank Lisa Charlotte Rost for signaling this bug after comparing with other color blindness simulation tools.
