What to use ProRes or ProRes HQ

[Gary Adcock]

[Phil Incorvia] “Could you give some examples of what ‘heavy’ has meant in your experience?”

Sure Phil, but lets define a few things-

I almost never work with compressed camera original content, I prefer uncompressed or camera native in the case of Phantom, SII, RED and the h.264 from the Canon DSLR’s. This means I am looking at content that has little compression to start with (except for the DSLR’) so my standards of quality reflect what my preferred capture format is.

Secondly I work with really really fast storage, on fairly new computers running the latest software- I never cut content on a firewire drive except when on location.

Lastly I measure the loss by what the tools tell me, using the best hardware and software tools made to evaluate the signal and the images, I do not rely on my eyes, as they have been known to trick me after a long day.

I have tested the ProRes HQ codec extensively, I have run generational lost tests, signal degradation tests and plain old user tests. I have yet to find any need for anything greater than the HQ version of ProRes for ANY camera that is not able to capture greater than 10bit internally, ProRes HQ is considered to be the equivalent to HDCAM SR, and that is considered a lossless archival and delivery format.

Since the vast majority of users are not working with HDSR, or have access to a $100,000+ deck, that makes ProRes HQ a better format than they currently acquire in.

ProRes 4444 is designed to handle up 12bit files with an Alpha Channel and there are very very few cameras on the market that actually can handle the full 4096 levels of gray per channel. Yet, I do not know of one that can also produce an Alpha at the same time. So in mainstream use, the 4444 codec is designed to handle graphics and animations.

I have tested the ProRes HQ codec and did not find any technical or visual errors until the nearly the 50th re-encoding of the same file in the same codec.

I consider it heavy processing anytime I need to re-encode the same file more than 4 times, and that is something that is just not done in modern filmmaking.

The Canon DSLR content is recorded as 4:2:0 LongGOP at 8bits and compressed for direct web delivery in Full Range SMPTE RGB as an h.264 file. The sheer compression of the original file shot by these cameras does not offer anything to gain by going to the 4444 codec.

does this help?

gary adcock
Studio37

Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, IL

https://blogs.creativecow.net/24640

[Phil Incorvia]

Helps a lot! Thanks for your contextual response – very cool.

I’m mostly working with HD-DSLR stuff right now, and am a bit obsessed with babying the footage as much as possible so that I can pull it (mostly in Color) in different directions when I need to.

I was trying to hone in on the suggestion that your post above made that there are reasons to go ProRes 4×4 with heavy effects work. So far, vanilla ProRes has left me fairly happy given the compressed state of the camera original footage. Sounds like there isn’t a lot to be gained with the DSLRs, but keeping HQ and 4×4 in mind for RED and EX1 footage might be smart. Just always looking for that last bit-o-quality or latitude in grading to hang on to!

Setup:
2×2.8GHz Octocore
16GB RAM
ATI Radeon 4870 graphics card

FCS 3 – all up to date
OS 10.6.2

[Gary Adcock]

[Phil Incorvia] “keeping HQ and 4×4 in mind for RED and EX1 footage might be smart.”

For REDCode yes.
but not the for the EX, that is still an 8 bit 4:2:0 long GOP mpeg recording.

gary adcock
Studio37

Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, IL

https://blogs.creativecow.net/24640

[Dennis Couzin]

Jeremy Garchow: “Dennis, can you explain more as I’m not following you? ProRes is not CBR. I follow your math logic, but that’s not all of the picture. You skipped the 8bit RGB to 10bit YUV conversion and whether or not ProRes or HQ is equal in that regard.”

Concerning ProRes being VBR, according to the Apple White Paper of July 2009 “the variability is usually small”. Concerning 8 bit to 10 bit conversion, it adds 25% of data to the ProRes stream, strengthening my numerical argument. 10 bits lets us ignore the rounding errors in the RGB to YUV conversion. Why would ProRes do this differently from ProRes HQ?

For reference, compare ProRes data rates with the uncompressed 10-bit 4:2:2 data rate. Uncompressed requires 1244 Mb/s for 1080 30p. (Or 1327 Mb/s if it uses 32 bits to convey 30 bits as it does in the .mov file.) So ProRes (147 Mb/s) does 8.5:1 compression and ProRes HQ (220 Mb/s) does 5.7:1. These are significant rates of compression. Recall that DV25 did 6.6:1 compression (relative to uncompressed 8-bit 4:2:2 for the corresponding number of pixels). Obviously data rates don’t completely describe different image compressions but they are indicators. The Apple White Paper discusses ProRes vs. ProRes HQ quality very honestly.

Transcodings involve the interactions of two different codecs. It is a safe conclusion that it is desirable to transcode to a codec that uses less intraframe compression than the original.

[Dennis Couzin]

ProRes4444 is 10-bit RGB+alpha. If you look at the data rate for “ProRes444” (that is, ProRes4444 without the alpha channel) it’s exactly 150% of the ProRes(422)HQ data rate. In other words, ProRes444 does the same degree of compression as ProResHQ except it does it on full RGB instead of on 4:2:2 subsampled YUV — this explains the 150%. (Allow me to write YUV instead of Y’CrCb, since the terms Cr and Cb tend to be misunderstood.)

If the original material is 4:2:2 YUV, as it is in Anthony DeRose’s original example, why does Gary Adcock suggest that transcoding this to 4:4:4 RGB (ProRes4444) is better than transcoding it to 4:2:2 YUV (ProResHQ)?

REDCode material, derived from the RGGB Beyer filtered sensor, is not straight RGB. If RED patent application 12/422,507 is to be believed, the camera outputs a kind of quasi 4:2:2 YUV. So here too, why is transcoding it to 4:4:4 RGB (ProRes4444) better than transcoding it 4:2:2 YUV (ProResHQ)?

Why does Gary Adcock call ProRes4444 lossless? It is 5.7:1 compressed versus the corresponding uncompressed original. Again, the Apple White Paper is honest about this, describing its quality headroom as “very high, excellent for multi-gen. finishing.” It uses the same words for ProResHQ and explains why.

[Jeremy Garchow]

[Dennis Couzin] “Concerning ProRes being VBR, according to the Apple White Paper of July 2009 “the variability is usually small”.”

Have you tried comparing this yourself, or have you tried a hardware vs software conversion?

[Dennis Couzin] “Why would ProRes do this differently from ProRes HQ?”

Why wouldn’t it?

[Gary Adcock]

[Dennis Couzin] “ProRes4444 is 10-bit RGB+alpha.”

Dennis Couszin – You need to refresh your knowledge of the the article you keep quoting since the July 2009 Apple White paper on ProRes clearly states that “Apple ProRes 4444 supports 12-bit pixel depth with an optional, mathematically lossless alpha channel for true 4:4:4:4 support” on page 4, in the middle of paragraph 3.
So if Apple states that the codec in 12bit- How do you know that it is only 10bit.

[Dennis Couzin] “(Allow me to write YUV instead of Y’CrCb, since the terms Cr and Cb tend to be misunderstood.)”
Y’Cr’Cb’ is the correct SMPTE designator for digital component video in HD, how is that somehow misunderstood?

[Dennis Couzin] “If the original material is 4:2:2 YUV, as it is in Anthony DeRose’s original example, why does Gary Adcock suggest that transcoding this to 4:4:4 RGB (ProRes4444) is better than transcoding it to 4:2:2 YUV (ProResHQ)?”

I did not, I clearly state that [gary adcock] “So in mainstream use, the 4444 codec is designed to handle graphics and animations.” in my note to Phil regarding his question on when to use other flavors of ProRes.

[Dennis Couzin] “REDCode material, derived from the RGGB Beyer filtered sensor, is not straight RGB. If RED patent application 12/422,507 is to be believed, the camera outputs a kind of quasi 4:2:2 YUV.”

So you have never used a RED Camera have you? The video output from the RED is not considered to be more than a confidence monitoring signal- REDCODE is captured as an R3D file on a RED Drive or CF card and has little to compare with the video signal out of the camera. The R3D format from RED is considered to carry more than 10bits of data so why wouldn’t it benefit from the best desktop codec that can handle more than a 10bit signal?

[Dennis Couzin] “Why does Gary Adcock call ProRes4444 lossless?”

Once again Dennis Couzin, while calling me out, you have incorrectly read or reported on my remarks, and in some cases erroneously state claims are not true.

I clearly state here that [gary adcock] ” ProRes HQ is considered to be the equivalent to HDCAM SR, and that is considered a lossless archival and delivery format”

SO it is HDCamSR that is that is considered “Lossless for Archiving” though it is technically not lossless.

gary adcock
Studio37

Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, IL

https://blogs.creativecow.net/24640

[Rob Grauert]

hmm, well, I’m glad regular ProRes is just fine for most cameras, cause this is WAAAY over my head.

Rob Grauert, Jr.
http://www.robgrauert.com
command-r.tumblr.com

[Gary Adcock]

[Rob Grauert] “hmm, well, I’m glad regular ProRes is just fine for most cameras, cause this is WAAAY over my head.”

I am sorry that it gets into head butting Rob,

Most people accept the simplest answer, that ProRes standard is more than good enough for the vast majority of users, HQ is needed if you really want to maintain fidelity at the cost of greater hardware and storage needs and that 4444 ProRes from a camera original is really only for the highest level workflows. (FYI – currently only certain models of the Arri Alexa can capture onset as ProRes 4444 and I happen to be one of the very few people that have access to one of these cameras)

Quality to some is a judgement call, to me its about maintaining the quality of my images thru post – not about how much space or bandwidth the compression uses.

gary adcock
Studio37

Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, IL

https://blogs.creativecow.net/24640

[Dennis Couzin]

Gary,
Item 1. I was wrong here. The White Paper does say ProRes4444 supports 12-bit and does not say this is an option. If ProRes4444 is a 12-bit codec, then it is doing an extreme chiselling of the image in order to stream (without its alpha channel) at just 150% the rate of ProRes422HQ. Going from 422 to 444 makes 150%. Going from 10-bit to 12-bit makes 120%. Together that’s 180%. This is puzzling. This should be discussed in a separate strand about compression.

Item 2. I’ve witnessed smart people referring to Cr as a red component and to Cb as a blue component and have come to believe that SMPTE made a poor choice of terminology. Notice that Jeremy Garchow also uses the YUV terminology in this strand. When the purpose is just to contrast with RGB, it’s preferable.

Item 3. The statement of yours I challenged was:
[gary adcock] “Using the HQ codec only offers advantages if you are planning on doing heavy effects or corrections within the ProRes codec or the FCS3 suite, and if you are you should be working in the lossless 4444 version, You gain nothing going to HQ if the compositing is being done outside of the FCP/ Color workflow, nothing at all.”

Item 4. I’ve never used one — too damned heavy — but I’ve hung around a RED camera shooting session and also edited/manipulated some raw RED output. By “output” I mean the files stored on the drive, not the irrelevant video output. For clarity I should have said “capture”. The camera captures a kind of quasi 4:2:2 YUV. You’re right that the RED’s capture being more than 10-bit commands the 12-bit codec even if the codec is RGB rather than YUV.

Item 5. The statement of yours I challenged was the same one quoted above. So long as we agree that ProRes4444 is far from lossless these verbal disputes don’t matter.