Making it big in Hollywood is tough, but moviemaking professionals have readily accepted CinePaint in the past few years. This image retouching program is a reworking of an unmaintained spin-off of The GIMP, the open source world's alternative to Photoshop.
On the code level, while CinePaint retains roots to The GIMP, it has evolved along a different path. For example, a major studio has contributed code for a new image core called
img_img. That developed as a command-line tool similar in purpose to ImageMagick's
convert. The CinePaint developers want to replace the tile-based GIMP-derived core with this new, high-performance raster-based engine designed for use on studio render farms. This change will also bring a new channel architecture that supports CMYK, RGBAZ, and any other image structure desired.
The team is currently adding vector paint features. Unlike raster paint — that behaves like spray paint — vector-based geometric figures can be picked up and modified after being drawn. There's already a PowerPoint-like slideshow mode that shows off vector-based slides, but the main purpose of vector paint is to improve rotoscoping capabilities in CinePaint. Rotoscoping is a spline-based special effects painting technique used for effects such as the light sabers in Star Wars. Vector paint will give CinePaint the capability to create similar effects easily.
The architecture and feature-set of CinePaint continues to evolve to meet the particular needs of a specific niche of users: image editors and special effects artists working in motion picture film, a medium which requires a high degree of image fidelity. Beyond that core market, the team also adds features necessary for professional printing, another market The GIMP doesn't serve.
|Linux/Unix System Administration Certification -- Would you like to polish your system administration skills online and receive credit from the University of Illinois? Learn how to administer Linux/Unix systems and gain real experience with a root access account. The four-course series covers the Unix file system, networking, Unix services, and scripting. It's all at the O'Reilly Learning Lab.|
Effects artists have used it to clean and touch up footage for major, special-effects-filled Hollywood studio movies that include The Last Samurai, Elf, and 2 Fast 2 Furious. In February, the studio Flash Film Works won the Visual Effects Society Award for Best Supporting Feature Film Effects for The Last Samurai. Part of the work Flash Film Works did on that movie was to add flying arrows to the battle scenes using CinePaint.
CinePaint started as a development version of The GIMP, sponsored by the film industry in 1998. The GIMP evolved in a different direction, though, and The GIMP team abandoned the code to languish in CVS. As an example of what CinePaint developers call the "Lazarus effect," useful open source projects never need to die. Though Film GIMP never saw a public release, the current CinePaint team came together, resurrecting and renaming the project. Development continues to this day.
Robin Rowe, the project leader, became involved in reviving Film GIMP when he researched and wrote a Linux Journal article about Film GIMP use by a special effects company. The 43-year-old Hollywood programmer consults for the movie studios and also leads the Linux Movies Group, a user group for those who work with (or anyone interested in) Linux-based motion picture technology.
Because building Film GIMP from the CVS was difficult, Rowe decided to help out when readers of his article asked for a source tarball or RPM files. The GIMP development team did not publicly support Film GIMP as a priority, so Rowe "suggested putting the tarball up myself, and everyone agreed that could be best."
From there, Film GIMP finally made its official launch on, fittingly enough, American Independence Day — July 4, 2002. Then other developers came out of the woodwork: Sam Richards, an employee at Sony Pictures Imageworks, emailed Rowe and revealed that his company had been using Film GIMP for a year. Not only that, they had fixed and improved the application, and were willing to contribute their work to the official code base.
The technical demands of motion picture and high-resolution photography tax or exceed the capabilities of either The GIMP or Photoshop. Photo retouching applications, including The GIMP and Photoshop, deal with 8-bit color images, and the latest version of Photoshop has good 16-bit capabilities. CinePaint, though, supports 8-bit, 16-bit, and 32-bit depths. Artists refer to the ability to manipulate color images of a broader range as "deep paint."
When it comes to motion picture color, "bits" differ from standard computer images: it's bits per channel, not per pixel. So a 24-bit RGB monitor is only an 8-bit device, and 16-bit color is the equivalent of a 48-bit RGB. "Motion picture film, and now theatrical digital projection, is capable of displaying 16-bits per channel of color. Monitor technology is not," says Rowe.
Color depth at the 32-bit range is more than the human eye can discern — at least, with current display devices, but he explains: "As with Hi-Fi audio, the point of so much 'excessive' quality is 'headroom.' When manipulating imagery, you want to have room to maneuver — not have to worry that your content will degrade perceptibly as you are working on it."
Photographers and publishers also benefit from the depth of CinePaint. "This is an important prerequisite to avoid artifacts in printed output. Catalogs can show more exactly what they represent. The human eye gets more stimulated by meaningful colors," says Kai-Uwe Behrmann, a 35-year-old programmer from Chemnitz, Germany. To bring the visual qualities of deep paint to high-resolution still photography, he ported the Gimp-Print utility to CinePaint so that it could handle 16-bit colors internally. The result is that printed photos under CinePaint exhibit smoother shading and higher contrast.
Thus far, the languages and libraries used in CinePaint have mostly come from The GIMP code. It's written in C and C++, and uses the typical image file format libraries, including LibTIFF and Independent JPEG Group. It also supports the open source OpenEXR format, developed by ILM for motion picture work.
Also, like The GIMP, it currently uses GTK+ for its GUI library. This has proved problematic on Windows, where GTK 1 does not work well. The current plan is to replace GTK with FLTK, building a compatibility layer to ease migration. Their initial experiments seem promising, but the developers have no schedule estimates in mind.
The CinePaint developers have updated the embedded Scheme interpreter, Script-Fu, and have added Python support. Java support is in the works.
"We're trying to strike out in a little different direction on embedded languages from GIMP because we have different goals, particularly with performance," says Rowe. "The GIMP plugin architecture is slow, but that isn't an issue for them because by our standards the typical GIMP web image is very small — say, 100K. A typical motion picture image is much larger — 1828x1102 and weighs in at 12MB. And that isn't just one image. A motion picture has 150,000 of them. Launching a new process and shuttling the pixels down a pipe as GIMP does isn't a very fast way to apply, for instance, a blur filter."
Therefore, the CinePaint plugin architecture uses threads rather than forks, resulting in plugins that work faster and scripting languages that can manipulate image rasters directly. To accomplish this, the CinePaint developers have had to recompile The GIMP plugins for CinePaint and "trick" them into running. "We have a plugin compatibility layer (PICL) that shims GIMP plugin code as-is into the CinePaint architecture," says Rowe.
This threaded processing runs only on the Windows version of CinePaint presently — for its other platform versions, CinePaint still uses the original The GIMP plugin system. "We compile identical plugin code to thread or fork depending on platform. We will be bringing threaded plugins to Mac and Linux, too. When that's ready, we'll throw a switch and recompile. It is backwards compatible," Rowe assures.
This meticulous approach enabled the CinePaint team to port the PIC image format plugin from The GIMP. Except for fixing some minor bugs, the code needed no changes to build under CinePaint as a threaded plugin.
The CinePaint team is developing new image file formats specifically for their application. For example, CPX will replace "the mutant version of GIMP XCF we inherited," says Rowe. "CPX is interesting because it has text tags and binary blobs. Unlike typical image formats, CPX is self-documenting."
While CinePaint is usable for low-level image manipulation, its developers remain committed to keeping their focus on its particular user niche.
"CinePaint was originally going to be the development path The GIMP project was going to take. We picked it up. Any changes we have made, and will continue to make, are based on what is best for our target audience, the motion picture studio artists," says Andrew Prock, another key CinePaint developer.
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.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to LinuxDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.