After spending a few more hours exploring the gamma correction issues on mac and pc, I decided to check out how Apple handles the problem. The following three captures were taken from the Fantastic Four trailer, encoded by Apple’s own h.264 gurus and advertised prominently on their Quicktime website.

Here is the clip as seen on a Mac running the latest version of Quicktime player:

Now, here’s the exact same clip, as seen on Quicktime for Windows:

And, just to make things more complicated, here’s the same clip as seen on VLC (a 3rd party player) in Windows XP:

As you can see, Apple obviously super-saturates their source material so that it doesn’t look too “washed-out” when viewed on PCs. The result is that the colors also look extremely vivid on Quicktime for OS X. VLC has a much better rendering engine than the Windows version of Quicktime, and so the color correction is more accurate.

But what does this all mean? Unfortunately, compressor doesn’t have a simple “saturate” filter. So, for the Fein videos, I had to explore around until I found a combination of filters that produced an image that looked decent on both Macs and PCs. Although it’s far from a perfect solution, I think I’ve arrived at a template that will work reasonably well for now. I color corrected the highlights and midtones on the source by a factor of 18, and increased the gamma to 1.3. This produces an image that looks slightly too saturated on a Mac monitor, but not too washed-out on a PC. This compromise also seems to work reasonably well for digital projectors.

However, it should be noted that the Fein files were originally captured and encoded on a PC. For material captured and encoded on a Mac, no gamma correction should really be necessary (at least in theory). PCs capture analog images with a gamma of about 0.45, and display them with a gamma of about 2.2. Macs, on the other hand, encode at 0.55 and decode at 1.8, which is far more accurate (and which is also, incidentally, why image professionals and CGI studios like Pixar tend overwhelmingly to use Macs instead of PCs). So, in other words, video captured and encoded in Mac OS X is higher-fidelity and far more cross-platform compatible than video captured and/or encoded on a Windows machine.

My recommendation? We should be capturing and encoding everything on Macs. Ideally, material would be captured from a clean source (i.e. DVD) through S-Video (or firewire), encoded in a lossless DV format (such as Motion JPEG or one of the Final Cut Pro codecs), and then transcoded into high-resolution h.264 at something between 800 and 1500kbps.

I thought I might record some of my observations on the various h.264 tests that I’ve been performing over the past couple weeks.

The punch line is this: Apple’s h.264 codec is ok, but its color correction algorithm is horrific. I was able to get x264 (an open source codec) to work in a Quicktime shell and that produces much better color fidelity on a mac. Sorenson’s AVC codec is probably the best in terms of compression ratio. But its color correction is also somewhat off. Curiously, Sorenson’s output looks far better on the PC version of Quicktime than on the Mac version.

1.) MAC CODEC COMPARISONS

The first thing I did was to compare the built-in Apple h.264 (bundled with Quicktime 7) to other similar codecs at the exact same bitrate and resolution (800kbps, 640×272). As you can see, the results were striking.

Here is a high-motion clip from The Matrix encoded in Sorenson 3 (the old Apple standard codec):

Now here’s the same clip in Apple’s h.264:

Notice the fidelity to the original DVD capture, which you can view here.

2.) COLOR MADNESS

I noticed very early on in the testing phase that the different h.264 codecs were not producing qualitatively equal material. They also had different algorithms for handling color conversion – and some did this much better than others. For the Seth Fein project, which involved transcoding highly-compressed WMVs to equally compressed h.264 MOVs, it was important to maintain as much fidelity to the original image as possible. So I performed most of the following tests on a three minute clip from the Fein directory. I made sure the clip was in color and that it had as much action as possible. The clip was originally encoded on Vader in WMV format at 1,000kbps (640×480 pixel ratio). For the tests, I maintained both the original bitrate and resolution.

NB: Notice the difference in color. Ray Liotta goes from normal skin tone to extremely pale and then to extremely tan.

The”raw” WMV file. Apple’s h.264 codec.x264 (open source) Sorenson AVC

*x264 is the obvious winner on the Mac (although you can produce better results on the other codecs by screwing around with the gamma, brightness, and contrast settings in Compressor and Squeeze).

3.) CROSS-PLATFORM MADNESS

So, it turns out that the color correction issue becomes even more complicated once you start moving between Macs and PCs. No only does everything appear brighter on PC monitors (because PC video cards have slightly different gamma standards), but the same content is rendered drastically different depending on whether you are using Quicktime for Windows or Quicktime for Mac OS X.

Here are the exact same clips, captured in Windows XP and displayed in QT for Windows.

The “raw” WMV again. x264 Sorenson AVC

*Notice that Sorenson is the definite winner in this group – even though this is the exact same file displayed on the mac above.

3.) SO WHAT’S THE SOLUTION?

Since Prof. Fein will be editing his clips on Quicktime for Windows, I am tempted to use Sorenson AVC. There are two problems with this approach, however. First, students viewing these clips on Macs will see an image that is far too dark. Second, we only have Soreson Squeeze 4.5 installed on one PC in the rear lab. And when you transcode to h.264 using Squeeze, for some reason it inserts an extra “empty” frame at the start of the file and screws up the Quicktime preview. It seems like a gamma-adjusted x264 is the way to go. At least for now…

As part of the Clarke digitization, I’ve been looking for ways to normalize Quicktime movies. I thought, incorrectly, that Sound Forge 8 would be capable of doing this. It turns out that SF 8 is not able to handle .MOV files, unless you download a particular plugin — and that’s only designed for QT 6, which is no longer the version we use.

To make a long story short, I asked Joe whether Soundtrack Pro (part of the Final Cut Pro suite) had a Normalize function. Turns out it does, and Joe says it’s very simple to use.

Because of our increasing use of H264, as well as the use of iMovie to capture video at the Film Studies Center, a new and simpler method presents itself.

If the final output is intended to be a Quicktime movie using the H264 codec:

1. Capture the clip using iMovie

2. Export from iMovie to Quicktime using the H264 codec and specifying the desired settings.

3. Run the compressed .MOV file through Soundtrack Pro’s Normalize function.

This avoids the pesky aspect-ratio business of throwing raw .AVI files at Sound Forge 8, as well as the prospect of spending $399.95 on Sound Forge 9.

There are, however, some issues.

1. The Film Studies Macs don’t have Soundtrack Pro (as far as I know).

2. If a professor wants to edit the clips on a PC, we would need some way of transferring the normalized clips to their machine — either via the server or using the MacDrive application.

All of this, of course, assumes that audio normalization is important. Quicktime Pro does give its users the options of adjusting sound levels manually, which might be enough for many clips.

And anyway, who ever said it was important to be normalized?

Video

What: Conversion of all WMV clips and full length movies to Quicktime using the H264 Codec. This codec is cross platform compatible and has no noticeable video degradation or size increase. These QT files will replace the WMV files in the teaching collection of Portfolio.
How: Nightly run batch processing of WMV to QT with appropriate codec.
Why: QT proves to be a more versatile format for editing using QT Pro as well as providing native viewing in Portfolio
Needs: QT pro for windows on Seth’s machine.

What: Save AVI files as archive
How: rename to match teaching collection numbers, these will not be cataloged in Portfolio, they are for archive purposes only.
Why: newer codecs may make editing or delivery better

Audio:

What: Conversion of WMA’s to MP3’s. Windows media player 10 did not offer a save to mp3 function. How: downloaded free wmatomp3 converter (burn the exe to disk)
Why: Native play in Portfolio; Sound comparable and file size much 2 to 3 mb smaller.

What: Quicktime in Powerpoint
How: Download QTVR plugin, help pages for inserting the video forthcoming,
Why: provides player controls on a slide, single format for Portfolio and Powerpoint

Images:

What: Tiff files
How: rename tiff files to match teaching collection jpeg numbers
Why: these are for archive purposes and possible different output methods (i.e. zooming for maps)

What: Jpeg files with descriptive names
How: rename to fit with teaching collection, verify that all descriptive names have been entered into the catalog
Why: to reduce redundancy on the drives and keep track of all image assets with Portfolio

Metadata/cataloging/organization

What: Rename the collection to fein#### rather than teaching-### (remove dash as well)
How: Use Portfolio batch rename – suggest we wait until next week when Mary returns to make sure we aren’t missing any important steps that might screw up cataloging already done.
Why: there really is no distinction between teaching and fein research. Seth can make galleries for teaching in Portfolio if necessary.

What: Piece apart the descriptive fields and add custom fields for cataloging.
How: Catalog in custom fields for the future, consolidating fields into description or caption when necessary. Lea will work to create custom fields and copy appropriate data to these fields.
Why: we can easily leverage data for searching, creating galleries and possibly mapping to endnote as well as file make pro.

What: Cataloging
How: look for a common field in file maker and endnote that we can add to portfolio for possible mapping
Why: we might be able to create a cap that will pull in data from all three collections

Drives

2TB drive needs to be formatted and items need to be copied. Seth will return 1tb for ITG use.

After some confusion on my part about the status of the Clarke project, Pam and I decided that it would make most sense to restart the whole thing. One category of videos, which seem to deal primarily with some kind of court proceeding, remain unchanged on ITG LaCie 6. The other category, which deals mostly with a village called Oyotunji (and the occasional big-haired Oprah segment from 1991), is what I have undertaken to digitize.

Lea and I had some trouble with the Mac setup — one of the VCRs seems to only play videos and DVDs in black and white, and the other displays no timecode, which can be a problem when it comes to clipping. After much head-scratching and research on the relative benefits of S-plugs and progressive scanning, I abandoned the Mac for Vader, whose penchant for capturing pesky Rebellion videos is undeniable.

Because there are some 19 Clarke videocassettes, each of considerable length, I compiled an Excel sheet on the big-screen PC listing the name written on the videocassette, along with the name I would give the corresponding digitized file. I then cleverly color-coded the spreadsheet, so that I could better keep track of the status of each video.

Here is my procedure:

1) Capture the video with Edius on Vader

2) Instead of using the traditional “Print to file” option, I decided that it would be faster to simply rename the captures with the appropriate title. Thus, Cap0612_000.avi becomes Yemojah_Festival1995.avi, I save 40 minutes, and Darth can save his energy for more important pursuits.

3) Once I have captured all of the videocassettes onto ITG LaCie 6/Kamari Clarke Videos/Oyotunji Captures (.avi), I will ProCode them with the following settings:

720×480, 29.970 fps, 4:3, Sorenson 3 Compressor codec, 48 kHz.

I created a profile called “Clarke” in ProCoder with those settings.

4) With the completed Quicktime movies saved to ITG LaCie 6/Kamari Clarke Videos/Oyotunji Quicktimes (.mov), I will transfer the drive to the Mac and use Quicktime Pro to clean up all the residue that I would normally have dealt with in Edius.

5) I will then Sound Forge the Quicktime movies. As Joe and I learned, Sound Forge only pulls its little aspect ration trick with certain types of files, and I don’t believe .mov’s are on the list.

14 videocassettes and countless fascinating hours in, I can say that I have learned a tremendous amount about a host of interesting topics: African drumming, the behavior of South Carolinian tourists, Yoruba culture, polygamy, animal sacrifice, and the effects on the human body of long exposure to poor-quality camcorder film.

For the ongoing Seth Fein project(s), I have been exploring different ways of embedding and reading metadata on MOV and WMV video files. I have not arrived at a satisfactory process yet, but I thought it might be a good idea to record some of my observations thus far.

Incorporating the data is relatively easy. For WMV, one need only right click on the file and select “Properties.” There are a number of boxes for title, author, description, etc. In Quicktime, open the movie and navigate to Window—>Show Movie Properties—>Annotations. You can then “Add Annotations” for a variety of descriptive fields. Note that you must save the MOV file before exiting Quicktime.

Fein uses Portfolio to organize his media clips. For MOVs, the metadata is clearly readable in the file header (or sometimes footer, as it were). So, theoretically at least, this data can be displayed in Portfolio. WMVs encode their descriptor information differently and tend to be less compatible with Portfolio. I was unable to locate any tools that could extract such data and put it into a usable form (i.e. XML for a Portfolio database). Although Media Catalogue 1.0 might be promising. If only I could figure out how to get it to work correctly!

There is a powerful Linux tool by the name of “libextractor” that can pull the metadata off WMV files (actually, these are ASF files, but let’s not get bogged down in semantics). After a good deal of effort, I was able to load a C compiler onto an iMac and hack libextractor to work natively on Darwin. It can do all sorts of neat things, like use an english dictionary to intelligently parse a given file for descriptor data. But, for our purposes, it can also simply read the metadata on WMVs and print the information to the terminal in “BibTeX” format. Here is a short example:

$ extract -a /Users/ITG/Movies/Test/Matrix/Captured/Clip\ 04.wmv
description - Director's Name Here: Matrix
mimetype - video/x-ms-asf
copyright - 1999
comment - blah, blah, blah
author - Director's Name Here
title - Matrix


Adding the -b operator will print the information in BibTeX format, which can then be converted to XML (or a wide variety of other formats) using BibDesk. More information (for the Linux version) can be found here.

Note to self: there’s got to be an easier way to do this. Maybe someone who is more familiar with C programming can incorporate libextractor (or the promising Media Catalogue API) into Portfolio itself?