Hollywood, Linux, and CinePaint at FOSDEM 2008

By Robin Rowe

As keynote speakers, Gabrielle Pantera and I (Robin Rowe) are presenting Tux with Shades, Linux in Hollywood on February 23rd at FOSDEM 2008 in Brussels. Philip Paeps of FOSDEM asked that we answer the following questions.

1. Could you briefly introduce yourself?

Gabrielle and I are partners in MovieEditor.com, founded in 1999. We're co-founders of the 2,200-member filmmakers association ScreenPlayLab (www.screenplaylab.com). I'm the project manager for CinePaint (www.cinepaint.org), a popular open source motion picture retouching tool that's the same type of application as Photoshop. I write for Linux Journal. Gabrielle writes for the newspaper British Weekly. My background includes being chief technologist at a Fortune 500 defense company, a navy research scientist, and teaching software design at two universities. I've worked for NBC as a technical director and had an office on the lot at DreamWorks Animation. I work on television, film and live events such as COMEDY WALK. Gabrielle works at a film production company making major movies.

2. What will your talk be about, exactly?

We'll talk about Linux in the motion picture industry, especially its use at the major studios. This community is an upside-down parallel universe where Linux is everywhere, and Windows and Mac are niche operating systems. We'll talk about how the movie Titanic touched off a mass migration to Linux, what Linux tools are used and how. The result is virtually every blockbuster or animated feature in theaters today is made using Linux tools.

Every major studio and many minor ones are using Linux for visual effects and feature animation. Linux-based studios include CFC-Framestore, Digital Domain, Disney/Pixar, Double Negative, DreamWorks Animation, Flash Film Works, Hammerhead, Industrial Light & Magic, the Moving Picture Company, Rhythm & Hues, Sony Pictures Imageworks, Tippett Studios, Vanguard Animation, Weta, Wild Brain, and more. Why is Linux #1? How does an industry convert in mass to Linux in the midst of production? Which distros and kernels do they use?

At first, studios had no choice but to develop Linux applications in house. The film industry has millions of lines of Linux code, both desktop applications and server pipelines. Studio Linux programmers write code in C++, Python, Perl, and Java. What does all this secret proprietary Linux code do? And, why do they do parallel programming with grid computing? How does the film industry use renderfarms with thousands of CPUs?

Studios no longer have to develop their own tools. They can buy the Linux tools they need off the shelf. Commercial Linux motion picture tools available today include Combustion, FrameCycler, Houdini, Maya, Mental Ray, Nuke, Piranha, Platform LXF, RaveHD, RenderMan, SoftImage|XSI and more. What are all these tools for and where did they come from? What do they cost? How did a vibrant commercial Linux applications market emerge in this industry, and why nowhere else?

The film industry has funded open source development. CinePaint, Wine, and FLTK are open source projects that have received financial support from the film industry in the past. FLTK was developed at Digital Domain to support their proprietary application development and then released LGPL. What kind of crazy open source world is this where copyright zealot Disney funds development of LGPL code in Wine to replace Windows? Why isn't the film industry doing more to support open source development?

3. What do you hope to accomplish by giving this talk? What do you expect?

To entertain and inform. We expect to have fun!

4. How does CinePaint differ from plain GIMP, apart from higher fidelity?

CinePaint is software for painting and retouching sequences of high fidelity (more bits per pixel) high dynamic range (can go brighter than a white sheet of paper) images. If you're a film studio or pro photographer you have to choose CinePaint over GIMP because GIMP can't open your high fidelity images without crushing them. High fidelity and HDR images are not normally encountered outside of the film, pro photography and print industries. You won't see these images on the Web because the files are very large and monitors lack the color fidelity to reproduce them. Film has more dynamic range.

Because you asked and since I'm the project leader, I'll go into more detail on CinePaint here. We're not planning for CinePaint to be the focus of our talk at FOSDEM, which is the much broader topic of Linux in the film industry.

The core feature GIMP and CinePaint have in common is the clone brush. That's a tool that copies pixels from one area to another to retouch an image. GIMP and CinePaint, despite outward similarities, are different internally. CinePaint has a high fidelity image core. CinePaint handles 8-bit, 16-bit and 32-bit per channel HDR (high dynamic range) images. GIMP has only an 8-bit core, but has more features and bells-and-whistles. GIMP is typically used on JPEG, PNG, and 8-bit TIFF images. CinePaint is typically used on DPX, EXR, and 16-bit TIFF images (and also supports JPEG, PNG, etc.).

The CinePaint project adopted software that was a forgotten fork of GIMP. That fork was created by some GIMP developers in 1998-1999 with funding from the film industry. I was only slightly aware of it. It wasn't until 2002, while writing an article for Linux Journal, that I noticed Film Gimp in use at a studio. I got a copy of the source code and played with it. When my article came out, readers wrote asking me for the code. Then people started sending me patches. I made the code available to everyone through SourceForge. The GIMP clique became quite upset with me, an outsider, releasing software they thought they'd buried in 2000 when they proposed creating GEGL instead. Some are still angry that I'm giving away free open source software that they wish forgotten.

5. Can you compare CinePaint's Glasgow architecture to GEGL?

I've never been a member of the GIMP or GEGL projects, so I can only comment on those as an outsider. The GEGL architecture is a node-based image processing library. Its implementation details have changed significantly since the original GEGL proposal in 2000, with each new GEGL technical lead, but the concept remains the same. GEGL is quite different architecturally from GIMP. The GIMP architecture is a tile-based framebuffer with executable plug-ins that communicate over a library-based "wire" protocol to manipulate frames.

The Glasgow architecture is an evolution of the GIMP architecture. Glasgow takes into account several design premises that were not true when GIMP was designed and that go beyond GIMP's mandate:

a.) We care about high fidelity images (more bits per pixel) and high dynamic range images (brighter than white). We accept the more complex core architecture necessary to deal with multiple bit-depth images. HDR images are becoming less exotic all the time because digital pro photography uses them now, too.

b.) We care about exotic features specific to the film industry and pro photographers such as movie flipbooks, HDR, bracketed composite images, 16-bit gallery-quality printing, CMS, Z-depth, and exotic image types such as RAW, CMYK, and XYZ.

c.) We care about maintainability and debugging. The plug-in wire protocol needs to be transparent. Rather than use variargs (which is what GIMP uses to marshal data to plug-ins) we like ASCII strings and direct memory access.

d.) We care a lot about performance. We have bigger images to process. One 2k resolution DPX image is 12MB. A 90-minute film has 130,000 DPX frames, a total of 1.6TB of data. We have more to gain from running faster. One way to go faster is to load more into memory at once. (In the nineties when GIMP was designed, memory was precious and had to be conserved no matter what the performance cost.) Another way to go faster is to make plug-ins DLLs. (GIMP runs each plug-in in its own process space.)

e.) We care about automation and interoperability features such as macro-recording, scripting, networked and shared-memory operations with multiple tools.

f.) We care about renderfarm grid support to perform operations on many images simultaneously in a headless environment, not just one user modifying one image at a time in a GUI.

6. In a recent article in Linux Journal, you draw a nice picture of Linux platforms at DreamWorks Animation studio projects where Linux is used extensively for computing power. However, from the application software point of view, it appears that most of the Linux code is custom written and kept proprietary. What are the reasons these companies don't embrace open source for their applications as well?

First, studios no longer have to write proprietary Linux tools. DreamWorks Animation was a Linux pioneer. Reasons for studios to build their own tools today are the competitive advantage in having better tools than your competitors or that you simply don't believe others can make the best tools for your needs.

The studios attract the best software designer talent on the planet. The work is very sophisticated. Open source studio application projects don't have the resources to compete with the internal and commercial tools that studios have. More on that under question #8.

Studios have tried to support open source. CinePaint exists because the film industry funded some GIMP development in 1998 and 1999. That GIMP never released what the film industry funded didn't help the open source cause. If CinePaint could have been released as GIMP 2.0 in 1999, things might be different today.

As the popularity of studio Linux demonstrates, Hollywood is a Darwinian system where nothing succeeds like success. There could be a lot of film industry open source application development happening today if it was proven as "better, faster, cheaper" than keeping a hundred expensive Linux application programmers on staff.

7. Companies often want to protect their custom algorithms and adaptations. Does this sometimes conflict with the licenses of open-source software packages?

Not really. Most studio code is internal secret stuff that's not for release. Where open source is modified only for use by yourself, typical open source licenses don't require you give your changes back.

Studios are reluctant to touch anything GPL. It's hard to justify the legal expense of checking for GPL compliance. LGPL or BSD-licensed is much easier because lawyers don't need to become involved in the software development process.

CinePaint is the only significant instance where studios took an open source GPL program and brought it in house to enhance it and release it back to the open source community. The FLTK GUI library was developed at a studio internally and released LGPL, but that's different because it's their code. They can change the license as they wish.

The one who the GPL disrupts most is me, the open source project leader who adopted unloved GPL/LGPL code. I can't take GIMP GPL code and move it into an LGPL library or vice versa. Where GIMP made bad design choices which code is GPL or LGPL, I can't fix that without rewriting the code. When I write open source code I license it BSD.

8. Are you satisfied with the rate of improvement of open source applications?

Are you kidding? The lack of resources in money and expert developers is totally frustrating. It's almost impossible to get anything done. Because I don't employ CinePaint developers I can't really direct them. Everyone delivers what they want, when they want. Because I have to do other things to earn a living, I can only moonlight on CinePaint as time permits.

DreamWorks Animation employs over a hundred Linux programmers. Not students. Not amateurs. Not moonlighters. A studio can and will put a dozen professionally managed highly paid full-time expert Linux programmers on a project. Almost no open source project can do that.

9. Which are the most popular open-source applications in the animation/cinema world?

CinePaint.

10. Can you actually see in some films with which tools they're generated? Do filmmakers include visual or audible Easter eggs?

Have you noticed there have been a lot of penguin movies lately? ;-)

I've heard that sometimes artists sneak tiny penguins into the background of a scene where they don't make any sense as an insider Linux joke, but there isn't much time for pranks. People are working long hours to finish the film to the highest standard they can. The goal is to make the tools transparent, to make sure the audience doesn't look at the movie and think, that's not real.

Talkback: Discuss this article with The Answer Gang

---

Robin Rowe is the executive producer of COMEDY WALK, the project leader of CinePaint, a co-founder of ScreenPlayLab, and the founder of an association of film industry Linux users, LinuxMovies.org.

Robin writes for Linux Journal about the motion picture industry, where Linux is the #1 operating system for animation and visual effects. He's a sysadmin for a Hollywood soundstage. He's worked at DreamWorks Animation in technology R&D. He's taught C++ software design at the Naval Postgraduate School and at the University of Washington. He helped build the robotic studios at NBC-TV Chicago. He was a technical director for broadcast news at a mid-market NBC-TV station.

Robin went to sea on the aircraft carrier USS Lincoln and on the flagship USS Coronado to field test systems he created while chief technologist at Fortune 500 defense company SAIC. He's designed software for the Pentagon, the Navy, NORAD, SPAWAR, and the White House. He's a partner in MovieEditor.com and does consulting on special projects.