Film Gimp Project Renamed to CinePaint

ubiquitin writes "To avoid confusion with the GIMP, the Film Gimp project has renamed itself to CinePaint. The project is essentially a legitimate fork of GIMP, and is focused on image manipulations for moving pictures." We've mentioned Film Gimp several times lately; it'll be even handier as programs like Cinelerra and Kino grow more polished.

Comments

CinePaint? Kind of bland ...

[moonbender]

CinePaint? Not exactly a creative name. Out of the names mentioned as candidates in the press release, Film-Fu is easily the funniest. But I guess being funny isn't exactly what they wanted to achieve for "the most popular open source tool in feature motion picture work" ...

Re:CinePaint? Kind of bland ...

[DrPascal]

CinePaint is a "producer friendly" type name, and it sounds like it fits pretty well.

Put features in the mainline GIMP!

[Speare]

Too bad for the GIMP.

A lot of people had been hoping to see a backporting and/or merge between these two versions. This sounds like the architecture's going to be mainly irreparable.

Some people would really like to see deep color channels and stronger tools for doing compositing work on movie frames.

The more that digital cameras offer 12bpc RAW mode, the more the OSS world is lacking until GIMP can handle them well. Color corrections can and should be done with more bits, to avoid losing fine color integrity.

Forks like this can be good

[for(;;);]

Cloning a project, forking a project with essetially the same goals but under different management, can be bad. In Linux distributions, for example, we have the same features implemented many different, annoying ways.

A functional fork, to coin a term, is different. At my company, we have several different version of our client software, all of which does basically the same thing in different contexts. We organize this by placing most common functionality in a shared library, and using different code for each context (email integration, web client, desktop client, et cetera.) The codebases have enough different functionality that different code should be used, with common stuff in its own sandbox.

This is a good way to go. It encourages the core code to be put into a generic library. Having a GIMP for single images and a GIMP for sequential images will move the developers to code in a way that maximizes reuse. They're not (really) competing with each other, so there's nothing to lose by sharing. And they'll each have their own space to work in, without having a poorly-overloaded interface for both single and sequential images.

Or, they could not share code, and it could suck. But the incentive is there for sharing, and the architecture of both systems would naturally improve.

Flamebait was my first reaction.

[Chuck Chunder]

After all GTK stands for GIMP Toolkit.

It's ludicrous for anyone outside the project to suggest a wholesale change from C/GTK+ to C++/QT. It's the people who work on the project who actually have to work with the code and it makes sense for them to work with what they are most familiar and comfortable with.

You will certainly not get "Better maintenance" or "rapid development" if you disenfranchise your developers. The "cool platform" and "more acceptance due to QT/KDE" just reek of KDE fanboy garbage.

If any of these theoretical reasons were practically significant then there'd be no need for a request to port GIMP. People would _want_ to use QT and Krita (or whatever) would be a significant app already.