Speed Merchants In Post
Posted on Feb 10, 2011 by Alex Fice
In the second of a series of articles by Michael Ganss of high speed specialists Pirate, production workflows for high speed footage shot on Vision Research’s Phantom and Photron’s BC2 cameras are explored and explained.
As a rental company specialising in high speed cameras, we have a complicated answer to the producer’s questions: “How do I handle the data? How can I be sure it is OK?” It’s complicated because there are several options, the choice depending budget, time constraints and perhaps the need to fit into an existing workflow (in order to cut with film or Red footage for example).
RAW data, Bayer pattern and all that
All high speed digital video cameras, in common with most digital stills cameras, have a single image sensor, the surface of which is divided into a grid of light sensors. These sensors are only ‘black and white’ – they only measure brightness. To ‘see’ colour a fixed grid of red, green or blue filters are fixed in front of each sensor. The colour arrangement of these filters is in a particular pattern known as a ‘Bayer’ pattern. The light falling on each sensor, through its own colour filter, is measured by electronics to produce a ‘raw’ computer data file of red, green and blue values known as the ‘RAW’ file (a.k.a. digital negative). After downloading the RAW file, the data is converted (de-Bayered) into a sequence of colour images, usually .tif files, using a particular algorithm (a sophisticated mathematical recipe for interpreting the colour information in a RAW file into ‘real’ colour).
A consequence of this technique is that when viewing finely detailed scenes some algorithms are better than others at interpreting the fine detail. All algorithms generate errors (artifacts) of these finely detailed areas. On green screen shoots with flowing hair for example, these artifacts can be significant.
In the UK, the HD high speed cameras readily available for hire are the Phantom HD Gold, the Photron BC2 and now the new Phantom Flex. All these cameras have 4:2:2 HD-SDI video out for monitoring and some outside broadcast and drama productions simply record this, to a Sony SR deck for example, providing simple timecoded rushes for their tried-and-tested post-production workflow. The major drawback of this approach is that not only does the 12 or 14bit image data only get truncated by saving as 10bit video footage (at best), but also the cameras’ hardware de-Bayering is much poorer than using more powerful, sophisticated software de-Bayering of the data later. Consequently, we generally supply the cameras’ RAW data. That is where life can get complicated.
Tif file sequences: simple – aren’t they?
Data is downloaded from a camera in its own specific format for transcoding into the real world later. Both manufacturers provide software for producing a wide range of file formats, the only one of any interest to most post houses being 16bit tif sequences. The 16bit tif format enables the 12 or 14bit data to be carried into post-production within the 16bit file format. Video formats provided by the manufacturer’s software (.avi or .mov for example) are not capable of carrying the 12 or 14bit data.
The manufacturer’s software is free-to-use, although idiosyncratic, by clients and their post house. We can usually guide someone through how to use them over the phone. The processing can be slow (depending on the PC and speed of hard drives), and quite often takes 12 hours for a day’s worth of shooting.
A downside of using either manufacturer’s de-Bayering software are that their algorithms are not the best. De-Bayering algorithms are complex and as a general rule, the more complicated they are, the better the results, but the more complicated they are, (requiring more computer processing), the longer it takes to get results. Their free-to-use software is a compromise between speed and quality, although for many projects the quality is fine.
The downsides of .tif sequences are two fold – firstly, they are cumbersome, wrapping 12bit Photron data, say, with four ‘packing bits’ into a 16bit file format produces some big data numbers. A 16bit .tif frame of 1080 x 1920 is approximately 12MB. So a single take, running for three minutes, say, occupies 54GB of disk space – far too big to conveniently offline edit. Secondly, one cannot readily offline edit as there is no timecode associated with the clip. Timecoded rushes allow an editor to supply an Edit Decision List (EDL) for an automatic replication of the editor’s cut using the original data (the ‘conform’). Without timecode, the conform must be done by eye matching from the offline edit footage to the rushes, which is a tedious and time consuming process.
Available from Glue Tools, the ‘Phantom Cine Toolkit’ software allows direct import of Phantom camera data within Final Cut Pro (FCP) by putting a Quicktime ‘wrapper’ around the RAW file. (Any software that can edit using Quicktimes can read the camera data directly). The downside is the software investment (currently $800) might not be justified on a one-off project.
Further, the quality of the de-Bayered image is not best, simply because the transcode time has been minimized to enable editing ‘on the fly’, trading off quality against speed. This lower quality is probably not significant to many productions and Glue Tools does provide a ‘quick and dirty’ solution for editing with the Phantom RAW files directly.
This software is not built to work with Photron cameras. Whilst Vision Research, say this is the best Phantom workflow for FCP, they also detail on their web site a more circuitous route from camera data via .tif sequences into FCP. Longer, more involved, but no software purchase necessary and this method applies to both Phantoms and the BC2.
Whilst lack of timecode may not be significant on a simple edit, it can be created by loading all the tif sequences onto a powerful post-production tool, for example, a DVS ‘Clipster’. Clipster is an expensive hardware/software machine capable of many post-production tasks. After tif sequences are loaded on a timeline, a digibeta tape can be produced for the offline, returning to the Clipster with the EDL for the conform. The Clipster can also ingest the Phantom’s RAW file and perform the de-Bayering too. Indeed, the Clipster can colour correct and many other relevant tricks too. The only problem might be the cost: the system is very expensive and only the high-end post houses own them. And that means the charges are high.
Iridas’ higher end product, ‘FrameCycler DI’ provides similar functionality to the Clipster and again is a posthouse solution. However, they offer simpler much cheaper products, such as ‘SpeedGrade OnSet’ which can read Phantom RAW files directly and allows a quick look-see at the data on set for quality control purposes. This is usually provided as part of the camera technician’s toolbox. For transcoding the RAW data, their ‘MetaRender’ software can be used after the shoot to provide a wide range of file formats to suit most post-production workflow.
‘ShotServer’ by Pirate / Modern Industry
So there are many ways to skin the Bayer cat and transcode the data for post-production. The only trouble is, they are all after the shoot. And that means that when issues occur with the data later (and they often do …) it is just too late to do anything about it. That’s why we at Pirate developed ‘ShotServer’ with Modern Industry. This is a unique hardware/software system, running on set, for laying to rest the multiple ghosts of ‘it looked alright on set, how come the data is too dark? / the highlights are blown / there is noise in the blacks / I won’t get my rushes until when?! / why I can’t do an offline? / is my data safe? / I want to edit on set / etc’.
ShotServer provides several real-time facilities on set for both Phantom and BC2 cameras. Using top-end de-Bayering algorithms and within minutes of a take being saved, editors on set or
internet-connected can work with off-line Quicktimes and scrutinise full resolution stills for artifacts. Further, the shot list is served up to authorised users via a web browser for annotation and personal playback, often obviating the need for video playback on set.
To minimise the chances of data loss, data is saved first to mirrored RAID disks and then to twin archive external drives. On wrap, all timecoded Quicktimes (and stills) for off-line, together with a shot-log spreadsheet, can be taken away on disk or laptop. The same system later transcodes the RAW data into whatever format of digital intermediate the post-production workflow demands.
Of course, none of these tricks can’t be achieved by other means, but the difference is they are on set, handling and securing data from camera to conform. Further, ShotServer replaces the conventional DIT role, which typically involves driving a set of disparate software by hand: ShotServer is integrated and automatic, thus minimising the simple human errors like mis-labelling or forgetting to tick a critical box in a software’s new release.
In summary, the choice of which system(s) to use depends very much on budget, quality required and how paranoid you are about data integrity and security.