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:
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.
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:
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:
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.
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.
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.
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.
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.
NEW & Updated!
Edit smarter with Larry’s latest training, all available in our store.