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

topic's

[slug359]

Hard to believe GIMP has a topic of it's own, despite the fact this is the first story in the topic for over a year (see here), when overclocking (which I'd love to filter without removing hardware!)/individual BSD's/P2P (including the RIAA/MPAA/*AA)/and so on don't have topics!

Re:topic's

[cascino]

The same goes for Mac OS 9. Yes, there is a topic for OS 9. Five stories have ever been published in this category, one of which is entitled "Apple Drops Mac OS 9."
On the other hand, Google is a topic-deserver: there's been five articles in the last month directly pertaining to it. And besides - we all use it, love it, and, as of recently, have made quite a bit of controversy about it.
Can there be a vote on these things, or at least a call for feedback?

The Gimps are always getting shafted

[robb0995]

Does this mean the developers have to park further away now?

Re:CinePaint? Kind of bland ...

[DrPascal]

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

This is uber cool!

[$$$exy Gwen Stefani]

Film Gimp (now SinePaint) has been used in tons of major motions pictures, such as the following:

Scooby-Doo, Harry Potter, Cats & Dogs, Dr. Dolittle 2, Little Nicky, Grinch, Sixth Day, Stuart Little, Planet of the Apes, Showtime, Blue Crush, and The Fast and the Furious II.

This is really cool. I used to think it was just another Open Source project where someone creates a SourceForge website and then abandons it two months later after no code is written.

Name change is probably a good thing...

[pongo000]

I mean, how much credibility do you expect from the outside world by giving your project a cutesy name like "GIMP"? Last time I checked, that was a slang term for a cripple, and a not-very-nice slang term at that.

Maybe "Cinematic Layout Imaging Tool" might have been more in keeping with the spirit of cute acronyms.

Re:Name change is probably a good thing...

[sean23007]

Cinematic Layout Imaging Tool? CLIT? Yeah, that would go over very well... Very cute.

Re:Name change is probably a good thing...

[llamaluvr]

The name "GIMP" kind of implies that the program isn't very good, I think. Like the program is limping behind Photoshop...

I respect the GIMP project, but calling it the "GIMP" is like naming a car the "Ford Lemon" or "Mercury Clunker".

Why fork?

[mcgroarty]

I don't doubt there are good reasons for it, but I'm curious no less...

Why fork?

Are there features going into CinePaint that aren't valid for GIMP? And the other way around?

It seems like both projects might benefit by staying more tightly coupled.

Re:Why fork?

[ocelotbob]

Essentially, the fork came from a different design philosophy and set of priorities. One of the big reasons was that the Film GIMP (now CinePaint) crew wanted support for 16 bit per channel color, something that the GIMP crew wasn't going to be getting around to until GIMP 2.0. While GIMP 1.3.x now has that support, CinePaint now has support for other color models, such as floating point colors. Also, GIMP is migrating to GTK 2.x, and CinePaint is still using 1.2.

Re:Why fork?

[Raphael]

Why fork?

Good question. The initial fork occured a few years ago, when a team of developers started to work on Gimp16 for adding 16-bit color channels into the GIMP. This was needed for editing films, but it was not appropriate at that time to integrate the new code into the core so this became a fork. However, the GIMP developers expected that the main GIMP code and Gimp16 (which was later called Hollywood Gimp, Gimp's Film Version and then FilmGimp) would converge later and that the core of GIMP 2.0 would support most of the features that were required for film editing (mainly 16-bit and floating point color channels). The user interface may have kept some differences due to the specific needs of film editors.

Unfortunately, for various reasons (political as well as technical), the gap between GIMP and FilmGimp widened a few months ago, soon after Robin Rowe took over the maintenance of FilmGimp and resurected the project that had not been very active in the last two years. There was some discussion about the fork on the GIMP developers mailing list in November and December last year (you can check the list archives here). The conclusion was that the FilmGimp developers were not interested in bringing their code closer to the current GIMP, and there are too few people working on GEGL (the library that should bring 16-bit and float channels into the GIMP) so it will still take a while before the main GIMP code is suitable for film editing. I am still sad about the way this whole thing happened. I tried to bring the two projects closer to each other, but obviously I failed.

I don't know how the future will look like. I wish the CinePaint developers good luck (honestly) and I hope that they will be successful. This fork of the GIMP suits the specific needs of the film industry and I hope that many studios will be able to use it and do great stuff with it. However, I expect that most people interested in photo editing, web design and general graphic editing will find that the GIMP is more suitable for them than CinePaint.

By the way, if you want to know some of the plans for the future of the GIMP, I suggest that you have a look at developer.gimp.org. In particular, read the plans for the future of the GIMP, posted in December 2000 but still valid. Besides this, the developers mailing list and the list of enhancements submitted to Bugzilla are good sources of information.

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.

Good Name

[Arc04]

I agree with them. CinePaint is definitely a much more professional sounding name than FilmGimp was and also more than the other suggestions.

If it had a name like FilmStudio, it would sound to me like an amateur effort (My First Film Studio?!?!), which we know it is not and would not have the success it will most certainly have in the future.

Well I like it anyway :P

Arc

My PC suggestion

[baywulf]

physically challenged film

Good

[shr3k]

The project is essentially a legitimate fork of GIMP

Good, because you know how bad the "support" costs can get when you fork illegitimate chil... errr.... projects.

Re:Legitimate fork?

[commodoresloat]

an example of a rogue fork is the spork.

Re:No thanks

[TheRaven64]

I was sure you posted something higher up implying that you actually had a clue as to what this program was. Obviously not. Film GIMP (sorry CinePaint) is 'a free open source painting and image retouching program designed to be more suitable for film work than GIMP or Adobe Photoshop.' (from the web site). It is a paint program, designed for editing and retouching individual frames in a movie, not a video editing tool. It is aimed at film studios, not at people like you. If you think iMovie would cut it in these situations then you are mistaken.

Tomorrow's headline

[enos]

To avoid confusion with the GIMP, the Film Gimp project has renamed itself to CinePaint.

To avoid confusion with MS Paint, the CinePaint project has renamed itself to Film Gimp.

While were at it...

[cybercomm]

Did anyone notice that the icon for gimp is ANIMATED (his eys move) is this me, or is this the FIRST animated gif on slashdot??

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.