What Is DCP?

A Digital Cinema Package is a specially designed collection file types defined by the Digital Cinema Initiatives organisation which was created by the major Hollywood Studios to standardise the distribution and playout formats for digital cinemas around the world.

A Simple Overview Of The DCP

• MXF File(s) containing the pictures in JPEG 2000 Codec & XYZ Colorspace.
• MXF File(s) containing the sound channels.
• A number of XML files identifying the elements of the film and how they should be played.

An example of a DCP’s file list.

Some of the things that confused me initially about DCP are – having separate picture & sound files, the choice of the MXF format and the choice to have separate XML files holding the whole thing together.

It does actually all make sense though.  Having separate picture and sound files is very practical for films, for example it means that different language versions can be produced without having to re-encode all of the pictures.  In fact, the DCP can also have a separate subtitle file as well.

MXF Wrapper Format

As a long time Final Cut Pro user (since Version 1) I was very unfamiliar with the MXF format apart from know it as the format that Sony uses in it’s XDCAM cameras that has to be “re-wrapped” as Quicktime before use in FCP.  This concept of wrapper formats is an important one in understanding the value of MXF.

You can think of it in terms of a book.  You could have a paperback copy, a hardcover or even an e-book.  All three can have the same content,the same words, but the wrapper is different and makes those words more or less useful in different contexts.

In media these wrapper formats work in very much the same way.  DV video can exist as Quicktime, AVI or DV Stream files and the content the “words” of the DV encoded video can be exactly the same.  Or take a piece of h.264 encoded video.  It could be wrapped as an MP4, DivX or AVHD.  Same content, but in the DivX form it might be hard to watch on an iPhone for example, because the video player doesn’t recognise that wrapper.

So why use a wrapper at all?  Well to put it in very simple terms, if you think about a feature film having around 150,000 individual frames in it, then transporting and playing 150,000 individual files can be a real pain (but more on that later).  So putting them in an appropriate wrapper format is really useful.

One of the big advantages of the MXF (Material Exchange Format) is that it isn’t tied to any one manufacturer the way that something like Quicktime is tied Apple (as an easy example).  Why is this important for DCP?  The DCP specifications are the underpinning for the huge worldwide investment in digital delivery and projection technology.

While there’s lot’s of formats capable of doing the job, MXF is one that’s been developed by the industry and won’t suddenly leave the industry with licensing problems in a few years time.

It’s also pretty agnostic about about platform and codecs, so it’s very flexible and it was designed from the beginning to be very good at handling the additional information that goes with a lot of content these days – Metadata.

JPEG 2000

Within the Picture MXF the images are encoded with intra-frame compression in the JPEG 2000 codec.  This is very different to the everyday  JPEG format that everyone uses with digital cameras an a vast proportion of the images in the web.

Visible DCT Blocking.

Garden variety JPEG uses a type of  DCT  compression which breaks the image down into blocks of pixels near each other that can be grouped together and colour values averaged.  This works on the principle that pixels near each other are often similar colours.

In simple terms, the bigger the blocks, the bigger the reduction in the amount of data used.  JPEG & DCT are great at getting good looking images down to file sizes that are a fraction of the original.  The mathematics behind the process, therefore the processing power and time needed to do the job are relatively modest.

The downside is that when the compression does become visible it is in the form of those blocks.  This is most noticeable in big areas of similar colours light the sky or a white wall, where one block averages one way and the adjacent ones go a different way.  Most people would now be familiar with how this looks even if they have no idea why.  The problem with this is that when it does become visible it is quite obviously an artificial effect.

JPEG 2000 is a whole different animal.  It uses Wavelet compression which is much more complicated both as a concept and to implement.  The upsides are that the quality is much better and on the rare occasions when it does degrade the image, the effects look much more natural and are therefore much less noticeable to the audience.

DCT Compression after 6 generations

Wavelet compression works on a similar principle to DCT in that it assumes that parts of the image that are close to each other are likely to be similar and can therefore be grouped to reduce the amount of information with a minimal effect on the image quality.  The clever thing about Wavelet Compression is that it does this by breaking down the image by the amount of detail or wavelet frequencies.

Wavelet Compression after 6 generations

So when Wavelet Compression does introduce artefacts into an image it does it by softening, and not even softening the whole image, just a particular band of detail frequencies.  So a highly compressed image using a Wavelet codec doesn’t show rectangular blocks and can still resolve fine detail.  On a 60 foot wide cinema screen, there is a whole lot of value in those two factors.

XYZ Colorspace

I’ve talked a bit about RGB Colorspace in my Secret World Of Colour Correction article and how it differs from the CMYK colorspace of the print world and how a weird mish-mash of the two is what we’re taught from early childhood is how colours work.  XYZ colorspace essentially takes RGB space and then refines it dramatically to match the way the various Rod & Cone “pixels” in our eyes actually combine to perceive colour.  So while RGB is a very electronic friendly way of capturing, controlling and manipulating colours, XYZ space is a very efficient way of presenting them so that they best match the human visual system.

XYZ Colorspace as it appears on an RGB screen.

XML

A DCP Asset Map XML

The eXtensible Markup Language has much in common with MXF in that it is an open, industry wide standard that is also highly flexible in being able to be adapted to different applications.

As markup language XML serves as a framework for adding more information into a document than the core text by marking it differently.  One of it’s most high profile implementations in the production world has been as the backbone of Final Cut Pro (pre FCP-X).

Like it’s brother  HTML is a simple way of recording and communicating information in forms that can be accurately interpreted by both the human eye.

So XML is a great choice for the files that identify the picture, sound & subtitle files and tell the projection system how to interpret them.

Making A DCP

So we know that a DCP is the gateway to the whole world of digital cinema, we know what the elements of one are and why they were chosen to work that way.  The elements are all readily and freely available, you can even export JPEG 200 straight out of Final Cut Pro using Quicktime conversion.  XML can be created in any text program.  So it should be pretty simple to manually create a DCP, right?

That’s what I thought.  Each of the many elements is in themselves pretty simple.

But getting each of them right, working together and then formatted correctly is to looking for a needle in a haystack what  designing a mission to Mars is to a game of chess.

I’ve been told that producers allow upwards of $20,000 for the creation of a single DCP.  And the complexity of making it all work does make sense of that price tag.

Enter OpenDCP

While new entrants have reduced the price of entry into DCP creation systems over the last few years from five or six digits down to the lower four digits, Terrance Meiczinger has been developing the OpenDCP software.  I’d been watching it for a while as it was a command line system, ie. you type in a series of text commands and then it goes off and does what you told it to (and hopefully you told it right!) the relatively recent addition of  GUI versions for Mac, Linux & Windows made me really sit up and take notice.  Now I’m not afraid of punching in a bit of code (after all I’ve written a successful package of colour grading plugins)  But the addition of the GUI versions took this a really practical level.

Open Source

There’s some genuinely amazing stuff coming out of the Open Source movement at the moment.  From the WordPress platform that powers this site to the Android mobile operating system and the Linux operating systems that power the actual digital cinema servers – Open Source is delivering some impressive software, often free and/or with completely new economic models.  OpenDCP could easily be the poster-child for this movement right now.  It has taken something that was essential for film makers in the 21st century but was prohibitively complex and expensive for most independent productions and made it relatively simple, cross-platform, high quality and there’s only one digit in the price tag… a zero.

The Process

The process of creating a DCP with OpenDCP is a small series of steps:

1. Create an Image Sequence from your digital master. This can be in the TIFF, BMP or DPX formats.
2. Create separate WAV files of each channel of the soundtrack.
3. Convert the image sequence to J2C (JPEG 2000) files in XYZ Colorspace in OpenDCP.
4. Wrap the J2C sequence into an MXF file in OpenDCP.
5. Wrap the WAV files into an MXF file in OpenDCP.
6. Create the DCP collection of files in OpenDCP.
7. Copy the files to a Linux EXT formatted portable hard drive.
8. Hand the drive to the projectionist.
9. Buy some popcorn. (optional)

The important thing to remember is that the scale of each of these steps is proportional to the length and resolution of your project.  By far, the most processor intensive and time consuming part or the whole thing is encoding to the wavelet based JPEG 2000 codec.  OnMcLean’s Money we tried this with an iMac and the two hour film was going to take nearly 4 days for this one part of the process!!  On a 12 Core Mac Pro this came down to an easily manageable 9 hrs.  Out of interest, we did try this on The Film Bakery’s one (admittedly low spec) PC and it was going to take just over 18 days.  So this is an area where raw processing grunt makes a very big difference.