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

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.