CinePaint: The GIMP Goes Hollywood
Pages: 1, 2
Developer Interview: Robin Rowe and Andrew Prock on CinePaint
Can you give an example of how CinePaint's use in a real-world situation, such as for a major studio movie, has shaped its development?
Andrew: We have developers from the actual motion picture studios contributing code. That, combined with Robin's studio experience, helps shape CinePaint into being the right tool for use on motion pictures. More specifically, we are looking into a new file format to replace the version of the XCF file format we are using. Since the sizes of these images could potentially reach a few megabytes, our new format, CPX, is being designed with speed in mind.
Robin: CinePaint is used for dust-busting, retouching, any sort of hands-on task. You can think of it almost as a programmer would a debugger. It is more for fixing problems: Is there dirt on a scanned image? Is there a tear in a NURB on an animation render? Do you need to take out a wire-rig from a flying actor?
Studios have a whole suite of automated tools they use, but when something needs the human touch, there's CinePaint. It has been used in about a dozen films, such as Scooby-Doo and 2 Fast 2 Furious.
What have been the technical challenges you guys have had to work through in developing CinePaint?
Robin: The biggest technical challenge was the plugin threading, which was part of the Windows porting process. We didn't take the route of GIMP for Windows and emulate UNIX forks. Also, everything on Windows builds directly as a Visual C++ project. No command-line make files. No Cygwin.
When I became involved in CinePaint, I wanted to work on the GUI and other areas that could visibly use improvement. But, for the most part, it has been unglamorous integration and debugging work because that's where I'm needed. Because [work on] Film GIMP had been officially abandoned, it wasn't in the best shape when we picked it up. Just last month I cleaned up hundreds of compile-time warnings.
We launched July 4, 2002. The Windows and Macintosh ports were the big accomplishments in our first year. CinePaint for Windows is native, a simple and quick install. For the Mac port, we did an X11 Fink port, a bit of a cheat. I also lead the GTK+OSX project. We're porting GTK+ to the Mac, so we can build CinePaint as a native Aqua app. Until then, CinePaint for Macintosh is a bear to install.
Andrew: CinePaint was written using GTK+, and there is no native version of GTK+ for Mac OS X. In response to this challenge, we have spun off the GTK+OSX project to port GTK+ to the Mac. Currently, there is a pre-alpha build of CinePaint running natively using our latest GTK+OSX release. [This] version was built as a Mac OS X application bundle, making it a first-class citizen with other native Mac apps.
Any interesting challenges cropping up as you guys work on CinePaint's own file format, CPX?
Robin: Some are trying to press me to make CPX 100% XML compliant. I've heard a lot of good ideas, but most of them miss the point of what I'm trying to accomplish with CPX. There are more XML zealots than I had imagined.
We inherited the GIMP XCF image format, but that is deliberately undocumented by the GIMP team. They don't welcome its use in other programs. The XCF format in CinePaint has diverged and is incompatible with GIMP XCF. The original Film GIMP developers changed it to support high bit-depth. CinePaint XCF isn't maintainable, as is. Partly in reaction to the undocumented nature of XCF, I want to create an efficient image file format that is self-documenting. What I came up with was an extension of ideas in the PPM P6 format (a popular but very simple format). My idea was to embed XML-like tags — no magic numbers or binary metadata.
When I described how I'd been inspired by XML ideas, many responded that they were very excited about making CPX into pure XML. Some feel compatibility with XML tools is more important than any other consideration. The problem, of course, is that XML has no mechanism for embedding binary raster data. That would have to be text-encoded first, like an email attachment. A typical image raster in CinePaint is 12MB. The overhead of encoding that, instead of throwing it down as a binary blob, would be considerable.
Sven Neumann of The GIMP project posted a note on our CinePaint developers list recently to object to incompatibilities and confusion between 16-bit CinePaint gbr brushes and 8-bit GIMP gbr brushes. I responded that the situation was worse than Sven imagined, that our 32-bit XCF format is incompatible, too. However, we have a solution in sight — to migrate to a new format called CPX.
Sven expressed his opinion that I was missing the boat by not making CPX pure XML. He also revealed that GIMP had secretly been working on its own format to replace XCF. That caused some excitement in the GIMP community because that was the first they had heard of it. Nobody had gotten to see a proposal on XCF2. The upshot of all this is that GIMP XCF2 seems to be going forward as pure XML, very much the design so many recommended for CPX. Pure XML could be a good format for GIMP, a web graphics program typically used for smaller images. Our compile-time compatibility with GIMP plugins means both CPX and XCF2 could be supported by CinePaint.
The beauty of open source is that competing ideas like this can go forward in a compatible way. We don't have to reach consensus. Competing ideas can help drive both projects forward.
What contributions could your project use from outside volunteers?
Robin: We're glad to have any help. Here are a few specific wishes:
More testers. People often don't report bugs, but we have to know about bugs before we can fix them.
Somebody really good with
automake. Our build code we inherited from GIMP needs to be checked by someone who fully understands it.
Somebody to help adapt The GIMP FreeType plugin. Our text tool is a sore point.
More developers to adapt GIMP plugins, generally. And not just GIMP: We have a partially implemented PICL [plugin compatibility layer] for ImageMagick, too. Using their plugins could be possible, too.
Developers willing to work on anything, who even prefer being assigned tasks to build something to my specification. Fabio Marinelli in Italy is one, and it's great that he is helping take the load off me with tasks I would otherwise do myself. He's building several utility tools, one of them our new internationalization architecture to use instead of GNU
Andrew: We have a Developers Roadmap. This lays out some specific goals and tasks that we have set for ourselves, and everyone is invited to take part. Being a software developer is not a requirement — we've had artists contribute concept art for suggested enhancements to the UI, and others contributing to our documentation.
So what advice do you have for those who want to modify the CinePaint code, or develop a plugin for it?
Robin: Take an interesting GIMP plugin and adapt it to CinePaint. There are many — I keep a list — that haven't been ported from GIMP, or that, like Film GIMP, were abandoned by GIMP over the years.
If you want to modify code in the core, fixing a bug is a good start. In fact, that's a good start anywhere. Pick something small that needs fixing and start there.
Andrew: Take a look at the Developers Roadmap, and see if there are any specific tasks that interest you. For plugins, keep in mind that we deal in more bits per channel than GIMP.
For you personally, what have been the things you've learned while working on CinePaint?
Andrew: The community atmosphere on the project mailing lists has been invaluable to me. I've been able to learn some of the various qualitative aspects of software development from the more veteran developers on the list.
Robin: It has been a great experience for me! I do get tired at times. I work all day as a studio consultant, then "relax" at night and weekends with CinePaint, doing more software development!
The most valuable part for me has been the great people I have met working on the project. People like Sam Richards at Sony Pictures; Nathan Wilson at DreamWorks; Drew Hess at ILM; Andy Prock, our Mac port lead, now with Apple; Andrew Lau, our Debian maintainer; and too many others to name.
Return to LinuxDevCenter.com.