Michel Fortin

Introducing Black Light 3

2023-12-15T08:30:00-05:00

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.

Brighter than White — EDR on Macs

2020-12-05T17:05:00-05:00

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:

[Your browser does not support displaying this video]

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.

macOS Big Sur and M1 Macs

2020-11-11T21:15:00-05:00

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.

Gamma Control, Black Light, Black Light Pro, Counterparts Lite, Sim Daltonism and Red Stripe are all ready for Big Sur as they are now.

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.

Sim Daltonism’s purple bug

2020-06-19T23:30:00-04:00

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.

More Hot Keys in Black Light Pro

2020-02-13T14:30:00-05:00

Some people find their display too bright, and some displays are actually too bright. You can dim the backlight of your display, but what if the lowest setting is still too bright? Then you can use Black Light or Black Light Pro to dim the display more… problem solved? Not entirely it seems.

I occasionally get requests for ways to dim the display using global keyboard shortcuts, often known as “hot keys”. In Black Light Pro you can have many effects configured with various dim levels, and you can assign a hot key to each. But wouldn’t it be better to have two keys for increasing or decreasing the brightness? The new version of Black Light Pro is making this possible, and more.

With version 1.2 of Black Light Pro you can now set hot keys to increase and decrease brightness, change the tinting vividness and hue, toggle the invert effect, etc. Those changes will be saved to the current active effect.

If you have more than one monitor, you can apply the same effect on all of them or apply a different effect to each. In the former case hot keys will control the effect for all the screens at the same time. In the later case hot keys will let you to control each screen independently, with one hot key to cycle between them.

Black Light Pro comes with a 30-day trial so you can experience it yourself.

Font substitution and missing text

2019-10-18T22:32:00-04:00

I recently found a bug in my work-in-progress-next-major-version of Counterparts Lite where text in certain languages was not showing up in the text editor. The problem ended up being related to font substitution. If characters from certain languages aren’t showing up in your Cocoa text views, here’s something to check…

The first thing to understand is that no font contains all the characters defined in Unicode. When the text system encounters characters that aren’t representable in the current font, it chooses another font that has the correct glyphs to display those characters.

Every time you change some part of a NSTextStorage object in Cocoa, its processEditing method is called to optimize attribute ranges and fix things that could be incoherent (such as a paragraph style spanning only part of a paragraph). This is also where font substitution happens.

You can observe what processEditing is doing easily by setting a delegate on the text storage implementing the willProcessEditing and didProcessEditing methods. After changing the text, printing the text storage’s content in willProcessEditing will result in this single text section with uniform attributes:

Hello 漢字{
    NSColor = "Catalog color: System textColor";
    NSFont = "\"Helvetica 12.00 pt. P [] (0x7f85d9f60070)
        fobj=0x7f85d9f4c320, spc=3.33\"";
}

And then in didProcessEditing you will see it was split in two text sections with different font attributes:

Hello {
    NSColor = "Catalog color: System textColor";
    NSFont = "\"Helvetica 12.00 pt. P [] (0x7fbdc15a25c0)
        fobj=0x7fbdbec6a0d0, spc=3.33\"";
}漢字{
    NSColor = "Catalog color: System textColor";
    NSFont = "\"HiraginoSans-W3 12.00 pt. P [] (0x7fbdc15b2330)
        fobj=0x7fbdc15adbe0, spc=4.00\"";
}

The font was changed for the characters not representable in Helvetica to ensure they can still be shown. Font substitution at work!

Perhaps however our app wants to control the font in the text view in order to replace whatever style could come from the user pasting some text. Those delegate methods sure seem like a good place to do that, and they are.

It is important to know however that there’s a crucial difference between changing the font in willProcessEdting and in didProcessEditing:

willProcessEditing is called before font substitution. Any font you set while in willProcessEditing will get substituted with an appropriate font for characters not available in the font you choose.
didProcessEditing is called after font substitution. If you change the font while in didProcessEditing there will be no further font substitution, and thus you should make sure the font you set can display all the characters.

In summary, if you have to change the font after the text storage was edited, do it in willProcessEditing and it’ll do the right thing. Don’t do it in didProcessEditing.

It’s also important to note that you can change the font in the text storage without manipulating the text storage directly (such as in textView.font = myFont). The same rule apply: do it in willProcessEditing because if you do it from didProcessEditing no font substitution will occur and you can end up with characters not showing up.

macOS Catalina: Authorize Screen Recording

2019-10-11T22:34:00-04:00

macOS Catalina brings tighter security in various ways. One change is about preventing apps from seeing what’s on your screen. Apps that want to do that now require a special authorization from the user. This includes two of my apps: Sim Daltonism and Red Stripe.

The first time you open the app, macOS will tell you it wants to record the screen and will offer to open System Preferences. Until authorized in System Preferences, all the app can see is your desktop picture.

You can open System Preferences from the alert shown by macOS when you first open the app, which will bring you exactly at the right place. Otherwise, you can go there by choosing System Preferences from the Apple menu: from there, open the Security & Privacy pane, choose the Privacy tab, and select the the Screen Recording category.

You will see a list of apps that requested the ability to record the screen. Check the ones you want to authorize. You might be prompted to quit the app so the setting takes effect; this is unnecessary in the case of Sim Daltonism and Red Stripe but might be needed for other apps.

Black Light Pro 1.1 on the App Store

2019-09-17T17:00:00-04:00

The short version of this post is that Black Light Pro 1.1 is out, and is now available on the Mac App Store. If you’re interested in the story behind this, read below.

Last year when I was developing Black Light Pro, I intended it to be available on the App Store as well as directly from my website, like all my other apps. Things don’t always work as intended though. The App Store is famous for its strict sandboxing requirements, disallowing access to many functions of the OS in the name of security. One of these is for changing the current color profile of the screen.

There’s two ways really the operating system lets us affect how colors are rendered on a screen:

You can directly change the display transfer table and it’ll have an instantaneous effect. It’s a bit fragile too because many things can reset this transfer table unexpectedly, like the display waking from sleep, plugging a secondary screen, other apps quitting, etc.
You can change the color profile of a screen. The color profile tells many things about a screen, one of them is the display transfer table the operating system should use. When the transfer table applied in method #1 gets reset, it becomes whatever is in the screen’s color profile. This makes the profile the ideal place to apply a long-lasting effect.

In Black Light I always used method #1. For Black Light Pro I wanted to use #2 to make the effect more robust by changing the screen’s profile while the app is running. This is better because it avoids the flashes of “normal” colors that happen whenever the transfer table is reset.

So, the sandbox got in the way. Since you can’t change the color profile of a screen from a sandboxed app, that feature was out for the Mac App Store version. The app would still work inside the sandbox, but changing the profile wouldn’t. I didn’t want to remove the feature (because it truly makes things better), and I did not want to make one version sandboxed and the other not for various reasons. In the end, I released it only on my website.

A few months ago, it came to my attention that Black Light Pro would sometimes crash unexpectedly. This would manifest by the app disappearing from the menu bar and scheduled effects no longer triggering. From the crash logs it looked related to the code for changing the profile.

I couldn’t figure out exactly how to reproduce it, but it seems like a reference counting problem with a value returned from one of the function calls needed to change the profile. Not sure if I could do something about it (the bug could be on Apple’s side), I decided to move the profile-management code to a separate process: if that separate process crashes, then a new one could be re-spawned and continue where the other left. It’s fault-tolerant now.

This complicated bug fix has an interesting effect: it makes it possible to sandbox the main process. If the main process is sandboxed, that means it can go on the Mac App Store… as long as the profile management process is not included. And that’s what I’ve done for 1.1.

I’m a bit proud now to announce Black Light Pro is now available on the App Store. Also the color profile functionality is more robust now in the direct version.

Gamma Board 1.3: Presets

2019-09-02T19:55:00-04:00

There’s a new version of Gamma Board out today with new features helping you color-manage screens from a distance. Three highlights:

Presets are a new feature allowing you to save and restore settings for screens and groups. Tap the sliders icon in the setting panel to create or apply a new preset.
Propagation of a group settings to all the screen settings. Tap the group icon at the top of the group settings and you’ll be offered to merge the group settings into each individual screen settings. You can also reset individual settings for all the screens in the group in the same way.
The document browser has been changed to use the standard iOS document browser (if running on iOS 11 or later). You can now save set documents on iCloud, locally on the device, or using other storage services.

Gamma Board 1.3 also includes a couple of minor bug fixes.

You can download it from the App Store for $79.99 USD — a 20% reduction. Or request a custom branded version for your organization.

Gamma Control 6.3: Color Profiles

2019-09-02T19:54:00-04:00

One feature that has been requested for a long time in Gamma Control is the ability to create a color profile. Now it’s there. If you choose a color profile in System Preferences, in the Screens pane, the operating system takes charge of applying the gamma correction curve you’ve chosen in Gamma Control.

So in Gamma Control 6.3 you can calibrate your screen, export a profile, select it in System Preferences, and never have to open Gamma Control again. Yeah!

This feature is mysteriously unavailable during the free trial though, so you’ll need a purchased copy of the app.