Gerhard, > CinePaint has been branched off from The Gimp, hasn't it?
The CinePaint code was based on a GIMP branch that they forked in 1998 and later abandoned. Many people have presumed that the CinePaint team is an offshoot of the GIMP hackers somehow, even imagining that we're disgruntled former GIMP developers, but that's simply not true. When I launched our project on SourceForge in 2002 I knew no more about GIMP than anyone else in the Linux community. I'd never written any GIMP code or been part of their effort. Our project's strategy to base our work upon an abandoned GIMP CVS code branch was a reuse decision. It saved a lot of time in prototype development. And, we gained a small user community of high-end pro artists who'd been using the unsupported deep paint GIMP branch for years. Our design goals are quite different from GIMP. Philosophically, we have more in common with Scribus or GraphicsMagick. We embrace pro features such as 32-bit per channel color and CMS. GIMP's core users are editing 8-bit JPEG images for the web. CinePaint's core users are editing 10-bit log DPX images for the motion picture industry. Because we support the high-end, pro photographers who want 16-bit scanner support are coming to us. We work with 16-bit images now. CinePaint's legacy GIMP-based architecture has reached end of life. Development of a new architecture is underway. A highly visible change, we're switching from GTK1 to FLTK. Really everything's changing. Our goal is to release our new version, code-named Glasgow, by the end of 2005. I'm here to let you know we're ready to listen to suggestions on how to better accommodate sane and CMS in the new design, that now's a good time to think about implementation decisions. Have you thought at all beyond GIMP? > We currently support Gimp with the xscanimge plugin. Has this > plugin-interface been removed? Or is there any other plugin > interface available for CinePaint? The GIMP plugin interface is too restrictive. The new CinePaint interface is a shared memory framebuffer. Independent applications will be able to directly access CinePaint images in memory, not have to launch from within CinePaint. We're looking into adapting flscan to make it CinePaint-aware. Is flscan a good starting point for scanner support? Robin ------------------------------------------------------------------- [email protected] Beverly Hills, California www.CinePaint.org - Open source digital motion picture software
