-
Serious Black/White level bug w/ FCP 5.0.2, AE6.5.1, Tiger 10.4.2 and BMD 5.0 HELP!
I recently updated (thankfully, on a seperate partition) to 10.4.2 and all the latest of everything. I just discovered a problem with the current Decklink drivers. The output of my Decklink HD card has correct levels when coming out of FCP 5.0.2, but is incorrectly darker when coming out of After Effects 6.5.1. I have several machines, so I patched the output of this machine (via SDI) to a machine using an AJA iO and did screen grabs of the scopes for both the output of FCP 5 and AE 6.5.
The output of FCP 5 is on top, the output of AE is on bottom:
Discovered this problem while color correcting in AE and finding all my original shots appearing too dark. Naturally, I began to brighten everything up only to find them too bright when I brought them back in to FCP 5.I’ve looked at this on another machine with a Decklink card and all the same versions of the software and the problem DOES exist. I’ve looked at this on the machine that is using an AJA iO and the problem is NOT there. All the machines were booted in 10.4.2 and all have the same versions of Quicktime, FCP, AE, etc. The fact that the machine using the AJA iO does not have this problem obviously points in the direction of the BMD drivers/codec.
I’ve rendered some bars (generated in FCP, exported as reference movie) from AE in various codecs (Apple UC 10bit, BMD RGB 10-bit, NONE, etc.) and compared them with the scopes in FCP to the original bars generated in FCP and the problem is not as great. However, the Apple UC 10-bit does still cause a luminance shift that is greater than it should be. Perhaps we could have the BMD 10-bit codec back? But I digress…
Anybody else seeing this? Can you guys at BMD have a look?
Thanks
Chris Tomberlin
Editor/Compositor/Owner
OutPost Pictures -
6 Replies
-
I have the same problem, since switching to tiger/FCP5 even with the beta drivers. The latest updates haven’t fixed this. When rendering from AE the Apple 10bit codec turns out waaay brighter than it should. For now I am using the BM(DV10) for AE renders, since that is fairly close to the original. I also pine for the BM10bit codec . . .
-Felix
-
[Felix] “When rendering from AE the Apple 10bit codec turns out waaay brighter than it should.”
Strange, for me, the white levels with this codec were too low.
Chris Tomberlin
Editor/Compositor/Owner
OutPost Pictures -
Here’s a related issue. I’m using the Decklink HD Pro with Tiger.
When I run color bars out to my monitor, the center pluge bar is totally black. Nothing I do to the monitor
can get any gray out of it. When I brighten the color bars up a couple points in FCP, then I can see and adjust the
center pluge with the monitor. So, it seems that either FCP 5.02 or Decklink 5.0 is sending video out to my monitor that’s too dark.
I don’t want to wrongly adjust my images.My experience with Uncompressed HD isn’t extensive yet. But I’m finding no explicit fix for this problem.
-
Well, when I take a grayscale that I make in Photoshop, and render it out from AE, then drop it in FCP5, the apple 10bit file has a brighter gamma than it should. In your case you are saying your gamma is darker than it should be? Then I agree that our opposing results are strange . . .
-
There is some serious wonkiness going on with either FCP -or- Quicktime when it comes to luma and chroma shifting. We had this problem back when we were running the AJA IO, and it has caused me nothing but headaches and embarrasment when doing finishing work with a client looking over my shoulder.
At least with FCP 4.5 & QT 6.5.x, I get shifts in my footage (noticeably visible on scopes, as well as in a difference-matte) even if I simply export a completely untreated clip (digitized as UC 10-bit) as a reference movie out of FCP, and then re-import the reference movie BACK into FCP!
I’m perfectly aware of YUV-RGB colorspace conversion issues, but it seems to me that an uncompressed 10-bit clip, exported out of a “high-precision YUV” sequence (either to the exact same codec, or ESPECIALLY as a simple Quicktime reference movie) should NOT exhibit any color/luma shifting when re-imported back into FCP.
I did extensive tests with this, and found that the only way I could get acceptable results was to *completely* bypass using FCP to export clips, and bring the original clip (from the Finder level) into AE, and–this is VERY important–setting the project to 16bpc before rendering back out. With 10-bit footage, there is still a very slight shift that is visible on the scopes (as is to be expected, since AE only works internally in RGB colorspace), but for the most part, it’s not noticeable to the naked eye, unless you strain your eyes real hard.
While this method works, it’s really a huge pain in the ass to have to eyematch shots and edits from the originally digitized clips!
After all the tests I’ve done, I can only come to the conclusion that there is something *seriously* broken with FCP’s Quicktime export functionality. I don’t think it’s a Blackmagic issue, because as I mentioned before, I had these same issues with the AJA Io.
I haven’t yet tested any of this on FCP 5/QT7/Tiger, and was hoping that it was fixed. But obviously it hasn’t 🙁
Aloha,
mel -
I can confirm the issue. I have Echo Fire for After Effects running on Tiger. An old job I was working on wanted a new version of a scene so I run the old project. Sometimes I like to switch off Echo Fire so I can do faster Ram previews. When I chose the video preview from within AE’s prefs the same footage I was previously seeing on my CRT monitor through Echo Fire went noticeably darker. I closed down AE and restarted in Panther. Opening the same project in my Panther partion with Quicktime 6.5 and 4.5 decklink drivers, the issue does not occur
regards
Richard
Reply to this Discussion! Login or Sign Up