[sane-devel] CinePaint and sane
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