Data Recording

With electronic cinematography, I'd say right now the biggies are access to RAW data, RGB instead of YUV recording, extended dynamic range, multiple frame-rates, and ergonomics that resemble the workflows used in film production rather than being squeezed into the video production mould by necessity (i.e. access to film lenses, optical viewfinders, film-style accessories, film-camera ergonomics, etc.). I believe that Jeff outlined many of these points very nicely in an email a couple weeks ago (Bread and Butter: falling butter-side down).

One thing that really irks me though, and I'm going to see if it gets remedied this NAB, is that first point, access to RAW data. It really puzzles me why, if cameras, etc. are digital, meaning that they're recording digital bits onto tape, hard-drive, etc., do we have such a hard-time getting access to the data? HD-SDI is NOT IT friendly. It takes an expensive card, expensive hard-drives, etc., etc. to record that stuff. Why can't we go to a computer friendly file-formatted system, where you don't have to move the data around in real-time, and in the case of compressed formats, can move it faster than real-time over the latest serial connections.

The problems with dropped frames, pre-roll/post-roll, timecode breaks, drop-outs, 0 IRE vs. 7.5 IRE, video routers, break-out boxes for SDI/Analog, etc., these, at least to me, seem like the IT infrastructure trying to fit itself into the traditional workflows and methodologies of the video market rather than the other way around. Maybe Sony is fixing some of the mess with their new eVTR series of recorders (at least that what it seems like the brochure is advertising), but with ease of use the digital still photography market has made of the manipulation of the files that the camera takes on the computer, I really don't see why that can't happen in the video market, especially with the new wave of digital cinematography cameras coming to market in the next two years. Audio recording has adopted IT-friendly workflows (i.e. Aaton Cantar, etc.), the digital still camera market has, even film has with scanning, datacines (Spirit 2k), and DI, and it only seems logical that the high-end video/digital cinematography market should be next. To work with HD-res footage I shouldn't have to rent an expensive deck, have an expensive HD-SDI card, worry about dropped frames, etc. Hopefully the manufacturers are working on IT friendly workflows that simply say copy from here-to-here, just like we've done with files over Ethernet for the last twenty years (at least, I'm not quite sure when modern Ethernet was created).

I think part of the problem has been the lack of computing power available to manipulate such data and the storage space available, but both the power and storage is available now, the software to manipulate these files is there, now we just need easier access to the data on the cameras (or datacines), and easier IT-friendly ways of digital distribution (i.e., "dumping" back to tape should be just another file-transfer, not back through the SDI pipes) to complete the circle.

Just my .02 cents

Jason Rodriguez
Post Production Artist
Virginia Beach, VA

Jason Rodriguez wrote :

>It really puzzles me why, if cameras, etc. are digital, meaning that >they're recording digital bits onto tape, hard-drive, etc., do we have such >a hard-time getting access to the data?"

And what would you suggest as the "pipe" from the camera to the capture device? Or do you want to capture on the camera? And at what cost? And how long a recording time? And how do you want to move the data to the post production facility?

Do you want to talk about IT infrastructure and dropped frames?

Answer these questions first. Then look at what is available to accomplish what you have proposed. I am not disagreeing with you. Just the opposite.

Uncompressed RAM recording? For what duration? At what cost? Where is it and when?

From Individuals to the largest companies come the most "interesting" claims. Pie in the sky claims.

The biggest problem yet to be solved is the "offline and transportable" media for storage of all this uncompressed data.

Regards,

Bill Hogan

Bill Hogan writes :

>And what would you suggest as the "pipe" from the camera to the >capture device? Or do you want to capture on the camera?

I must say that I was heartened by Jason's message, it's something I intend to cover anyway because I can't see the sense in converting raw RGB data into dual HDSDI feeding it down a cable and then converting it back to RGB. There has to be a way to deal with the raw data directly.

As to record in RAM, of course! a CineRAM directly interfaced to the raw data and then take that pack to your disk store and dump, use multiple err, mags and have a downloader instead of a loader.

Cheers

Geoff Boyle FBKS
Director of Photography
EU Based
www.cinematography.net

Bill Hogan wrote :

>The biggest problem yet to be solved is the "offline and transportable" >media for storage of all this uncompressed data.

I hope someone at Kodak is reading this and sniggering
to themselves...

Tom Townend,
Cinematographer/London.

>The biggest problem yet to be solved is the "offline and transportable" >media for storage of all this uncompressed data.

>I hope someone at Kodak is reading this and sniggering to >themselves...

If they are, it will be yet another in a long series of miscalculations about where things are headed.

I suggest that based on the last decade's performance, Kodak is not in a financial position to have their execs be sniggering at anything.

Bob Kertesz
BlueScreen LLC

Bill Hogan writes :

>Uncompressed RAM recording? For what duration? At what cost? >Where is it and when?

I think the folks over at BayTech Cinema and S-two are on the right track, having inputs that are compatible with HD-SDI, but then making the data available to IT infrastructures (even in-the-field laptops) through ethernet, USB 2.0, and Firewire. The thing that puzzles me though, is like Geoff said, why dual-link HD-SDI for RGB? And even worse, what Arri is thinking using 3 HD-SDI's to output the raw data from the camera! The RAW data is no use on a tape deck, it's going to a hard-drive eventually, so get a serial connection that's more hard-drive friendly like SATA, Firewire2 (the IEEE1394b spec can go up to 3.2Gb/s), SAS (serial attached SCSI which goes up to 4Gb/s), etc. There are many serial connections out there that are not as cumbersome and expensive as HD-SDI to use, and don't require coaxial BNC's everywhere. Fibre can be run for at least a kilometre, and again, it's IT-friendly. The point I'm trying to make is that if everything is going in a computer, and the cameras, telecines, digital VTR's, etc. have "computers" in them, why not make it easy for everyone to talk to each other? Why put a "glue" between the machines that is technology built on a video infrastructure, not an IT infrastructure?

>The biggest problem yet to be solved is the "offline and transportable" >media for storage of all this uncompressed data.

Hard-drives are getting very cheap. There are data tape formats available if that doesn't work (but they're slower than hard-drives). The amount of space that a hard-drive takes up is less than a roll of film, and Blue-Ray DVD's, which are dual-sided can hold up to 40GB (and they take up even less space).

Not everything is perfectly in place for everyone to use right now, but the thing to keep in mind is what direction are we trying to go in? At some point this industry is going to have to break from the past and stop building this gigantic, immovable tower on older video-based infrastructures. Computers and the associated technology are advancing to the point where they can handle the loads placed on them by HD to 4K footage, why not make it easier for computer based software tools and video-based hardware tools to communicate with each other?

Jason Rodriguez
Post Production Artist
Virginia Beach, VA

>HD-SDI is NOT IT friendly. It takes an expensive card, expensive hard->drives, etc., etc. to record that stuff.

The Blackmagic Decklink HD card is already under $2000. I don't know how anyone could consider that "expensive." As for hard drives, you can get HD capable RAID systems from vendors like Huge Systems and others for under $3000 per terabyte. I don't consider that "expensive" either, unless you're referring to putting it in your home office for personal
use.

Frankly, the way I see it is that such standards allow for inexpensive support equipment like that mentioned above. Where there are standards there is ease of use and manipulation, and therefore a larger potential audience. What you're suggesting would likely require a lot more expertise, computing power, and IT-type support. I'm not saying it's not a good scenario, only that there are good reasons why the video model persists.

BTW, I think two words should be completely banned from the vocabulary of everyone who talks about new technology - "just" and "simply."

Mike Most
VFX Supervisor
IATSE Local 600
Los Angeles

Dear Mr. Kertesz :

Kodak Entertainment Imaging (Motion Pictures) is doing just fine, thank you. Last year set records for film sales volume, and featured the introduction of the new VISION2 family of films :

http://wwwau.kodak.com/AU/en/motion/news/customerLetterP.shtml

Here is what Dick Sehlin, our Chief Technical Officer has to say about plans for the future:

http://www.kodak.com/country/US/en/motion/products/v2/sehlin.shtml

John Pytlak
Customer Technical Services
Research Labs, Building 69
Eastman Kodak Company
Rochester, New York 14650-1922 USA
website: http://www.kodak.com/go/motion

John Pytlak writes :

>Kodak Entertainment Imaging (Motion Pictures) is doing just fine, thank >you. Last year set records for film sales volume, and featured the >introduction of the new VISION2 family of films :

Rochester's Democrat and Chronicle newspaper seems to disagree somewhat with this assessment:

style="font-size: 11px">http://www.democratandchronicle.com/biznews/01222F317CB_business.shtml

One division may be doing "just fine" but the company as a whole seems to be doing less so.

Bob Kertesz
BlueScreen LLC