> it is going to be a tough act to follow robin rowe and cinepaint.
> gimp-1.0 rox!

Should I feel flattered that GIMP can't stop talking about me and CinePaint,
even when it is to spread the misconception that CinePaint is GIMP 1.0?

GIMP people have demonstrated a persistent interest in expressing their
opinion about CinePaint and giving me unsought advice since I became the
CinePaint project leader in 2002. For the benefit of those who seem confused
about the difference between our projects, I would like to share CinePaint's
long range roadmap and explain why GIMP isn't part of it. In addition, I
will address some common misconceptions GIMP folks have repeatedly stated
about CinePaint.


- Deep paint including support for exotic bit depth formats. We've supported
16-bit integer and 32-bit floating point for a long time. Recently, we
implemented 16-bit binary fixed point, another bit depth format widely used
in the motion picture industry. One reason deep paint matters in pro work is
film has greater dynamic range than monitors. Deep paint images clipped to
8-bit will look fine on monitors (which can only display to 8-bit) but can
show visible defects when output to film.

- High dynamic range (HDR). We can read and write OpenEXR, an open source
HDR format provided by ILM. We're adding paint features to better support
HDR capabilities. HDR is to images what headroom is to audio. Without HDR an
image clips white at 1.0. Colors in flames and other highlights can be lost,
turn gray if the image is later adjusted back down again to be darker.
HDR paint can repeatedly adjust image intensity without color loss.

- Roto and vector 2D paint. CinePaint (and GIMP) are raster paint programs.
CinePaint can be used for rotoscoping, but the lack of vector 2D paint
support (especially splines) hampers that. Good vector 2D support is also
needed for our new slideshow feature, described below.

- 3D paint. CinePaint is used as a texture paint tool to support work with
3D packages such as Maya. We seek to have closer integration, be able to
preview or even paint 3D in CinePaint using OpenInventor.

- Colorspaces. CinePaint (and GIMP) only have RGB support now. We've begun
work to implement CIELAB and CMYK. We want to add XYZ, sRGB, and scRGB.

- Color management. We want output on film that matches what users see on
monitors, to support precision and artistic control in how colors are
displayed. We have recently implemented color management for 8-bit depth,
but found the screen performance too slow. We have begun to overhaul our
GIMP-based paint core to make CinePaint fast enough to handle CMS

- World-class GUI. Our goal is to offer a user interface superior to

- Slideshow feature. We want to offer an alternative to PowerPoint. We have
a new slideshow feature built into the movie flipbook in CinePaint.

- Compositing and effects. We want to offer an alternative to Apple Shake
and Adobe AfterEffects.

- Video editing. We want to add a flatbed film-style video editor including
sound and support for transcoding to popular video codecs such as MPEG, DV,
QuickTime, AVI, and MJPEG. We want to offer an alternative to Adobe
Premiere, Apple FinalCut Pro, and Avid Composer.

- High performance. We're developing a command-line tool with no GUI,
something like ImageMagick 'convert' but to use CinePaint plug-ins. Our
'img_img' tool is intended initially for fast image file format conversions
on renderfarms and came out of a major studio. For performance, img_img uses
a scanline-based architecture. It's plug-in architecture is a totally new
API I developed, and unlike the CinePaint and GIMP tile-based APIs. In
keeping with our strategy of maximizing our compatibility across
applications (e.g., GIMP, Photoshop, AfterEffects) we will enable img_img
plug-ins (such as our new img_img JPEG2000 plug-in) to work in CinePaint,
and tile-based legacy CinePaint plug-ins to work in img_img. CinePaint seems
likely to evolve into a scanline architecture more like Shake.

In 1998 the film industry decided to help GIMP by sponsoring development of
deep paint. To enable GIMP developers to understand motion picture
technology they were brought into the industry, given first-hand experience
working at desks at film companies. GIMP maintainer Yosh Singh started as an
intern at Silicon Grail and later became an employee. He did not accomplish
his employer's mandate to build and release deep paint as a feature in
mainline GIMP. After a year or so gaining experience in motion picture
technology Yosh left Silicon Grail to go to LinuxCare. What he's done since
I don't know.

I once asked the current GIMP developers what qualifications they have to
develop high end graphics software. The answer given was to point me to GIMP
as their signature accomplishment. Sven Neumann has said on this list that
he is offended because we have never sought his advice in how to implement
CinePaint. I have taught computer science at two universities and worked as
software designer most of my life. When I need technical advice on graphics
software design I turn to experts at ILM, DreamWorks, Disney, Sony Pictures
ImageWorks, Rhythm & Hues, and other studios. Their proprietary in-house
development is vastly beyond anything the GIMP developers have ever worked

GIMP has said since 2000 that someday it will support 16-bit deep paint.
Sven and Yosh have said that CinePaint developers are wrong to continue
building upon CinePaint's deep paint implementation (which is 32-bit and
considering 64-bit), that we should stop our work to help GIMP catch up in
this area. You are still trying to complete your GEGL 2-year roadmap from
the year 2000. Technology has changed significantly since 2000. To the
limited extent you have revealed your plans, they seem out of touch with the
current graphics landscape.

To put it bluntly, you haven't said what you guys are doing for long term
vision. Besides 16-bit deep paint, is there anything you have planned that
could match CinePaint?

Does GIMP have a long term roadmap?


GIMP advocates suggest that CinePaint is fundamentally flawed for being
based on GIMP 1.0.4. It is true that CinePaint was branched in 1998 from
GIMP 1.0.4. But, then so did GIMP 2! GIMP 2 is not a total rewrite. Both
programs derived from GIMP 1.0.4. Furthermore, both GIMP 2 and CinePaint
contain some code from GIMP 1.2. CinePaint has adopted code from other
projects than GIMP, such as gimp-print, LCMS, Dillo, and ImageMagick.
CinePaint also contains new code written from scratch.

GIMP advocates suggest that GIMP developers should resent duplication of
effort between our projects. First, it isn't your business how we choose to
use our resources. Second, we don't rewrite code pointlessly. Third, there
is very little duplication of effort between our projects. CinePaint simply
adopts any code from GIMP that we like. What could cause resentment is we
won't adopt all your code because we don't like all of it.

GIMP advocates suggest that CinePaint is a temporary stopgap for a future
release of GEGL expected to occur at some unspecified date. Whether GIMP is
a stopgap for GEGL is your call, but CinePaint is not a substitute program.
People who use both CinePaint and GIMP, including myself, understand why
they are not substitutes for each other. As CinePaint matures it will tend
to encroach more on GIMP's turf as a Web tool, but our design focus
continues to be the high end. The software we seek to surpass is Photoshop.

GIMP advocates say they hope that CinePaint will cease to exist. Some GIMP
advocates express hope that our developers will be reunited, that everyone
will work for GIMP. However, what was never united cannot be reunited. We're
not former GIMP people. Our current team was never part of your group.

GIMP advocates who have never had any relationship to me are telling me that
I owe them labor and should do as they say. Why accept your management?
GIMP's record with project management is a sore point I've been asked never
to bring up again on the GIMP lists. My project management experience
includes being an enterprise manager at a Fortune 500 defense IT company.
I've led R&D projects funded by motion picture and television studios,
DARPA, the Pentagon, and the navy.

We're glad to reuse bits of your code when it meets our needs and to work
cooperatively when it doesn't interfere with our goals.


[EMAIL PROTECTED]   Hollywood, California
www.CinePaint.org   Open source motion picture image editing software

Gimp-developer mailing list

Reply via email to