Why the “red equals sign” campaign drives me a bit nuts

If you’ve looked at a social network the last few days, you’ve probably seen the “red equals sign” logo show up, showing support of the marriage equality, currently being debated in the U.S. Supreme Court. While I intended to stay silent about this campaign, now that it has taken off, I can’t hold it in: this red logo campaign is driving me a bit nuts.

Not for any political reason, of course. It’s just… the compression artifacts… they are the visual equivalent of nails on a chalkboard.

The red equals logo uses simple, continuous blocks of pixels, in only two colors. Unfortunately, the most popular image compression technology in the world, JPEG, which was built to compress photographs, turns out to be hideously awful at compressing simple blocks of same-color pixels. It winds up creating weird bands of unintended colors around the edges of such blocks. For example, here is a version of the logo (3,183 bytes), compressed with really low quality JPEG settings (to exaggerate the effect).

Equality, with horrible artifacts

The artifacts become less noticeable, but still present (especially if you are overly sensitive to them, like me), using a high quality JPEG compression (generating a file that is almost twice are large: 5,517 bytes):

Equality, with slightly less horrible artifacts

It gets even worse. Because JPEG is lossy, these compression artifacts get progressively worse as you re-compress the same image repeatedly. So, for example, if you found a JPEG of the red equals on the net, then uploaded to to, say, Facebook, chances are that Facebook recompressed it again, making the artifacts worse.

A different kind of compression—portable network graphics or PNG—is, in contrast, is extremely good at compressing large blocks of same-colored pixels, particularly in a limited color palette. It shows no compression artifacts and, since it is lossless, you can re-compress it over and over with no quality degradation. And, as a bonus, this file is only 1,590 bytes:


In support of the red equals sign, feel free to link directly to the PNG version above (/images/equality.png) in blog posts, avatar icons and so on. Or, copy and distribute at will. Hopefully my server will keep up.

Launching a backup with launchd

Six years ago, I posted about using rsync to backup a web server (many of the difficulties mentioned there have since been fixed). I’m finally getting around to switch from using cron to run that backup to using the new hotness: launchd. This task was made easier by Preston Holmes’ cron to launchd converter.

To summarize the prior post, I have a special user on my Mac named “backup”. The only thing this user does is backup other stuff, such as my web server. This user has a script (shown in the previous post) in ~/Documents/webbackup. I want this script to run at, say, 2:30am as this backup user, even if no one is logged on. To do this with launchd, I first need a file describing the job:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <!-- Write this file to /Library/LaunchDaemons/ -->


While there are ways to run this job using launchctl, if you want it to run automatically, unassisted, even after rebooting your machine, you need to write the file to /Library/LaunchDaemon/com.mycompany.webbackup.plist. Note, that is /Library, not ~/Library, so you will likely need to use sudo to get the file there.

Also note that the name of the file should match the “Label” key in the file, with .plist suffix. Note also that this “Label” is used as a unique id, so if you make more than one of these job descriptions you need to change both the filename and the “Label” key.