Skip to main content

The colours in my video aren't accurate

Robert Bullen
  • Updated

Color Correction

iShowU HD / HD Pro since 2.1.2, can (optionally, it's off by default - see footnote) perform color correction of captured video.  This can result in better colors, with the most obvious being removal of a green tint in H.264 recordings.

To enable color correction, turn the option on in General Preferences.

When is correction applied?

Correction is applied for a selection of common codecs. The most common QuickTime codecs for which correction is applied (assuming you have correction enabled under General Prefs in HD) are:

  1. Apple Intermediate Codec
  2. H.264
  3. DV
  4. JPEG
  5. Apple ProRes, XDCAM

Correction is not applied to:

  1. MPEG4
  2. Apple Animation

What can I expect to see?

The amount of correction you see is highly dependent on your monitor. For example, on a wide gamut 30" Dell monitor, the difference between color corrected/uncorrected greens is considerable. However on a Cinema 23" display, the difference is there but barely noticeable.

If you record in one of the formats for which correction is applied, the you can test for yourself by creating two recordings, one without correction and one with. You can then open both of these in QuickTime and observe the differences.

In testing here, we found that correction of both Apple Intermediate and H.264 produced better whites (the green tint was removed) and a far better perceptual match with the original. JPEG content was a bit washed out.  MPEG4 content ended up being far far brighter and incorrect (hence we don't correct MPEG4), besides which there was no green tint visible in the first place. As a result, we don't currently correct MPEG4 content.

  1. The reason that correction is optional is that the correcton appears different per compression method (Apple Intermediate, H.264, JPEG, MPEG4 etc), and we didn't want to force it on with the possibility of a less desirable result than in if it were off.
  2. Correction is applied to any codec that can take Y'CbCr coded data directly.  Correction is not applied to codecs that don't take this format (i.e: Apple None, Apple Animation).

Video Card Specifics

Color correction will not be enabled on some video cards; GMA950 (older Mac Mini), ATI 9600 (older G5's). This is because the older video cards cannot cope with the size of code it requires.

The nitty gritty details

Here's a very good question from an actual user:

"Is there any way to record with iShowU that yields fairly accurate color/brightness results? While recording PhotoShop software demos the results from iShowU have brighter images in the video.

My current set up is calibrated with a ColorVision Spyder2.  I prefer to use H.264 compression because the finished videos will be upload to the web. I have Quicktime Pro and could darken the video with a filter and then resave, but this would recompress and add more time. In addition to H.264, I have tried Apple Intermediate Codec, Apple Animation, and Apple MPEG4 Compressor. Even when the quality set to Lossless, the results are always a brighter video.

I have tried to find answers in the forum but have not found anything that worked. Are there any settings that I am missing? Any info is appreciated. Thanks."

Unfortunately there's no way to get absolutely perfect results.  I've spent a vast amount of time on this, talking to Apple engineers and the official response is "There's no API (Application Programming Interface) to let you do it".

The reason is that I haven't found a way to "uncorrect" any color changes caused by calibrations.  e.g: In the case above, HD is capturing from a display calibrated using a Spyder. That means the captured frames are all calibrated to the Spyder ICC profile. Before we perform Rec601/709 color space conversion, we should really be "undoing" this calibration to return the data to it's raw RGB form.  Apple don't provide a way for us to do this.

All codecs make different assumptions about the color space of the incoming video. Most YUV based codecs (H264, MPEG4, JPEG, etc) assume Rec 601.  But even then, H264 assumes Rec 601 if the size is "less than HD" and Rec 709 if the size is "greater or equal to HD". On top of that, if a compressor choses to convert between color spaces they more often than not don't perform a correction first (I'm told this by Apple themselves). Therefore you end up with conversion loss as each frame is compressed, because a HD isn't correcting the screen calibration first and b even if conversion is performed inside the compressor, a correction may not be applied beforehand.

It gets worse. QuickTime 7 (and I believe X) then perform additional gamma correction upon playback, and this gamma correction is different in 10.4, 10.5 and 10.6.  Add to this that the QT player plugin in Mozilla (for example) doesn't perform this gamma conversion, but the standalone QT player does... And that windows has a different default gamma than OSX 10.5 and below, and you end up with an absolute minefield of ... (insert word here).  HD tags the video with it's gamma function - so in theory we get around this hurdle, but the problem of no reverse correction for calibrated displays remains.

HD Pro assists in getting color "more correct" by:

  1. Reversing the screen gamma of captured video,
  2. Applying a conversion to Rec601 or Rec 709 (depending on codec / size)
  3. Re-apply a gamma of 2.2.
  4. Tagging the video with the correct gamma and color matrix (Rec601 or Rec709 as above).

The idea is that the QT player should honor the gamma value, and no longer guess. It seems to work on 10.6, but I can't vouch for previous releases.

In various tests here, I found codecs responded very differently to the above process. The end result was very much cobbled together from observation (since even Apple couldn't / wouldn't tell me what each codec did *exactly*). Hence the list above, mentioning when Color Correction is applied (e.g: It's not applied to MPEG4, because in my tests - it looked worse).

There is one way around it.  And that's to setup both the monitor, and the calibration to be sRGB.  From what I've been told this is what most codecs expect.  If you do that however; you'll likely need to be working in quite a dark room with little ambient light (as things will appear too bright otherwise).

Without switching your monitor calibration, you can however get close, but it requires additional filters.  It'll be close. Better. But not perfect. It also means you have to muck about to get the result you want.

I hope this helps explain the rationale behind color correction.  I know it doesn't solve the entire issue, but perhaps it sheds some light on the mess we're in.

Comments

0 comments

Please sign in to leave a comment.