Compressor 4.2: Testing Image Quality

One of the problems I’ve seen with previous versions of Apple Compressor are variations in color saturation (chroma) and gray scale (gamma) when compressing files using the H.264 codec. These differences were easy to see when comparing the master file to the compressed image and I’ve written about them in the past.

To fix this, I would increase color saturation and modify the gamma setting during compression. However, as a general rule, you don’t want to make color or gray scale changes during compression.

With the release of Compressor 4.2, and filled with an abundance of curiosity, I decided to test the default compression settings for H.264 compression to see if anything had changed.

NOTE: I’ve written other articles looking at Apple Compressor 4.2 in more detail:

• This article compares the compression speed between Compressor 4.1.2 and Compressor 4.2.
• This article compares video compression speed between a new Mac Pro, 21″ iMac and MacBook Pro.
• This article compares video compression speed between Adobe Media Encoder CC and Apple Compressor 4.2.
• This article compares whether enabling multiple instances in Compressor speeds up compression on either a MacPro or an iMac.

EXECUTIVE SUMMARY

The H.264 codec, as implemented by Apple in the Compressor 4.2 release, generates color and gray scale results that are indistinguishable from the master file.

When the compressed frame size matched the source frame size, no differences were detected between master and compressed files. When the compressed frame size was scaled smaller than the source frame size, small differences in edge detail were noted; however, these differences, in my opinion, are not significant, nor visible to the eye.

TEST SYSTEM

All files were compressed on a new Mac Pro using Compressor 4.2. Three compression settings were created and compared to the source file using the video scopes in Final Cut Pro X:

• YouTube default setting for both 720p and 1080p frame sizes
• MPEG 4 defaults, with the bit rate set to 1500 kbps for both frame sizes
• QuickTime defaults, with the bit rate set to 1500 kbps for both frame sizes

I tried to modify the default settings as little as possible, except for frame size, bit rate and keyframe distance (set to 90). Click the links above to see the compression settings I used. All three used the H.264 codec as supplied by Apple.

Three test signals were created:

• 1080p color bars, created in Final Cut Pro 7 and exported as ProRes 422 HQ
• Gray-scale gradient, created in Final Cut Pro X and exported as ProRes 4444
• Moving gray scale gradient, created in FCP X and exported as ProRes 4444

All files were loaded into Final Cut Pro X 10.2 and measured using its video scopes. As a precaution, I also loaded the files into FCP X 10.1.4, where the scopes showed the same results.

NOTE: All video scope images are stored as PNGs, which is how I captured them from the screen. While I’ve reduced their size for this report, click any image to see it at its full, unretouched size.

UNSCALED RESULTS

Here’s the color bar movie that I used for the first part of this test. Color targets are set to Rec. 709 (HD).

When the compressed results were compared to the source image using the video scopes in Final Cut Pro X, the images were identical. (The top image is the source, the middle image is the YouTube version and the bottom image is the QuickTime version.)

In fact, when I apply a Difference matte to compare these in Photoshop and really crank up the gain this is the result: virtually identical patterns except for very minor variations in the trace route.

SCALING A 1080p IMAGE TO 720p

Reducing the size of an image can create a wide variety of problems, the biggest of which is how to accurately describe the edge of an object.

Here’s our 1080p source image, scaled to 720p in Final Cut Pro X. Notice the small artifacts during the trace? These are caused by modifications to the edges of objects in the frame as they are resized.

All three compressed versions showed exactly the same results, as illustrated here in the MPEG-4 version of the clip. While clearly noticeable in the Vectorscope as increased saturation, look at the Waveform Monitor and you see a small bit of “waviness” in the vertical lines representing the edges of the color bars. As I looked at the image in the Viewer, I could not see these artifacts at all.

COMPRESSING GRADIENTS

The next test was compressing a gradient, created in Final Cut Pro X representing every shade of black, white and gray that a video image can contain.

All three compressed versions were identical to the source, as you can see here from the QuickTime compressed version.

When the image was reduced in size, there was no difference in how gradients were compressed. This image is the source file set in a 720p Timeline.

This is the YouTube compressed file, reduced to 720p and displayed in the same Timeline.

COMPRESSING MOVING GRADIENTS

The last test, which is impossible to reproduce in print, was animating a gradient so that the grayscale of every pixel changed from one frame to the next. Basically, what I did was create a gradient, then moved the white from the left to the right edge, while moving the black from the right to the left.

All three compressed versions displayed no significant differences when compared to the master file using Final Cut’s video scopes.

SUMMARY

Frankly, I’m very impressed!

I’ve always been a bit wary of the image quality when compressing files using the H.264 codec in Compressor. But, the results of these tests show that Apple has made major improvements in its implementation of H.264. So much so, that if you don’t change the frame size of your source image during compression, and assuming you don’t materially modify Apple’s compression settings aside from data rate, your compressed images should virtually match the source.

Nice job, Apple.

---

Bookmark the permalink.