News for June 2007

Digital Production, Part 6 – Post-production…

Judging by the amount of time that has gone by since part 5 of this series, the post-production phase has taken the longest. Part of this was due to technical issues (many of which will be covered later), but a good deal of it is due to budget limitations unfortunately. Anyway the “post-production” stage is itself made up of separate processes, each of which could warrant its own article, and each of which involve almost exclusively digital processes.

In brief:

  • Arrangement of all digital assets was done using Assimilate Scratch. Two uncompressed copies of the source data were kept on removable storage (and weighed in at around 500GB per copy).
  • All editing was done by editor Ollie Rainbird, using an Avid system. The cut was made from digital rushes created using the method described in part 5, delivery consisted of a CMX3600 EDL, as well as a QuickTime reference.
  • Music was composed and produced by James Griffith, and supplied as WAV files.
  • The final sound mix (including an ADR session) was created by Stumpy Music and supplied as WAV files.
  • Mastergrade was done using Assimilate Scratch (version 2.5 at the time).
  • Final touch-ups were done using Autodesk Combustion.

The editing, sound and music were done in a standard way, similar to the approach taken by practically every other production. Of note was that pretty much everything was supplied, reviewed and commented on using E-mail or by FTP transfer, which saved a lot of time. Of course, everything was also logged using our own production database (more on that in the next part of this series).

We used Assimilate‘s Scratch for the beginning and end of post-production, and the rest of this article will primarily revolve around how that fit into the workflow.

Getting Started

The first thing to do was to generate the DPX source data. For the DVCAM material, we just output the entire reels as 720×576 DPX frames. The HDV material would require higher resolution, and thus more disk space. Given the total number of shots, we decided to just extract sequences that would be needed for the final cut (with a generous number of handles). From our database, we out the list of 100 or so shots, and then built Combustion projects to output de-interlaced, 10-bit 1920×1080 DPX frames (but still have them indexed by reel). This was probably the most tedious part of the entire process, but at least it worked. Of note, one last process we ran the frames through was a preliminary colour-correction pass. Normally this is a very bad idea as it limits the flexibility you have when you come to grade, but was necessary in this case, as the look we were going for could not be achieved through traditional grading systems. In Combustion, we multiplied each frame with itself (a traditional digital photography technique that boosts the image density) and then replaced the green channel with the yellow channel, and replaced the blue channel with the (original) green channel to get the desired look.

The next stage was to reassemble all of the uncompressed, de-interlaced elements into Scratch. At this stage, we had three key pieces of data: the source data (stored as single DPX frames), QuickTime references, and the offline EDL. Typically at this stage we would have needed to convert the QuickTime movies to DPX stills as well, but fortunately Scratch can read QuickTime files directly, thus saving us the conversion time (not to mention additional disk space).

Creating the project was fairly straight-forward, just set the base output format and default media folder and you’re basically ready to go. From here it’s simply a matter of lading the required shots in. Scratch has a very logical system for loading in multiple shots, you can either load them in one by one, or have Scratch scan through all the folders, loading everything it finds, and organising it according to the directory structure it finds them in. One of the other interesting points is that it scans directories for files very quickly. In fact, it seems to load a folder full of files faster than Windows Explorer could list them. Of course, there is no actual movement of data happening at this stage, but the speed boost is still appreciated.

There’s actually another way to get data into Scratch: using an XML file. We found out just how useful this was very early on. From our production database, we were able to generate Scratch XML files that would load entire reels, split them into separate clips for each take, and even add comments to each one. The XML file is simply dropped into a pre-determined “watch” folder, and while Scratch is running it will update the project accordingly. This provided us with a very efficient method for making changes to the conformed material.

The Conform

With the media all in place, we conformed it using the XML file method mentioned above. Actually we also tried using the offline EDL as well, just for the hell of it, and the results were the same either way. We conformed the offline movie in tandem, and used this to ensure the online version matched exactly. We also imported an offline audio track which we could easily toggle on or off during playback.

One of the oddities about Scratch is the way it organises timelines. It’s a bit of a learning curve, and it’s something I have to reacquaint myself with every time I use it. Basically, Scratch takes a grid-like approach to the timeline. Horizontally, slots are akin to a regular timeline (think Smoke in “Storyboard” view). Vertically, slots store multiple versions of a shot, typically different takes for a shot, or even different grade versions. The problem with this is that you’re not really getting truly independent multiple timelines. For example, in Final Cut Pro, adding an extra video track gives you the ability to slip/slide shots on that new track independently from other tracks. It’s strange that Scratch doesn’t have that capability, but perhaps it’s something that will be addressed in the future.

It’s at this stage when you realise that not everything goes 100% smoothly all the time, and there were a few shots that were the wrong take and some transitions that had gone wrong (more likely due to errors in our EDL than with Scratch itself). In addition there were render errors caused by the de-interlace process that had to be corrected. These were fairly easy to fix though, especially given that Scratch has one of the best editing interfaces of any digital intermediate system, allowing changes to be made numerically or using the mouse directly.

Finally, we went through the timeline, applied any necessary flips or flops, and resized the DVCAM footage to match the HDV resolution. We also put Scratch’s excellent stabilize module to use to good effect where it was needed.

The Grade

Scratch offers a comprehensive set of grading tools (especially with the Scaffolds option loaded), and there was nothing particularly special about how we did the grade (barring the pre-grade mentioned earlier). It was simply a matter of balancing the shots to provide continuity (as much as the latitude would allow), and then making little tweaks. (Interestingly, the HDV footage maintained rather a lot of latitude, especially compared to the DVCAM footage, which I found very surprising- making the HDV images vastly superior to the DVCAM ones). Scratch has a nice histogram overlay that can be toggled on or off to check for things like clipping and crushing of colours (unfortunately we did not have the necessary equipment to output to external scopes, so this came in very useful). We then spent some time in the Scaffolds portion of Scratch, just enhancing mood on some shots by adding shapes to darken or lighten key areas as needed. Different versions of grades could be saved for each shot (these would be added vertically to the slot), or even at a more global level, into a “tray” in the user interface.

Finishing Up

With the grade complete, we switched to Scratch’s processing section and added some (very subtle) effects such as glow. In here we could also switch between different resize algorithms for the shots that required some degree of resizing and repositioning. Again these can be saved with multiple versions, which is a great touch.

The last thing that remained was to play through the picture and render it out. We also checked for title safety using the guides (strangely the guides did not show up on the secondary display) built into Scratch. At this point we noticed some other render errors in the source data we hadn’t noticed earlier, but proceeded with the render anyway. The errors were then fixed in the rendered output directly using Combustion.


At this point, the picture is complete and ready to be tied together with the audio and credits roller and then mastered to the required formats. We will also be backing up to LTO3 tape, which is as close to an industry standard as anything else right now; at ten minutes running time, the whole thing should fit quite comfortably on a single tape.

Posted: June 21st, 2007
Categories: Articles
Tags: , , ,
Comments: No comments