We're comparing the rendered out highest-quality h264 files versus the DVCPro HD 720p files.
Note that the renders were
Although the drive is already at the lab, I'm going to experiment with putting the bit depth back to high. UPDATE: Actually, that particular shot with the banding has a lot of effects on it. And it's only a couple frames where it sucks that much. Much of the general yukkitude is part of the original footage, raising the bit depth doesn't/didn't help.
It's easy to tell which image is the DVCPro because they're somewhat skewed to the wrong aspect ratio. UPDATE. OK, I fixed that. So let's look at the pictures one by one shall we?
Here is Ryan and Warchild. Top picture is from the h264 Quicktime (exported, as all the 264's here, with keyframe set to "automatic" and the highest-quality, dual-pass). The lower picture is from the rendered out DVCPro HD 720p Quicktime. What do we learn? Well, one thing is
This image with nobody in it shows the worst of the "banding" which I can find. Top is h264, bottom is DVCPro HD. Honestly, they both look really close to what is in the timeline.
I can't really see a difference between the h264 and the DVCPro HD.*
The last two are Dunn in the hallway. It's the same frame, two different renders.
Remember that these images were all acquired on a Panasonic HVX200 using a Letus35 adapter and Canon S.S.C. lenses. (My guess is that the top images are an 85mm, the middle a 50mm or... maybe an 85mm, and the bottom a 35mm.)
They were imported into Final Cut Pro and I really don't understand what it is that Final Cut does when it imports DVCPro HD 720p from the .mxf files on a P2 card -- is that another compression hit? Who knows?
Then the images were rendered out to h264 and DVCPro HD.
And THEN they were made into the .jpg images (using the highest quality settings in FCP and exporting as a still image from the viewer.)
Plus also too I nearly screwed up big-time with the files at the lab. They were going to take the flattened Quicktimes and bring them into their own project. Eek! That's totally not how I'd set it up. That could have gone very badly -- I'd made changes in a timeline which didn't need rendering -- but there were additional video files of those changes. So they would have made DigiBetas with the errors (which we'd already caught) in them.
Plus, I didn't realize that FCP will output multitrack Quicktimes. Apparently the number of tracks is dictated by the number of outputs you have. Sheesh! I could have avoided a lot of rendering that way (I think). Although I don't know how iDVD handles Quicktimes with more than two tracks. Does it just sum them? Does it just take the first two tracks?
*I'm not saying they're identical, I just can't really decide which is better.
No comments:
Post a Comment