FOSDEM '08 is a free and non-commercial event organised by the community, for the community. Its goal is to provide Free and Open Source developers a place to meet.

   

Interview: Robin Rowe

Thu, 2008-01-17 21:48

Gabrielle Pantera and Robin Rowe will present Tux with Shades, Linux in Hollywood at FOSDEM 2008.

Do you have a main goal for your talk?

To entertain and inform. We expect to have fun!

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.

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:

  1. 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.
  1. 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.
  1. 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.
  1. 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.)
  1. We care about automation and interoperability features such as macro-recording, scripting, networked and shared-memory operations with multiple tools.
  1. 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.

Sounds pretty impressive... In one of your Linux Journal articles, you described the Linux platform in use at DreamWorks Animation studio. However, from the application software point of view, it appears that more of the software is being 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 is explained in one of the questions below.

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.

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 about whether code is GPL or LGPL, I can't fix that without rewriting the code. When I write open source code I license it BSD.

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.

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.