[sane-devel] CinePaint and sane

Robin Rowe rower@MovieEditor.com
Fri, 8 Apr 2005 09:19:22 -0700


> 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 

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 

We're looking into adapting flscan to make it CinePaint-aware. Is flscan a 
good starting point for scanner support?

Robin.Rowe@MovieEditor.com   Beverly Hills, California
www.CinePaint.org - Open source digital motion picture software