- March 25, 2013 at 2:02 pm
I have a question about how information is lost through re-rendering of Apple ProRes files. I have a feature where the original files were Apple ProRes 422. The finished film will have a 2.35 crop and some titles for the opening credits. If the ProRes files are graded in a dedicated system, such as Resolve or Baselight or Nucoda and then delivered to the director as ProRes 422, can he then bring the movie back into FCP and do an online, one in which he puts black bars and titles over top? Can he do this without degrading the parts of the image unaffected by the bars and text? I am not fully aware how rendering works. If black bars are cropping, they’re of course not affecting the parts of the image we care about, but does just the simple act of re-rendereding the video degrade the image as a whole? My initial thought was that he absolutely had to put the bars on during the grade and I was also concerned about putting titles on once the film had gone back to ProRes. Is there anyone out there who understands the exact mechanics of rendering who can shed some light on this matter? Many thanks.
Film Editor, London UK
- March 25, 2013 at 3:48 pm
ProRes is a lossy codec so with each generation the quality will suffer. Consider using 10-bit Uncompressed for intermediate steps.
- March 25, 2013 at 4:00 pm
Thanks, Michael. I was thinking that perhaps the unaffected parts of the frame wouldn’t be recompressed, but have since learned that in a lossy codec the entire frame is recompressed and that in an uncompressed codec, only the affected parts are.
Film Editor, London UK
- March 25, 2013 at 4:19 pm
But ProRes is a very efficient codec, where you won’t notice the degradation until after many levels of recompression. I don’t start seeing things until I recompress about 4 times. My typical workflow is ProRes 422 or HQ online, send to color grade…grade, render out as ProRes 422 or HQ (1 level of recompression), bring back into FCP…add title and other text, render out ProRes master (2 levels of recompression).
Two levels won’t degrade the image in any way that you’d notice.
Little Frog Post
Read my blog, Little Frog in High Def
- March 26, 2013 at 11:47 am
[Scott Clements] “have since learned that in a lossy codec the entire frame is recompressed and that in an uncompressed codec, only the affected parts are.”
Whatever thing you put on a FCP sequence is rendered as 444, so when you render 8/10b Uncompressed, the missing chroma samples are interpolated, but when you export as 8/10b Unc, the same chroma that has been interpolated is discharged, so you end up with the same 422/YCbCr values that you started.
But I’m with Shane.
ProresHQ is not Uncompressed but was designed to stand a multi-generations workflow without visible degradation.
- March 27, 2013 at 2:03 am
Generation loss with ProRes HQ is minimal. Even using standard ProRes generation loss is fairly insignificant. Page 15 of the ProRes whitepaper tells us the second generation of ProRes HQ will take a small hit, but after that detail is preserved.
Here’s my advice:
It only makes sense to keep as much detail as the camera captures.
If your source is an 8 bit (HDSLR, DVCPRO HD, XDCAM 50 or less, or HDV) ProRes 422 will keep all of the detail your camera captured. ProRes HQ is overkill for these formats.
If you’ve captured at 10 bit or higher (HDCAM tapes, AVC Intra, KiPro, RED, Alexa, etc.) working in ProRes HQ is a fantastic balance between uncompressed quality and manageable size/bitrates.
If you’re paranoid about every bit and you have the space/bandwidth to burn an uncompressed codec will preserve every bit. Do some screen tests for uncompressed verses ProRes HQ and decide if the difference is significant enough for the data payload. Use difference mattes if you want to see the impacts of the compression.
- March 27, 2013 at 4:37 pm
[Jeff Meyer] “10 bit or higher (HDCAM tapes,”
Just a little tiny quibble for rigor (maybe rigor mortis), but if we’re counting bits, HDCam is an 8-bit format, with HDCamSR being 10-bit. It seems out of character, since the HDCam format (DCT, same bitrate, except at 1440×1080-internal) is arguably an extension of Digital Betacam, which is also 10-bit.
“I always pass on free advice — its never of any use to me” Oscar Wilde.
- March 27, 2013 at 6:59 pm
Thank you for the correction!
Log in to reply.