Update: Readers were quick to point out some issues with the informal test. Frank retested, and ProRes 422 has been vindicated.
“Using the ProRes 422 (HQ) codec as intended… it delivers as promised and a bit better than expected…..Further, I have been able to determine that most of the difference spotted in the Difference mode tests in After Effects was due to some sort of a gamma shift.”

Frank Capria whipped up a quick codec compression test pitting Avid’s DNxHD 175 and DNxHD 115 codec flavors against the similar Apple ProRes 422 and ProRes 422 HQ codec options.

“After re-importing the results in After Effects, I placed each file in a composition along with the Uncompressed 10-bit 4:2:2 version and used the Difference transfer mode to illustrate where the compressed image varied from the uncompressed. The results were quite surprising. The DNxHD 175 file’s difference from the uncompressed was barely visible to the naked eye, but the ProRes 422 (HQ) codec showed significant differences. In fact, in my test, the DNxHD 115 codec also outperformed the ProRes (HQ)”

Obviously this was a very quick and informal test, as Frank himself is quick to note. But the differences are striking…Avid’s codec is absolutely killing ProRes in these examples. It will be interesting to see how ProRes performs in more extensive testing.

(Via Editblog)


6 Responses to “DNxHD spanks ProRes 422 in (flawed) informal codec comparison”  

  1. 1 Mike Curtis

    I just left a comment on that article - I have multiple issues with that test. Don’t call this game yet…

  2. 2 Steve Speed

    I have issues with that test too.

    I have comped (1920×1080 16bit) a Grad and a circular Grad in Shake and exported an uncompressed 10bit 422 sequence.

    This was imported into FCP6 then a ProRes HQ exported. Reimported and difference comped in the timeline. A very fine grey line showed up around the circular Grad. I have not experimented with using the 4:4:4 filtering option in ProRes yet which might solve that issue. Needless to say that one could not see any difference visually when zoomed in 800% and switching between video tracks.

    My tests do NOT show the huge degradation that the Studio Daily tests have shown. Might I suggest it could be operator error rather than ProRes being at fault.

    Steve

  3. 3 Matthew Jeppsen

    Thanks for the heads up, Mike. I see that Graeme also has some suggestions for Capria to test. Good to see this sort of debate this early in the game, IMHO.

    -MJ

  4. 4 Matthew Jeppsen

    Steve, thanks for your ProRes vote of confidence. I also see that from the Studio Daily post comments that many are calling into question the infamous Quicktime gamma shift…

    -MJ

  5. 5 Graeme Nattress

    I think alarm bells should have rang as soon as Frank saw the massive differences he did. As far as I can see, AE incorrectly sets a gamma value for a YCbCr codec, something it shouldn’t do, which forces an image encoded with REC709 to be decoded as REC601 causing shifts. You don’t need to know the technical gubbinses to see that something is pretty wrong when you do a difference test like this! Even just flicking between the encode / decode image would show that something has gone, and at that point, you certainly don’t blog about the codec being at fault without digging further!

    Graeme

  6. 6 Matthew Jeppsen

    Very true. But at least Frank was very much up-front with the informal and unfinished nature of the test. And thankfully, blogging tends to be a conversation, a two-way street. He was called on his conclusions by commenters such as yourself, and ProRes vindicated. As Mike Curtis said, I believe Frank meant it as a conversation starter. Which brings up another issue…should that sort of thing be on a blog dispensing information, or should the conversation occur on a forum? I would tend to point to the latter…

    -MJ

Leave a Reply