ProRes 422 – After Effects gotcha
Previous testing of the ProRes codec comparing it the Avid DNxHD codec yielded some unexpected results when Adobe After Effects was used to generate test media. While the Avid codec made the round trip from Media Composer 2.7 to After Effects and back without issue, the ProRes codec showed what appears to be an YUV to RGB conversion issue.
Further testing reveals that the issue is not consistent between a recent beta release of Adobe After Effects 8/CS3 and After Effects 7.
Pictured (click to enlarge) are the waveform and vectorscope images when the original ProRes 422 HQ material is placed on V1 of a Final Cut Pro 6 timeline and the same image placed on V2 after being run through After Effects with no changes made to the image – the clip was placed in an AE timeline and simply re-rendered with ProRes 422 HQ.
For the time being I don’t recommend using Adobe After Effects to render ProRes 422 material. While we can be confident this issue will be addressed shortly, this is exactly the kind of gotcha that can be expected when a new codec is released in the latter phases of a beta cycle. I’ve been transcoding clips to the Animation codec with Final Cut’s Media Manager before going to After Effects. Allowing FCP to handle the YUV-RGB conversions seems to work well.
The bigger lesson is that whenever a new codec is introduced to your workflow it should be tested in the applications it will be used in.
Looking down the road, color space, codec, and file format, and frame rate conversions will be with us for a long time. Make hardware and software decisions with eye towards the future and compatibility.
comments
4 Responses to “ProRes 422 – After Effects gotcha”
Leave a Reply
Frank,
There’s a new checkbox in After Effects CS3 that will let the user decide on how to handle QuickTime gamma conversions, due to bugs in QuickTime. You can either go with the AE7 method that will lead to gamma shifts between Mac- and Windows-rendered clips, or use the better CS3 method.
I’m not in front of a CS3 install at the moment, but I think it’s in the “Interpret footage” dialog box. Please try to change this setting and try again.
Very interesting Frank. I had just noticed some stuff yesterday running difference mode myself.
If possible, can you update your blog post so to clarify some stuff?
Can you expound upon these differences in behavior?
Placed on an AE timeline I assume? Rendered in AE and then imported to FCP? (the text isn’t clear)
I assume you are using ‘Difference’ mode in FCP…but you don’t mention it…
Can you explain these procedures and steps you took?
All this stuff will really help folks track with you exactly.
Thanks Frank, good catch on calling this one out.
Carey
The differences between 6.5 and 7 are subtle. Each shows a shift, but slightly different. Perhaps Jonas’ comment explains this.
If you looked at the image you would have seen the final comparison was in FCP. (I think the steps are clear enough – FCP to AE back to FCP for comparison. I can’t think of another way to do this.)
BTW — The “specifics are important line” you asked about was supposed to read “specifics are not important.” To me, that there’s a color shift is enough to render the codec unusable for the FCP to AE workflow. I don’t need to know anything else except when it’s fixed.
It’s easy to run the test yourself as described in the original post with any codec.
Does this help?
http://blogs.adobe.com/toddkopriva/2009/03/prores_422_colors_in_after_eff_1.html