.comment-link {margin-left:.6em;}

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, October 18, 2006

Real world notes on grading Viper/S.two footage 

The noise of the Viper - 10 Bit Log - The blogging factor

Jean-Luc Gason is a colorist who's been commenting on my blog, I followed some links from his comments and found his site and his blog, and he has a golden nugget of an entry on color grading done on Viper footage that was shot on S.two recorders.

Some comments he had:

-Viper is HD, and even 4:4:4 isn't going to change that. It is HD, and "HD is at its VERY BEST 16mm" in terms of resolution and detail. Uncompressed, or 4:4:4 only help in terms of no compression artifacts and being able to push things further in post (lift/gamma/gain/keying type stuff)

-night shots are really, REALLY good on the Viper - details not visible on monitor DID show up on filmout, so don't clip your blacks according to scope!

This was especially interesting:

10 bit log isn't a standard. I mean, it's not because Thomson tells people that their camera is shooting in 10 bit log that you'll get the same image as if your were scanning 16mm in 10 bit log. Most important, you CANNOT send Viper files in their 10 bit log state to the shoot, you HAVE to linearize them, even if you want to shoot in cineon 10 bit log. You'll have to then logarithmize them into the Cineon 10 bit log's log. I had to fight with this film director to make him understand that, and I'm sure his still think I'm a liar or an incompetent that destroyed his image by linearizing it... YOU CAN'T SHOOT VIPER'S LOG TO FILM. Simple, stated, point.

Problems encountered in the project:

-because the sound guys insisted on shutting off the onboard fans, they got pixel noisy, veiled looking output in their picture....and camera crashes and other issues. Don't let one department hose another is the lesson here.

-recorder crashes were a problem (due to overheating, fan disabled camera perhaps?) EDIT FROM EMAIL CONVERSATION WITH JEAN-LUC: nope, turns out the guy entering the shot metadata was using a shot naming system of "shot3/take5" ...and the groaning Unix guys are right - putting a "/" in the filename tricks the system into thinking that is a change into a subdirectory called "take5" that doesn't exist, so of course it crashed. A "competent" computer user (or any web designer) would know not to do that, but in the meantime, the guy running the S.two was calling it a piece of crap..because he didn't know he was making a mistake. In truth, S.two should forbid use of those characters, and tell you why.

-A.DOCK "forgetting" images to backup - maybe related to same above issue?

-some bozo decided to use non-full digital mags two days in a row, generating duplicate timecode on the same mag

-dead pixel lines from the camera due to bad boot initialization on the camera

-director misunderstandings

There's more good stuff in there as well - go read it, an EXCELLENT real world example of how things can go.

After I emailed Jean-Luc about quoting his blog so extensively, he said:

Re-reading my post, I would had some things about the linearization of the viper files. When I say linearize, best thing would be of course the linearize those 10 bit log into a 16 bit LIN format. As Viper's output it 12 bits coded in 10 bit log, 16 bit LIN won't clip anything in the linearization. BTW, Kodak cineon is 14 bit lin coded in 10 bit log, another proof that 10 bit log can be whatever you want..


Thanks Jean-Luc!

-mike
Comments:
This article really brings to light the difficulty of the data managment aspect of the IT-based camera workflow. The thing about tapes it that they are cheap and easy to protect. 4 hours to clone to LTO!!!! Yikes.

The real key to all this is getting the data levels down to something more managable with a good compression method.

I hope Graeme delivers the goods next year.
 
I have high hopes for the quality of Redcode, that'll help tremendously, and bring backup down to realtime or faster.

But for some applications, uncompressed is still the best way to go, and faster backup devices is the solution there. Or at least a high speed intermediate buffer - suck'em fast onto fault tolerant storage, then trickle to the tapes throughout the day if possible...
 
Post a Comment


Links to this post:

Create a Link

This page is powered by Blogger. Isn't yours?

Listed on BlogShares