Snow Leopard Quicktime Gamma issue

[finegrit 0]

So I hoped that the switch to gamma 2.2 in Snow Leopard would kill the dreaded gamma shifts round tripping from AE > Final Cut would be solved. I ran some tests today. Here's what I did:

 

Opened a source .r3d file and color corrected. Rendered to 4 formats (QT animation codec, QT Blackmagic 10bit, QT prores HQ, and PSD sequence) once with match legacy "on" and once "off". I then opened the resulting files in Quicktime, Final Cut and back open in AE CS4. Here's what I got:

 

Quicktime (match legacy off)

Animation: looked much brighter than original

Blackmagic: looked the same as original

Prores: looked the same as original

PSD: looked much brighter than original

 

Quicktime (match legacy on)

Animation: looked much brighter than original

Blackmagic: looked much brighter as original

Prores: looked the same as original

PSD: looked much brighter than original

 

Final Cut (match legacy off)

Every look the same as original

 

Final Cut (match legacy on)

Everything looks the same as original except:

Blackmagic which is much brighter than original

 

After Effects CS4 (match legacy off)

Everything looks the same as original except:

Blackmagic which looks much darker than original

 

After Effects CS4 (match legacy on)

Everything looks the same as original except:

Blackmagic which looks much brighter than original

 

Anyone tried a similar test or willing to try reproducing the results with other footage? I didn't try Compressor since I couldn't even get this path to stabilize.

 

And yes I know that there's a lot of sense to avoiding Quicktime all together, but I'd like to understand how the new operating system is dealing with these gamma tags.

[pixelthief 0]

Is it true that you don't have to buy QT pro anymore?

[Albo 0]

Is it true that you don't have to buy QT pro anymore?

Yes and No.

 

Snow Leopard ships with QuickTime X (both Player app and Plugin) but the app is essentially JUST a media player with minimal editing.

In order to use what you know as the fully featured QuickTime Player 7, you still need a pro license.

[imcalledandy 0]

I read that QuickTime 7 can be found in the Utilities folder.

[Guest Sao_Bento]

I read that QuickTime 7 can be found in the Utilities folder.

In Ed McMahon voice- YES! YOU ARE CORRECT SIR!!

[Albo 0]

I read that QuickTime 7 can be found in the Utilities folder.

This is true ONLY if you had a previous Pro license. If one is NOT detected, say on a clean system install, you need to manually install it from the Snow Leopard DVD.

[imcalledandy 0]

Ok cool.

 

I guess the new QuickTime X icon will grow on me... preferred QT7 icon....

[finegrit 0]

Hey guys, not to be a downer on this fascinating thread about Quicktime, but anyone have any thoughts about the gamma issue?

[froj 0]

All I know is that things that looked colourful, shiny, glossy and lovely in QT7, whether it was animation codec, h264, whatever, now look crap in QT X and I'm not entirely thrilled about the whole matter

[Derek Lerner 0]

This has driven me nuts trying to find a solution. Apple product specialists and engineers are currently looking into these issues with QuickTime X as well as 7 running on Snow Leopard. I've been going back and fourth with them for the last few weeks. Here is all my documentation along w/ screen shots.

 

I am attempting to create a workflow so that C4D, AE, FCP, PS, & QT will all present the same file consistently in terms of color/brightness across multiple applications. If anyone here knows of any workarounds I'd love to hear from you.

 

p.s. If you performed an erase and install of Snow Leopard and do not happen to have the install disk handy you can attempt to open a Quartz Composer (.qtz) file with QT X and the OS will ask you if you would like to download the SL version of QuickTime 7.

[finegrit 0]

Okay, I've accepted the fact that I'm the only person OCD-enough to keep writing about this (except for maybe Derek. Love your documentation, man), but I hope my affliction will help others. Here's what I've found over the last few weeks of experimenting:

 

We've been running tests on Snow Leopard, CS4 and FCS3 on one of our test machines. The basic workflow we've been testing is capture via BM Decklink in FCS3 to prores and BM encoded files. We've also tested starting with raw .r3d files from a recent RED shoot. Import into CS4 (AE and Photoshop). Render back out to a range of codecs (BM, prores, animation, PSD seq, TIff seq). Import all to Final Cut Pro. Send to Compressor and compress to h264. The goal has been to keep consistent gamma and colors throughout that trip.

 

Despite the switch to a default gamma of 2.2, the gamma problem is not fixed. However, it is more consistently wrong(!!!) and because of that you can actually now work around it (sort of).

 

It seems that Adobe has gotten their act together. Roundtripping through the Adobe suite now works flawlessly regardless of codec. In fact, we've found that colors and gamma are much more consistent when "Match Legacy Codec Settings" is turned OFF. We found some shifts in the Blackmagic codec when it was on.

 

Apple products are a mess. So far, we've only been able to verify that Prores and Blackmagic codecs seem to be working properly. The only problem is that they look very dark when previewed in DVDSP, but the compressed movies look fine. All the RGB codecs (including Animation, PNG and None) and PSD and TIFF sequences experience a gamma shift when viewed in Quicktime or roundtripped between CS4 and FCS3.

 

However, Apple describes a workaround here: http://support.apple.com/kb/HT3712. They use Automator to permanently alter the gamma tag of a movie file. What seems to be happening is that Quicktime correctly assumes that the YUV codecs should have an HD gamma tag (or those two codecs just happen to write the tags properly). Other codecs are assumed to have some other gamma and are shifted.

 

But the workaround explained in the Apple support document (using Automator to change the color profile of movies) does seem to fix the problem. It is not undoable, so make sure you test everything before you go switching tags on all you movies. BUT, this fix only seems to work on machines running Snow Leopard as far as I can tell. Good times!

 

Anyone else have thoughts?

 

NOTE: I've only tested this with video files. I haven't tried experimenting with stills yet.

Edited September 29, 2009 by finegrit

[Guest Sao_Bento]

1. The link doesn't work

2. You have tried altering the way the gamma is tagged inside of FCP, right?

[finegrit 0]

1. The link doesn't work

2. You have tried altering the way the gamma is tagged inside of FCP, right?

 

1. Sorry. Here it is: http://support.apple.com/kb/HT3712

 

2. Not sure exactly what you mean. You can adjust the way FCP interprets the gamma of still images, but not movies. You can adjust the gamma to darken the image, but because the tag is still there and read differently by different programs, you'll now have a super-dark image in some programs.

[Guest Sao_Bento]

I see - it's for Animation only.

http://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=85%26section=32

[ChrisProsser 0]

Okay, I've accepted the fact that I'm the only person OCD-enough to keep writing about this (except for maybe Derek. Love your documentation, man), but I hope my affliction will help others. Here's what I've found over the last few weeks of experimenting:

 

It seems that Adobe has gotten their act together. Roundtripping through the Adobe suite now works flawlessly regardless of codec. In fact, we've found that colors and gamma are much more consistent when "Match Legacy Codec Settings" is turned OFF. We found some shifts in the Blackmagic codec when it was on.

 

I'm pretty excited to hear that! We spent a lot of time in CS4 tweaking all the fiddly things we could find trying to make it behave. In the end there was no one way we could make every workflow work, which is why we have the preference.

 

We've been hearing about some ProRes 444 gamma shifts recently and we're talking to Apple about it. I can't recall if it was Snow Leopard only.

 

I'm going to send our resident OCD gamma geek a link to this thread so we can try and integrate anything interesting into out testing in CS5.

 

--chris

[Dan Ramirez 0]

I'm pretty excited to hear that! We spent a lot of time in CS4 tweaking all the fiddly things we could find trying to make it behave. In the end there was no one way we could make every workflow work, which is why we have the preference.

 

We've been hearing about some ProRes 444 gamma shifts recently and we're talking to Apple about it. I can't recall if it was Snow Leopard only.

 

I'm going to send our resident OCD gamma geek a link to this thread so we can try and integrate anything interesting into out testing in CS5.

 

--chris

 

Resident OCD AE gamma geek here. I've had a lot of trouble reproducing this problem lately with Quicktime Uncompressed 10bit as the original source in FCP(which is then converted to ProRes4444 in FCP), but I can now easily reproduce with ProRes4444(when it's re-rendered to ProRes4444 in FCP).

 

I'm not sure why I can't reproduce with ProRes4444 media that was originally 10bit v210, but in the meantime, here's a solution that *should* work for most of you.

---

Add the following line to your MediaCoreQTGammaRulesCS4.xml file located at harddrive/users/username/library/application support/adobe/common

 

<QTCodec codec='ap4h' vendor='****' platform='mactel' direction='encode' versionlow='0x00000' versionhigh='*' gammatag='true' />

 

We've already got the rules for the other flavors of ProRes, so this is a safe change. It just adds the appropriate tagging for 'ap4h' which is the 4444 flavor.

 

Thanks,

Dan Ramirez

After Effects

QA

Edited November 12, 2009 by Dan Ramirez

[Jonah Lee Walker 0]

Resident OCD AE gamma geek here. I've had a lot of trouble reproducing this problem lately with Quicktime Uncompressed 10bit as the original source in FCP(which is then converted to ProRes4444 in FCP), but I can now easily reproduce with ProRes4444(when it's re-rendered to ProRes4444 in FCP).

 

I'm not sure why I can't reproduce with ProRes4444 media that was originally 10bit v210, but in the meantime, here's a solution that *should* work for most of you.

---

Add the following line to your MediaCoreQTGammaRulesCS4.xml file located at harddrive/users/username/library/application support/adobe/common

 

<QTCodec codec='ap4h' vendor='****' platform='mactel' direction='encode' versionlow='0x00000' versionhigh='*' gammatag='true' />

 

We've already got the rules for the other flavors of ProRes, so this is a safe change. It just adds the appropriate tagging for 'ap4h' which is the 4444 flavor.

 

Thanks,

Dan Ramirez

After Effects

QA

 

That is great. Is there a a code for the DVCPRO HD codec? I have been major color shifts rendering into that format. Now I know I can use ProRES, but I would love to be able to render into DVPRO HD without the gamma shift as well.

 

Thanks!

[Todd Kopriva 0]

That is great. Is there a a code for the DVCPRO HD codec? I have been major color shifts rendering into that format. Now I know I can use ProRES, but I would love to be able to render into DVPRO HD without the gamma shift as well.

 

Jonah,

 

Dan responded to this same question from you in the comments on my blog:

 

"@Jonah - I'm unaware of a gamma shift with DVCPROHD. If you give more details I may be able to help.... - Dan Ramirez"