> 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. CINEPAINT ROADMAP - 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 responsively. - World-class GUI. Our goal is to offer a user interface superior to Photoshop. - 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 a 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 on. 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 MISCONCEPTIONS ABOUT CINEPAINT 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. Cheers, Robin ------------------------------------------------------------------- Robin.Rowe@xxxxxxxxxxxxxxx Hollywood, California www.CinePaint.org Open source motion picture image editing software