Atom Feed
RSS Feed
Buy Mike Recommended
edit systems & gear
from Silverado Systems
Buy Books, Software, & More
at HD for Indies Amazon Store
Buy New Movies from
HD for Indies Amazon Store
Or, you can also support
HD4NDs by contributing
to the tip jar...
Help Support HD for Indies
RSS Feed
Buy Mike Recommended
edit systems & gear
from Silverado Systems
Buy Books, Software, & More
at HD for Indies Amazon Store
Buy New Movies from
HD for Indies Amazon Store
Or, you can also support
HD4NDs by contributing
to the tip jar...
Help Support HD for Indies
Advertisements
Great HD Links
- HD For Indies Home Page
- HD For Indies FAQ
- HD 24
- Cinematography
- Bare Feats
- 24p Entertainment
- Digital Praxis
- OneRiver Codec Resource
- CamcorderInfo.com
- LumiereHD
- HighDef.org Info
- Understanding RAID
- Video Systems (Reviews)
- DV Film (DV=>Film)
- SonyHDVInfo.com
- Plus 8 Digital (vendor)
- Digital Cinema Society
- Texas High Def (local F900 guy)
- Creative Cow (news & forums)
- Philadelphia FCP User Group
- Los Angeles FCP User Group
- Cinema Tech
- FresHDV
- DV Info's forums
- HVX User
- Pro App Tips
- Bluesky Media - Instruction
- RedUser.net
- fxguide
- little frog in high def
- VideoMaker Learning Section
- Stu Maschwitz's ProLost
Archives
- March 2004
- April 2004
- May 2004
- June 2004
- July 2004
- August 2004
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- February 2005
- March 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
- October 2006
- November 2006
- December 2006
- January 2007
- February 2007
- March 2007
- April 2007
- May 2007
- June 2007
- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- December 2007
- January 2008
- February 2008
High Definition Video for Independent Filmmakers
A How To Guide for Digital Filmmakers
Welcome all! This is my blog to share my latest research,
thoughts, etc. on utilizing HD for independent filmmaking.
YES, I am available for consulting
Contact me at mike@hdforindies.com
All content copyright 2004-2007 Mike Curtis.
Wednesday, May 30, 2007
First stab at comparing DNxHD and ProRes
Studio Daily Blog � The great codec bake-off
I wouldn't call it that (the great codec bake-off), since it is just a first step, and I have a lot of technical quibbles (see my comment, and Graeme's next in the article) - so don't let the headline throw you - I think it is of interest to compare the two, but the results as shown are not what I would consider final nor unequivocal.
I'd like to see the One River Codec test image used to compare them, use some real footage (DCI StEM, anybody?), test/experiment with the 4:4:4 chroma filtering option, etc.
-mike
UPDATE - he redid some tests, and the results make ProRes look better, but it isn't clear if his currently posted images are the new-and-improved, or the old-n-busted. I'm still going to fool with it on my own when I get a chance.
Just got off the phone with a client asking about whether ProRes obviates the need for a RAID for HD work...good question, I don't have a definitive answer yet. Let's presume it falls between the quality of DVCPRO HD and uncompressed (a pretty reasonable presumption) - therefore for SOME amount of the market it will be good enough for their needs - the real question is how much of that market - and I don't know the answer to that yet, I need to do my own testing now that I'm back in town.
At this point, while he's said he retested, I'm not sure whether the posted files are the original testing methodology or the second improved-but-still-potentially-have-issues testing methodogy - so while his intent may have been to have a conversation starter on codec quality, I don't consider his downloadable files & samples worth seriously evaluating in depth until his testing methodology is clearly documented, updated results posted, etc.
Otherwise, his post is merely a conversation starter as he states but his headline implies otherwise, and his presented data lacks relevance to the core question at hand. To me, the core issue is how good are these codecs in their "native" environments first (Final Cut for ProRes, Avid for DNxHD), and a secondary but still interesting question is how good are these codecs for intermediate files rendered out of After Effects. Methodology is crucial in these regards.
-mike
I wouldn't call it that (the great codec bake-off), since it is just a first step, and I have a lot of technical quibbles (see my comment, and Graeme's next in the article) - so don't let the headline throw you - I think it is of interest to compare the two, but the results as shown are not what I would consider final nor unequivocal.
I'd like to see the One River Codec test image used to compare them, use some real footage (DCI StEM, anybody?), test/experiment with the 4:4:4 chroma filtering option, etc.
-mike
UPDATE - he redid some tests, and the results make ProRes look better, but it isn't clear if his currently posted images are the new-and-improved, or the old-n-busted. I'm still going to fool with it on my own when I get a chance.
Just got off the phone with a client asking about whether ProRes obviates the need for a RAID for HD work...good question, I don't have a definitive answer yet. Let's presume it falls between the quality of DVCPRO HD and uncompressed (a pretty reasonable presumption) - therefore for SOME amount of the market it will be good enough for their needs - the real question is how much of that market - and I don't know the answer to that yet, I need to do my own testing now that I'm back in town.
At this point, while he's said he retested, I'm not sure whether the posted files are the original testing methodology or the second improved-but-still-potentially-have-issues testing methodogy - so while his intent may have been to have a conversation starter on codec quality, I don't consider his downloadable files & samples worth seriously evaluating in depth until his testing methodology is clearly documented, updated results posted, etc.
Otherwise, his post is merely a conversation starter as he states but his headline implies otherwise, and his presented data lacks relevance to the core question at hand. To me, the core issue is how good are these codecs in their "native" environments first (Final Cut for ProRes, Avid for DNxHD), and a secondary but still interesting question is how good are these codecs for intermediate files rendered out of After Effects. Methodology is crucial in these regards.
-mike
Comments:
Mike
I did a comparison between ProRes and 10 bit uncompressed out of Shake and could not get the results that were shown by Studio DAily. I posted on the FreshDV blog what I did.
ProRes from my quick and not exhaustive test holds up very well compared to 10 bit uncompressed. Actually amazingly well.
I think there is an issue with the CS3 export rather than there being quality issues with ProRes.
I did a comparison between ProRes and 10 bit uncompressed out of Shake and could not get the results that were shown by Studio DAily. I posted on the FreshDV blog what I did.
ProRes from my quick and not exhaustive test holds up very well compared to 10 bit uncompressed. Actually amazingly well.
I think there is an issue with the CS3 export rather than there being quality issues with ProRes.
# posted by 
: Wed May 30, 04:44:00 PM CST
: Wed May 30, 04:44:00 PM CST
I did a test and found ProRes to do a great. It must just be the export process.
http://elvisripley.com/prores/
http://elvisripley.com/prores/
Hi, I compared prores hq and uncompressed 10bit, and it's impossible to see the difference. My test is this, capture with prores 10bit with final cut and decklink multibridge, and capture the same with uncompressed 10bit. After this export the prores clip with uncompressed 10bit codec and compare the image with shake or other programs under the same codec (uncompressed 10bit). The difference is only a low low level grain. But if you compare prores codec and uncompressed under shake there're big difference because when you import prores into shake it's only a 8 bit codec, and has a problems with the resolution of the chrominance. I think that ProRes is so good but only under FinalCut Studio, if you go out of this, you need to work with uncompressed 10bit.
Salu2.
Jose Miguel.
Salu2.
Jose Miguel.
# posted by : Thu May 31, 03:21:00 AM CST
: Thu May 31, 03:21:00 AM CST
I should clarify, I exported a 10bit uncompressed file out of Shake. This file was then imported into a FCP6 project then exported as ProRes422HQ clips. Re-imported into FCP6 then compared on the timeline against the original 10bit uncompressed clip.
The was a very tiny difference between the files and absolutley invisible to the naked eye.
Based on my test I'd say it would do a better job than the DNxHD examples posted.
I do realise I have one point on a line so to speak but will do further test as time allows.
I have not exported ProRes from Shake and am interested to find out why Shake would only export to 8bit in this codec. Jose perhaps you could enlighten me?? Please.
Cheers
The was a very tiny difference between the files and absolutley invisible to the naked eye.
Based on my test I'd say it would do a better job than the DNxHD examples posted.
I do realise I have one point on a line so to speak but will do further test as time allows.
I have not exported ProRes from Shake and am interested to find out why Shake would only export to 8bit in this codec. Jose perhaps you could enlighten me?? Please.
Cheers
# posted by : Thu May 31, 03:50:00 AM CST
: Thu May 31, 03:50:00 AM CST
Steave, normaly 8bit and 10bit are different codecs, but ProRes can be managed at 8 or 10 bit, I think that only FinalCut can make a 8 or 10bit ProRes and all other program can make only 8bit. It's strange but the default easy setup of blackmagic multibridge can't make 10bit ProRes you need to change the specification for 10bit because it think that ProRes is only 8 bit. Maybe in future updates Apple change this, but for now i recomend to use uncompressed when you work with programs out of final cut studio.
Salu2.
Jose Miguel.
Salu2.
Jose Miguel.
# posted by : Thu May 31, 08:03:00 AM CST
: Thu May 31, 08:03:00 AM CST
There's a white paper here:
http://www.digitalpictures.com/images/ProRes_422_WhitePaper.pdf
ProResHQ is 10 bit, I presume the regular ProRes is 8 bit. But I know for a fact that the HQ is 10 bit, full raster.
Presets may be incorrectly set up, but the codec can do 10 bit. After Effects may need the text setup/pref-y files manipulated to handle 10 bit, but the codec itself is 10 bit.
-mike
http://www.digitalpictures.com/images/ProRes_422_WhitePaper.pdf
ProResHQ is 10 bit, I presume the regular ProRes is 8 bit. But I know for a fact that the HQ is 10 bit, full raster.
Presets may be incorrectly set up, but the codec can do 10 bit. After Effects may need the text setup/pref-y files manipulated to handle 10 bit, but the codec itself is 10 bit.
-mike
I have confirmed the problem exporting from Shake with ProResHQ.
Jose you are indeed correct and thanks for the heads up as this might have bitten me down the line and no doubt when I am incredibly busy.
There is certainly no issue with the quality of ProRes as far as my tests this afternoon have been able to show. I am pretty confident that it is the host application that caused the rendering quality drop in the Studio Daily tests. Comparing BlackMagic's 10 bit output against ProResHQ is nothing short of amazing considering the massive drop in file size and just how little info is actually lost.
I wonder if there is any way of getting 10bit ProRes out of Shake? Anyone?
Cheers Mike for the link.
Jose you are indeed correct and thanks for the heads up as this might have bitten me down the line and no doubt when I am incredibly busy.
There is certainly no issue with the quality of ProRes as far as my tests this afternoon have been able to show. I am pretty confident that it is the host application that caused the rendering quality drop in the Studio Daily tests. Comparing BlackMagic's 10 bit output against ProResHQ is nothing short of amazing considering the massive drop in file size and just how little info is actually lost.
I wonder if there is any way of getting 10bit ProRes out of Shake? Anyone?
Cheers Mike for the link.
# posted by : Thu May 31, 08:58:00 AM CST
: Thu May 31, 08:58:00 AM CST
Certainly a third-party comparison should be done between ProRes and Cineform (which has already been pretty definitively demonstrated to outperform DNxHD) now that Cineform is available for the Mac.
Or perhaps the idea is that ProRes is a passable workflow if you decide not to go with Cineform.
Richard
Or perhaps the idea is that ProRes is a passable workflow if you decide not to go with Cineform.
Richard
# posted by : Thu May 31, 02:29:00 PM CST
: Thu May 31, 02:29:00 PM CST
CineForm also offers a 12-bit 4:4:4 version of their codec now that is a lot more appropriate for post compositing, color-correction (especially when you're doing secondaries), and VFX work.
ProRES is also DCT based rather than wavelet like CineForm, so I would still see the quality edge, even at 10-bit 4:2:2, going to CineForm, at least at equivalent data-rates.
ProRES is also DCT based rather than wavelet like CineForm, so I would still see the quality edge, even at 10-bit 4:2:2, going to CineForm, at least at equivalent data-rates.
Jason, I don't think we know for certain that ProRes is DCT based - Apple have not told anyone about the insides of the codec that I know of. That said, DCT is only ever a problem when the data rate is too low and it degrades so that blocks can be visible, whereas our beloved wavelets don't - they just get blurry. If both a wavelet and a DCT codec have enough data rate, they can look great. Also, it's tricky to direct compare data rates without looking at what type of entropy encoding is being used as that has as much an effect as the type of transform.
Investigating further into why the Studio test failed, it looks to be how AE specifically is handling things.
When AE renders the ProRes project, it passes RGB with a gamma of 2.199997 to the codec, which the codec converts directly to Y'CbCr using the Rec.709 matrix. Good so far. AE then tags the resulting render file with a 'gama' image description extension set to 2.199997. I don't think that this should be done for a Y'CbCr format though.
Things go awry when AE decodes the rendered ProRes file. AE requests a decode to RGB with a gamm of 2.199997. Since the codec is Y'CbCr-based, it decodes to 2vuy and QuickTime performs the 2vuy to RGB conversion. Apparently, this 2.199997 gamma request causes QT to invoke the Rec.601 conversion matrix rather than the Rec.709 matrix, resulting in a color shift.
The same color shift does not occur with Uncompressed 10-bit 4:2:2 because AE uses its own built-in v210 to RGB conversion routine rather than going through QuickTime.
Graeme
Investigating further into why the Studio test failed, it looks to be how AE specifically is handling things.
When AE renders the ProRes project, it passes RGB with a gamma of 2.199997 to the codec, which the codec converts directly to Y'CbCr using the Rec.709 matrix. Good so far. AE then tags the resulting render file with a 'gama' image description extension set to 2.199997. I don't think that this should be done for a Y'CbCr format though.
Things go awry when AE decodes the rendered ProRes file. AE requests a decode to RGB with a gamm of 2.199997. Since the codec is Y'CbCr-based, it decodes to 2vuy and QuickTime performs the 2vuy to RGB conversion. Apparently, this 2.199997 gamma request causes QT to invoke the Rec.601 conversion matrix rather than the Rec.709 matrix, resulting in a color shift.
The same color shift does not occur with Uncompressed 10-bit 4:2:2 because AE uses its own built-in v210 to RGB conversion routine rather than going through QuickTime.
Graeme
Hi Graeme,
Okay, quick clarification . . . it has been privately confirmed to me that ProRES is *not* wavelet-based (leaving DCT as the other major contender and hence why I posted it was DCT-based). Of course as you note, this information was not gathered on an official apple-website or from the apple white-paper, but I have other sources who are in-the-know :)
Okay, quick clarification . . . it has been privately confirmed to me that ProRES is *not* wavelet-based (leaving DCT as the other major contender and hence why I posted it was DCT-based). Of course as you note, this information was not gathered on an official apple-website or from the apple white-paper, but I have other sources who are in-the-know :)
Hey Mike,
Care to comment on Frank Capria's (from DV Magazine and moderator of the FinalCutPro-L) public statement that you are an "idiot", "pseudo-pundit" and an "insipid moron" because you wrote this post?
http://movies.groups.yahoo.com/group/FinalCutPro-L/message/37508
Care to comment on Frank Capria's (from DV Magazine and moderator of the FinalCutPro-L) public statement that you are an "idiot", "pseudo-pundit" and an "insipid moron" because you wrote this post?
http://movies.groups.yahoo.com/group/FinalCutPro-L/message/37508
# posted by : Sun Jun 03, 01:19:00 AM CST
: Sun Jun 03, 01:19:00 AM CST
Wow, that was seriously not nice of Frank to say.
My biggest issue with that piece was the headline - by publicly declaring it "The great codec bake-off" and then starting out with "I’m not a codec guy. I don’t know the ins and outs of codecs the way engineers do.", then later declaring DNxHD the winner.
I originally decided to link to the article to counter some other headlines I'd seen around that were citing the article as proof that DNxHD spanks ProRes.
I don't know why he is so particularly cranky with me, and I don't know whether he's mad that I wrote this post, or that I commented as I did, when I simply pointed out some potential issues with his testing methodology. In his revised article, he now tests with a methodology...much closer to what I'd suggest, but hey, he'd probably just say I'm making that up.
(BTW - Compressor 2.x used to clip >100 IRE values due to QuickTime issues, does it in version 3? Could STILL be throwing off his results potentially.).
So I have no idea why he's so mad at me - we've never met, we've never emailed, and even looking at what I wrote it wasn't accusatory or insulting.
Hmmph.
-mike
My biggest issue with that piece was the headline - by publicly declaring it "The great codec bake-off" and then starting out with "I’m not a codec guy. I don’t know the ins and outs of codecs the way engineers do.", then later declaring DNxHD the winner.
I originally decided to link to the article to counter some other headlines I'd seen around that were citing the article as proof that DNxHD spanks ProRes.
I don't know why he is so particularly cranky with me, and I don't know whether he's mad that I wrote this post, or that I commented as I did, when I simply pointed out some potential issues with his testing methodology. In his revised article, he now tests with a methodology...much closer to what I'd suggest, but hey, he'd probably just say I'm making that up.
(BTW - Compressor 2.x used to clip >100 IRE values due to QuickTime issues, does it in version 3? Could STILL be throwing off his results potentially.).
So I have no idea why he's so mad at me - we've never met, we've never emailed, and even looking at what I wrote it wasn't accusatory or insulting.
Hmmph.
-mike
Indeed Jason, it could very well be DCT based, but it could also be non-DCT block based like h.264, or it could be something else entirely. Without a confirmation or denial from Apple, we'll never really know for certain. Certainly interesting though, eh?
Fank's comments about you, Mike, on the FCP-list are out of line. Completely.
In the opening comment of Frank's blog entry he states he knows nothing of the engineering details of codecs. Perhaps that's where his blog entry should have ended.
Graeme
Fank's comments about you, Mike, on the FCP-list are out of line. Completely.
In the opening comment of Frank's blog entry he states he knows nothing of the engineering details of codecs. Perhaps that's where his blog entry should have ended.
Graeme
Oops, tweak - two comments above I said Frank declared DNxHD the winner - incorrect! I should have said the article gives the impression DNxHD was the winner.
He does caveat himself, but a cursory glance at the article (and let's face it, for many folks that's all they do) gives the impression that DNxHD is better - compound that with the headline and that take-away is reinforced.
-mike
He does caveat himself, but a cursory glance at the article (and let's face it, for many folks that's all they do) gives the impression that DNxHD is better - compound that with the headline and that take-away is reinforced.
-mike
Graeme - when I asked an Apple engineer-type guy at NAB about "Is it wavelet?", he said they were withholding that info to let folks decide for themselves whether the codec was good or not. He said there are good and bad implementations of both wavelet and DCT.
Since wavelet is the hot buzzword these days, I'd personally lay odds about 95%+ in favor that it is in fact DCT based - if it were wavelet, they'd be sayin' so is my guess.
-mike
Since wavelet is the hot buzzword these days, I'd personally lay odds about 95%+ in favor that it is in fact DCT based - if it were wavelet, they'd be sayin' so is my guess.
-mike
Frank may have done a footnote update, the still the misleading 'test' is presented as is, with those images for download as is.
Graeme
Graeme
After exchanging some emails, he's stating that he is merely calling me a pseudo-pundit, not a insipid moron - a finely shaded interpretation, but he's sticking by his pseudo-pundit statement - oh well, that's his call to make - but his attitude certainly doesn't put him on my Christmas card list.
Tongue almost in cheek, by those standards, I think he's pseudo-professional in his methodology and analysis of the issues.
-mike
Tongue almost in cheek, by those standards, I think he's pseudo-professional in his methodology and analysis of the issues.
-mike
Care to comment on Frank Capria's...public statement that you are an "idiot", "pseudo-pundit" and an "insipid moron"...
Yikes. I have this odd mental image of a bunch of artsy geeks with torches and pitchforks... ;-)
I originally decided to link to the article to counter some other headlines I'd seen around that were citing the article as proof that DNxHD spanks ProRes.
My particular headline wording was in retrospect somewhat glib. Though you tend to assume that when someone is blogging for Studio Daily, that they have done some research.
In the opening comment of Frank's blog entry he states he knows nothing of the engineering details of codecs. Perhaps that's where his blog entry should have ended.
Zing. ;-)
Matt Jeppsen
www.FreshDV.com
Yikes. I have this odd mental image of a bunch of artsy geeks with torches and pitchforks... ;-)
I originally decided to link to the article to counter some other headlines I'd seen around that were citing the article as proof that DNxHD spanks ProRes.
My particular headline wording was in retrospect somewhat glib. Though you tend to assume that when someone is blogging for Studio Daily, that they have done some research.
In the opening comment of Frank's blog entry he states he knows nothing of the engineering details of codecs. Perhaps that's where his blog entry should have ended.
Zing. ;-)
Matt Jeppsen
www.FreshDV.com
Still, confirmation of ProRes's foundations notwithstanding, regarding DCT-vs.-wavelet when addressing issues like multi-generational image breakdown, isn't DCT more prone to exaggerate certain artifacting (mosquito noise, blocking, etc.) especially on multiple generations? (Assuming a "good" implementation of comparative DCT-based and wavelet-based codecs.)
This is my understanding and relative experience, anyway, which makes a high-quality wavelet codec far more preferable for digital intermediate work.
This is my understanding and relative experience, anyway, which makes a high-quality wavelet codec far more preferable for digital intermediate work.
# posted by : Mon Jun 04, 10:02:00 AM CST
: Mon Jun 04, 10:02:00 AM CST
Apologies to Mike for my unprofessional comments. I was wrong about Mike and the resource he's built here. His observations were correct.
I retested the ProRes codec per suggestions made on the blog, and ProRes performed quite admirably when used as intended within FCP's YUV space.
Thanks for allowing me to post here, Mike.
Post a Comment
I retested the ProRes codec per suggestions made on the blog, and ProRes performed quite admirably when used as intended within FCP's YUV space.
Thanks for allowing me to post here, Mike.
Links to this post:
