Hi, I am one of the R&H engineers working on film gimp. I have previously posted a message describing our short term plans for film gimp development. Unfortunately, we have not really had time to begin on any of these issues yet, but we are planning on starting within the next few weeks to a month. Please see my post at http://sourceforge.net/mailarchive/forum.php?thread_id=1271771&forum_id=10511 Regarding R&H's feeling towards gimp, filmgimp, and gegl: GEGL was initiated by Calvin Williamson, a former R&H engineer, but we are currently planning on using filmgimp in some modified form for the forseeable future. This is not to say that we would not welcome development of GEGL, but we do not currently have any resources allocated to it, nor do we plan to in the short term. As for merging gimp with filmgimp, that seems very unlikely to us. Even assuming that it could be done in a reasonable amount of time (i.e. a few months), it is not at all clear to us that this is desirable. filmgimp and gimp fulfill fundamentally different needs. The needs of high-end film production are quite different from the needs of web publishers, video editors, artists, etc. Programmer manpower is an expensive thing, and R&H allocates resources (Calvin, Caroline Dahllof, and myself) to gimp because it is a cost effective way of getting a suitable high-end paint tool. If filmgimp went in the direction of becoming a more general painting tool, it is entirely possibly that we would branch yet again and maintain our own "r&h" branch so that we can customize it as needed to meet our immediate day-to-day needs. This is not any kind of veiled threat-- it is the reality of r&h's relationship with gimp. gimp is a tool we will support to the extent that it meets our production needs. That said, the software engineer in me is slightly saddened by the fact that we are duplicating (some) efforts from the gimp programmers. I'm sure most of what is on our todo list is on the gimp's todo list as well (or has already been done). However, some of things on our list definately are *not* the same. For example, we are eager to remove the color & index modes we do not need for performance and cleanliness reasons. We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing. Obviously, for a general paint tool like gimp, there is no question of maintaining 8-bit support. For us, the need to maintain this kind of flexibility with the code and independence from non-high end feature requirements far outweigh any software engineering ideals. I hope this clarifies our position and bit and explains the current state of r&h's gimp plans. As always, please post comments or questions to (either) newsgroup. Jon Cohen > Merging both does not require the removal of features from either > tool. The added value of Film Gimp comes primarily from its 16-bits > support and its frame manager (and specialized plug-ins). But > unfortunately, it is based on an old core, which lacks many features > that are present in the current GIMP (not to mention the plug-ins). > If GEGL and the frame manager were merged into the current GIMP, then > everybody would win because any new feature or bug fix would be > immediately available to everybody. Currently, everything since the > original HOLLYWOOD fork has to be implemented separately in each tool. > > Note that merging Film Gimp and GIMP does not mean that everybody > would have to use the same user interface. The split between core and > UI that occured during the development of GIMP 1.3.x means that it > would be much easier now to create a slightly different user interface > that is optimised for working with films. Some features could be > hidden or accessed in a different way if they are not so useful for a > specific version of the user interface. > > > Of course, it would be great to build both tools on a single > > code base. But that's a bigger job than just merging the code, > > requires a wider range of skills, and (like everything else) > > is only going to happen if someone wants it badly enough to > > either do it, or pay someone else to do it. > > Sure, this is not an easy task. But a large part of it is planned for > GIMP 2.0 anyway. > > The two most requested features for the GIMP are CMYK support and > 16-bits support. Other popular feature requests are layer groups, > active layers (adjustement layers or styles), EXIF and others, but > they come far behind CMYK and 16-bits channels. So we will have to > add those features to the GIMP soon, probably by using the GEGL > library. Another feature that will be integrated in the GIMP soon is > a macro recorder (and playback). This is also on the Film Gimp todo > list. Same for the support for Python, which has been added to the > current GIMP. > > Some other features related to the user interface are also requested > from time to time. For example, some users would like to have an > MDI-style interface or at least have the image menu available on top > of the image. Some GIMP developers are against it, but personally I > would like to have this (maybe as an option) because this would make > the GIMP much easier to use for those who do not have a "decent window > manager" (e.g., Windows). Some of these things have been implemented > in Film Gimp. I would like to have them in the GIMP as well and I am > thinking about implementing them myself. But having two separate code > bases implies that any fixes or improvements implemented later would > have to be duplicated. It would be much simpler to avoid these > efforts by merging the code as soon as possible. > > So although merging the two codebases is not an easy task, I think > that a significant part of the work will have to be done for the GIMP > anyway. Working on this convergence as soon as possible would also > avoid the duplication of effort that is currently done by trying to > bring Film Gimp closer to 1.2.3 (instead of 1.3.x) and porting it to > Windows and other systems (which would be much easier if Film Gimp > could use the current code). > > Last, but not least, it would be very nice if the Film Gimp developers > would not try to increase the distance with the GIMP. For instance, > the following parts of the filmgimp.sourceforge.net web page could be > changed: > > - The "History" part is slightly incorrect in some parts. Among > others, it states that "The Gimp committee eventually unanimously > voted against Film Gimp." This is of course wrong, since it was > only decided that the merge would be done later. There has always > been some cooperation between the two teams (until recently, maybe). > In addition, there is no such thing as a "GIMP committee" and this > conveys an obviously inappropriate feeling of "us versus them". > > - In "The future of Film Gimp", the first goal is: "1. Keep the Film > Gimp Web SourceForge site updated (an unmaintained Web site exists > at film.gimp.org) [Done July 4, 2002]". Why has the site moved to > SourceForge in the first place? When I complained about some > unmaintained pages on www.gimp.org, I was given access to the site > after a while. Now I am maintaining it (until the new design is > ready). Did any of the Film Gimp developers ask if it would be > possible to update film.gimp.org and use that as the main site? > That would avoid much confusion and bring the two projects closer to > each other. > > - The "Mailing Lists" section states: "Both users and developers are > urged to use the new SourceForge list. The SourceForge Film Gimp > list was created in August 2002 after the Film Gimp mailing list > hosted at UC Berkeley went down for a month with no explanation." > Wouldn't it be more appropriate to say that *all* GIMP mailing lists > have been unavailable for some time because the server had to be > upgraded? As it is written now, it looks like some secret cabal had > tried to silence the Gilm Gimp developers. This is of course not > the case. > > - That paragraph continues with: "We have no control over the UC > Berkeley list or gimp.org. Likewise, we have no control over > film.gimp.org and the older CVS hosted there." The obvious question > is: why? Did anyone even try? Why is it necessary to criticize the > old site (or gimp.org in general) instead of trying to improve it? > > I think that more constructive discussions between the two teams are > really necessary. Widening the gap is definitely not the best > solution. When I see the overlap between the future features that are > planned in both projects, I can only think that continuing on separate > tracks will lead to a huge waste of resources. > > -Raphaël > > P.S.: I cross-posted this to both lists. Feel free to direct your > replies to one or both, as appropriate.
