I’ll be the first to admit that I know almost nothing about the professional world of color—specifically, the issues involved in color matching between different mediums. Theoretically, I know it’s vitally important to try to keep the colors consistent between, say, your digital camera source image, the edits you perform in Photoshop, and the final printed result on your color photo printer. That’s theory. The reality in my world is that I snap photos with the camera, tweak them in Photoshop until they look “right” to my eye, then send them to the printer—whose output I’m happy with about 99 percent of the time. In other words, for the most part I pay no attention to color matching at all.
But there is one area of professional color management that I touch every time I get a new Mac or a new monitor—the Color tab of the Displays System Preferences panel. Using this tab, I create a
ColorSync profile for the monitor. For professionals, this means setting it up to insure they’re seeing accurate color throughout the process. For me (and I suspect other users as well), it’s more about making the OS X environment “look right” to my eyes. To me, the standard color profile for OS X is too “washed out,” so I try to darken it up a bit, providing more contrast. I used to go through the Calibrate steps on the Color tab, but then discovered that the various predefined “RGB” options worked well for me—usually the Apple RGB or sRGB Profile options. So for the last couple years, that’s what I’d been using, and I’d been quite happy with it. Keep this background information in mind as the rest of the story unfolds…
In 2005, Apple
released QuickTime 7, which included a new
codec known as
H.264. H.264 offers an amazingly high picture quality without requiring huge data rates or file sizes. As an example, my Canon PowerShot digital video camera shoots 640-by-480 videos in an AVI format. A recent capture of our youngest daughter was just under two minutes in length, and required 186MB of disk space. Although the picture looks great, that’s hardly a usable file size for posting the video on a Web site. Enter H.264. Using QuickTime Pro, I was able to re-encode the clip using H.264 (with the Quality slider set between medium and low) using Best quality (multi-pass) encoding. After a few minutes’ work, the end result is a movie clip whose quality is nearly indistinguishable from that of the original (to the casual viewer, at least), and yet is only 13MB in size. Sounds like a win-win, right?
Well, for most people, it seemed to be. But on my Mac, I was getting some horrendous fading of the H.264 video, as you can see in the image below (click it for a larger (232KB), higher-quality version):
The left half of the image is a frame from an AVI video as shot by the PowerShot camera. The right half is that same frame, taken from an H.264 conversion of the same movie—and using the highest quality settings. Technically, the two sides should be identical. Clearly they aren’t, as the H.264 version is suffering from some severe washout. I first saw this problem shortly after QuickTime 7 was released as a public preview, but didn’t think much of it—“I’m sure this’ll be fixed before it’s released.” Of course, it wasn’t—and even through the latest QuickTime 7 update, I was still seeing this problem.
Making things more frustrating and confusing, however, was the fact that most people who viewed the videos I was making would not see this problem—to them, the movie looked fine. So clearly, whatever was happening was apparently local to my machine. I also didn’t see a huge uproar about this issue on the usual Web hotspots, further cementing the feeling that I had a local problem. And in the overall scheme of things I need to get done, solving the issue wasn’t high on the list—the movies apparently worked well for others, so I just kept putting this issue on the back burner.
Last night, though, as I was trying to work on a large number of PowerShot clips for my family’s blog page, I finally got frustrated enough to go searching for a solution. After digging around in Google for a good bit of time, I think I’ve (mostly) solved the problem. The first thing I found was
this long discussion on Apple’s QuickTime Users mailing list. The discussion there centered around the impact of Core Video,
defined by Apple as:
Core Video, joining Core Image in Mac OS X Tiger, delivers a modern foundation for video services, providing a bridge between QuickTime and the GPU for hardware-accelerated video processing.
In the referenced discussion above, Core Video was singled out as the cause of the washout. I was able to confirm this on my own machine by downloading
NicePlayer, which is a free media player. Amongst its features is the ability to specify which “viewer” you’d like to use to open videos: Core Video, DVD Player, and QuickTime. When I disabled Core Video, the very same washed-out H.264 clip played back perfectly in NicePlayer. QuickTime Player, on the other hand, will always use Core Video if the machine is capable, so I was stuck with the washed out version there. So it definitely seemed this was the problem on my end. But I was still a bit confused, as I have many friends with Core Image-capable machines who had viewed my clips—and none of them had ever complained about the faded colors. So something else was still involved in my machine’s issues; it had to be something other than just Core Video.
As a quick aside, deep down in the discussion list coverage of this problem, someone suggested a method of solving it by setting a black movie mask and a composition blend mode for the clip. While this definitely works (the QuickTime Player playback is no longer washed out), it’s not really disabling the Core Video playback feature. Instead, it’s adding a dark background and blending it with the washed-out movie (at least, that’s my understanding of what those settings do). This, however, causes problems on slower machines—a simple 640-by-480 30 frames-per-second video test I created played back fine on the Mac Pro and Dual G5…but was only reaching about 15fps on my PowerBook G4. Clearly this isn’t a great workaround.
Just as I was about to give up for the evening, I found a link to
this Macintouch Reader Reports page, discussing H.264 export issues. In the final entry, dated May 19, 2006, Christian Kent figured out what was going on and provided an effective workaround. Christian, like me, was using a pre-defined RGB color profile for his monitor, and seeing washed-out video in his H.264 exports. He managed to figure out that it was the pre-made profiles that were causing the problems:
In fact, all of the pre-made profiles were interesting in the way that they caused QuickTime Player to compensate the video to reverse the effect of the profile (with some gamut limitations).
So I had a darker-than-standard color profile, and Core Video was exporting lighter-than-expected H.264 conversions. The solution, as identified by Christian? Just create a new customized color profile using the Calibrate button and the Expert mode option. I did this late last night, then re-ran an H.264 export on the same video shown above. So how’d it come out? Judge for yourself:
As you can see, there’s still a slight fade, but it’s nowhere near as bad as it was (compare the tree on the right side in this image with the one in the first image). I expect I’ll be able to fully eliminate it by just tweaking my custom profile a bit more. Christian sums up the situation nicely in his wrap-up on the Macintouch page:
What needs to be remembered is that sRGB and ColorSync are partly overlapping ” sometimes conflicting ” colour-matching systems; and that ambiguities in the specifications of each can inevitably lead to double-compensations and other bugs. Anyone who has read up on sRGB on the web can find the history of colour matching is a long and unfinished imperfect science, and that successive technologies have been developed that repeatedly attempt to be a more complete end-to-end implementation than the last.
Color is apparently part magic, part science, and part “who knows what the heck is really going on?” I’m just happy that I have (mostly) correct H.264 videos once again.