On 27-Nov-2002, Raphaël Quinet wrote:

I have the feeling that the gap between GIMP and Film Gimp is widening more and more, instead of shrinking until the two versions can be merged in the same codebase. I understand that the development on the HOLLYWOOD branch has different constraints than the main branch and it would not be easy to attempt a merge for the moment (without GEGL), but I am a bit worried about the fact that Film Gimp seems to be diverging more and more.

One of the goals of Film Gimp is to "Bring the codebase up from 1.0.4 to rendezvous with Gimp 1.2.3". I think that it would have been better to aim for 1.3.x instead of 1.2.3. When GIMP 1.4 is released, the old stable branch (1.2.x) will not be maintained anymore (like 1.0.x now) so there is a risk that a version of Film Gimp aligned with 1.2.3 would be obsolete before its first release. Also, the next goal for Film Gimp is to add "Windows and native Macintosh support". I see on the mailing list that some progress has already been made and it is close to completion. But I think that a part of this work could have been avoided by choosing GIMP 1.3.x as a target, since it is based on GTK+ 2 and has native support for Windows.

Also, reading the web page and documentation of FilmGimp gives the (wrong) impression that GIMP developers are not interested in any future convergence of the two projects. While it is true that the HOLLYWOOD branch could not be integrated into 1.2.x, it has always been stated (or at least that's how I understood it) that GIMP 2.0 would be the end of the fork because the usage of the GEGL library would allow all Film Gimp features to be integrated into the main branch. This is not mentioned on the Film Gimp page, nor on the GIMP homepage, nor in the various articles that were recently published about these programs. That's a pity.

With Film Gimp gaining more momentum in the last months, I am a bit concerned about the duplication of efforts and the gap growing wider. On the one hand, the increase in activity around Film Gimp shows that the main GIMP is not addressing some of the users' needs adequately and maybe the developers (us) should pay more attention to that. On the other hand, it would be nice if the Film Gimp documentation was mentioning a future convergence with GIMP 2.0 (assuming that this is still a valid goal for Film Gimp).

I dont agree with the gimp and film gimp development groups. Film Gimp should be eventually folded into Gimp 2.0. Having two branches like this sucks bad. Film Gimp is slowly turning into something that isnt gimp at all, and I see alot of reinventing of wheels, or even parrallel development of the same code, because the development teams dont communicate enough. I agree with a lot of what you said, but in the end, its silly to have two branches like this.

From what I heard, Gimp originally declined a merge with the hollywood branch, which I see as a serious mistake. Gimp isnt photoshop, and it isnt any other program that people compare it to. Gimp is more than all of them. And thanks to FG, Gimp can become much more than it is now. But I dont see this happening unless people realize having multiple (uncompatible) programs like this is extremly bad.

I personally just want a Gimp that can load normal xcf files, and have an internal rendering path of more than 8 bits per channel as it has now. (Maybe single precision floats per channel? We could use GCC 3.2's experimental feature to use both the fpu and sse at the same time to do sp fp math extremely fast.) I tried Film Gimp, but as everyone as heard, the xcf plugin has... issues. And a GEGL enabled Gimp is so far off, it will be years before I see it done. As a heavy user and supporter of Gimp, I deserve the occational feature request, and my request is that higher precision rendering is added asap.

Hi,

Patrick McFarland writes:

I dont agree with the gimp and film gimp development groups. Film Gimp should be eventually folded into Gimp 2.0. Having two branches like this sucks bad. Film Gimp is slowly turning into something that isnt gimp at all, and I see alot of reinventing of wheels, or even parrallel development of the same code, because the development teams dont communicate enough.

the point is that the new film-gimp maintainer or any of the people working on film-gimp don't communicate with us at all. The project somehow came back to life without any notification on this mailing-list. We had to hear about it in the news. Among these news that appeared on the internet is a lot of wrong information. To me it looks as if the film-gimp people try to actively spread FUD about the gimp project.

From what I heard, Gimp originally declined a merge with the hollywood branch, which I see as a serious mistake.

this is exactly the wrong information I referred to above. The film-gimp web-site makes you think that the film-gimp people expressed an interest to merge and the gimp people refused to take this into account. This is just plain wrong.

It has always been the goal of the GIMP developers to merge the features needed for film-editing into the main GIMP. This has been a major subject on the GIMP developers conference. We were happy to have Caroline and Calvin at the conference who explained the concepts of GEGL as well as the needs of the film industry to us and I'm glad to see that they are still actively developing the GEGL library.

I also liked the idea of the new film-gimp project to make the HOLLYWOOD branch available to a larger audience. Building a reasonably functional tarball that everyone can build was a good thing to do. Now people have something to play with and can start improving the gimp core and GEGL so that the main gimp can have these features as well.

The direction the film-gimp project is taking at the moment seems like a wasted effort to me. That is my personal opinion and I have strong arguments for it but so far none of the film-gimp developers have asked for it and I will thus keep my arguments for me.

Salut, Sven

unknown@panax.com (2002-11-27 at 2219.52 -0500):

From what I heard, Gimp originally declined a merge with the hollywood branch, which I see as a serious mistake. Gimp isnt photoshop, and it isnt any other program that people compare it to. Gimp is more than all of them. And thanks to FG, Gimp can become much more than it is now. But I dont see this happening unless people realize having multiple (uncompatible) programs like this is extremly bad.

And from what I heard, the decision was the following path:

- 1.3-1.4: code clean ups and port to gtk+2, add new features that drop in without any problem. Port to other plataforms officially. Make the GUI a bit more logical, reuse keycombos, make common previews. All this should make the code suitable for the future, based in objects and so on. It should be something like all previous versions, but nicer in the surface and in the engine, but not a complete rework.

- 1.x-2.0: support colour spaces and bit depths, macro recording or anything that done for 1.4 would mean a lot of job. This would use GEGL, which should be ready at that moment, or at least the core part should. Gimp would become an user of the lib, an interface, maybe a full video processor tool, based in scripting (after all, videos are ordered lists of images, and basic video processing has already been done with perl). It could be seen as a complete rework, or maybe not, I hope all the GUI can be plugged on top of the new system.

The "merge" is 2.0, or more probably, there is no merge per se, cos future code should do it from the lower levels. Thus merging with 1.0 code that would be deprecated anyway would mean more caos than real help. As anyone can guess, working GEGL can be done now, while the main clean up is done in the 1.3.

The status of Film Gimp for me was "some people use it, they got something solved, and as program it is a nice experiment, next time we will do it in core, not as patch". If some other people need or what something else / more, fine, but no other of the rest have to follow.

issues. And a GEGL enabled Gimp is so far off, it will be years before I see it done. As a heavy user and supporter of Gimp, I deserve the occational feature request, and my request is that higher precision rendering is added asap.

And coders deserve the right to have a live, I guess. That is a natural characteristic of free time projects: they evolve as the people's mood and time allows. :]

If there is market, I suppose people could start a business about coding under contract and make everything go faster or port or wathever. If there is none, there is only accepting more strong limitations and go on as they allow.

GSR

On 28-Nov-2002, Sven Neumann wrote:

the point is that the new film-gimp maintainer or any of the people working on film-gimp don't communicate with us at all. The project somehow came back to life without any notification on this mailing-list. We had to hear about it in the news. Among these news that appeared on the internet is a lot of wrong information. To me it looks as if the film-gimp people try to actively spread FUD about the gimp project.

Hrm. Side note, They got $1k from Linuxfund to further their project... hrm...

this is exactly the wrong information I referred to above. The film-gimp web-site makes you think that the film-gimp people expressed an interest to merge and the gimp people refused to take this into account. This is just plain wrong.

oh. heh.

It has always been the goal of the GIMP developers to merge the features needed for film-editing into the main GIMP. This has been a major subject on the GIMP developers conference. We were happy to have Caroline and Calvin at the conference who explained the concepts of GEGL as well as the needs of the film industry to us and I'm glad to see that they are still actively developing the GEGL library.

I also liked the idea of the new film-gimp project to make the HOLLYWOOD branch available to a larger audience. Building a reasonably functional tarball that everyone can build was a good thing to do. Now people have something to play with and can start improving the gimp core and GEGL so that the main gimp can have these features as well.

The direction the film-gimp project is taking at the moment seems like a wasted effort to me. That is my personal opinion and I have strong arguments for it but so far none of the film-gimp developers have asked for it and I will thus keep my arguments for me.

Yeah, this is what I was trying to get at. Gimp 2.x is where all of us (gimp, and film gimp developers) should be going.

On 2002-11-28 at 1259.18 -0500, Patrick McFarland typed this:

Hrm. Side note, They got $1k from Linuxfund to further their project... hrm...

$1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly).

carol

On Nov 28 Carol Spears (cspears@cablespeed.com) wrote:

$1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly).

If any GIMP developers come to visit Research Triangle Park (Central North Carolina, USA) please drop me an email. I'd be happy to buy you a beer.

Steve

On 29-Nov-2002, Raphaël Quinet wrote:

On Thu, 28 Nov 2002 14:55:06 -0500, Carol Spears wrote:

On 2002-11-28 at 1259.18 -0500, Patrick McFarland typed this:

Hrm. Side note, They got $1k from Linuxfund to further their project... hrm...

$1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly).

That depends... If you consider those who write GIMP code on a daily or weekly basis to be the real "developers" and if you consider those (like me) who submit patches from time to time as "contributors", then I think that $1K would be more than enough to buy beer for all developers, unfortunately. I wish there were more developers...

On the other hand, if you divide $1K among all contributors, then we would all be very thirsty. ;-)

Yeah, but how many _film gimp_ developers are there? Less than a handful?

Wow. Sure is hot in here.

Some comments, from a gimp _and_ filmgimp developer:

I also regret any duplication of effort between the two. However, I'm not personally convinced that merging them is a good idea.

My feeling is that Filmgimp should be a tool specifically (or at least, primarily) for the film industry. It is very likely to develop along lines that are (at best) not useful to, or (quite possibly) totally unwanted by, the more general Gimp community. Remember, a tool that can do everything is seldom the perfect tool for one specific job. I don't think merging Gimp and Filmgimp will necessarily make either set of users happy.

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.

Hi all,

David Hodson wrote:

My feeling is that Filmgimp should be a tool specifically (or at least, primarily) for the film industry. It is very likely to develop along lines that are (at best) not useful to, or (quite possibly) totally unwanted by, the more general Gimp community. Remember, a tool that can do everything is seldom the perfect tool for one specific job. I don't think merging Gimp and Filmgimp will necessarily make either set of users happy.

A smallish delta between gimp 2 and film gimp will probably be inevitable. And given that several filmgimp people seem to be the primary developers on gegl at the moment, I'm sure that there's some idea how big that delta will be right now.

But we're not talking about one tool for lots of different jobs, here, so much as narrowing a rift that's developped while film gimp was basically only developped in-house by one company over the last 3 years. Things like getting the front-end looking similar, doing similar separation of core & gui typ[e work to that being done in HEAD right now (mostly by Mitch), and making sure that major structural and design changes at least get discussed wrt the two programs.

Does anyone know how big the functionality delta is between the GIMP 1.2 and the film gimp? Are there plans to get filmgimp onto gtk+ 2.0? Is there the possibility of bringing useful functionality back into the main gimp branch from the HOLLYWOOD branch?

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.

Of course it's a big job. The point, I think, is that it'll be an even bigger job by the time filmgimp is roughly up to the gimp 1.2 level, and gimp 1.4 is out on the shelves getting heavily debugged :) Of course, by that stage the emphasis will be on gegl, pupus and all the other cool stuff that's planned for 2.0.

In brief, though - what does the film gimp have that the main gimp doesn't have, apart from some extra cool and expensive plug-ins and 16 bits per channel?

Cheers, Dave.

On 29-Nov-2002, David Neary wrote:

Hi all,

David Hodson wrote:

My feeling is that Filmgimp should be a tool specifically (or at least, primarily) for the film industry. It is very likely to develop along lines that are (at best) not useful to, or (quite possibly) totally unwanted by, the more general Gimp community. Remember, a tool that can do everything is seldom the perfect tool for one specific job. I don't think merging Gimp and Filmgimp will necessarily make either set of users happy.

A smallish delta between gimp 2 and film gimp will probably be inevitable. And given that several filmgimp people seem to be the primary developers on gegl at the moment, I'm sure that there's some idea how big that delta will be right now.

But we're not talking about one tool for lots of different jobs, here, so much as narrowing a rift that's developped while film gimp was basically only developped in-house by one company over the last 3 years. Things like getting the front-end looking similar, doing similar separation of core & gui typ[e work to that being done in HEAD right now (mostly by Mitch), and making sure that major structural and design changes at least get discussed wrt the two programs.

Does anyone know how big the functionality delta is between the GIMP 1.2 and the film gimp? Are there plans to get filmgimp onto gtk+ 2.0? Is there the possibility of bringing useful functionality back into the main gimp branch from the HOLLYWOOD branch?

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.

Of course it's a big job. The point, I think, is that it'll be an even bigger job by the time filmgimp is roughly up to the gimp 1.2 level, and gimp 1.4 is out on the shelves getting heavily debugged :) Of course, by that stage the emphasis will be on gegl, pupus and all the other cool stuff that's planned for 2.0.

In brief, though - what does the film gimp have that the main gimp doesn't have, apart from some extra cool and expensive plug-ins and 16 bits per channel?

To cut this all short, how long will it be until I can do higher precision rendering in any gimp whatsoever? FG's xcf plugin is broke, gegl isnt done yet....

Btw, why hasnt Gimp gone to linuxfund and get some funding? With $1k you probably could hire someone to push a single precision float rendering pipeline ahead of schedual. Or atleast put a huge dent in it.

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.

Yeah, really, isnt the point of GEGL and other realted stuff?

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.

Yeah, that would be cool. But really, I would want this in the same app. If Im editing images (normal gimp mode) I want it to look one way, if Im editing movies (film gimp mode) I want it to look another way.

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.

Actually, Im going to use my evil weapon of mass destruction here. "Adobe Photoshop does cmyk and layer groups." But Ill be fair here and say its got an ugly renderer like we do. BTW, Im not specifically pushing for Images themselves in 16-bit channel mode, but a renderer that works at a very high precision (once again, single precision floats comes to mind, so we can use gcc 3.2.x's -mfpmath=sse,387 and such) independent of what the image itself is. This especially would be good for film gimp's 16-bit mode because its more than twice the bitdepth (32-bit yes, but its also float.) So doing multiple layers will result in very high quality images no matter what.

Btw, has there been a discussion on how layer grouping will work? I want to be able to both group layers in just a group (aka doesnt change how rendering works at all) then also be able to group layers together, and have the output of that act as a layer (aka, for calculating the "virtual" layer, only the layers inside of it are done, no outside layers interact with these except through the final "virtual" layer.)

* Raphaël Quinet [021129 18:38]:

On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland wrote:

Btw, has there been a discussion on how layer grouping will work? I want to be able to both group layers in just a group (aka doesnt change how rendering works at all) then also be able to group layers together, and have the output of that act as a layer (aka, for calculating the "virtual" layer, only the layers inside of it are done, no outside layers interact with these except through the final "virtual" layer.)

There has been some discussion about layer grouping, but I do not think that any concrete implementation proposals have ever been agreed upon. So anyone who could come up with a GUI mock-up is welcome. Code is even more welcome, of course. ;-)

So as you mentioned yourself, there are two ways to define "groups": they have different purposes and need to be implemented differently.

A little while ago I added another little code project to my todo queue, it's just a toy project but might end up providing useful ideas for the implementation. I've been toying with the idea to create a small program that is built entirely of plug-ins and allows you to build graphs of dataflow between inputs and outputs of the plug-ins (nodes in the graph). And thus enable the coding of a function that only blurs the brightness and not the color of an image to be "coded" visually like this:

RGBA value_blur(RGBA,radius){ .--RGBA------.
| split_RGBA |
`-R--G--B--A-'
| | | |
| | | `---.
.-R--G--B-. \
| rgb2hsv | \
`-H--S--V-' \
| | \ \
| | \ |
| | .---V------. |
| | |blur(radius)|
| | `---V------'/
| | | /
| | / /
| | / /
.-H--S--V-. /
| hsv2rgb | /
`-R--G--B-' /
| | | /
.-R--G--B--A-.
| join_RGBA |
`--RGBA------'
}

At the moment I'm pondering about reference counting to avoid exhausting memory,

It'll take a little while until I have the time to start working on it, this is a much more general approach, but if I end up with something viable at least the ideas can be used to implement most kinds of layer grouping etc. since they will be graphs with special constraints.

http://phpweb.hig.no/~oey_kola/graph.txt s mostly playing with some design ideas I have, but if the ideas work out nicely,. gimp should be able to benefit from the fact that the problem has been attacked a little outside gimp.

quinet@gamers.org (2002-11-29 at 1833.03 +0100):

- Simple linking of layers so that some operations such as toggling their visibility or moving the whole group of layers can easily be applied to them (bug #86337, bug #86277). These operations would not modify the pixels in the layers. This could probably also be used for implementing the clipping groups (bug #51112).

Clipping sounds more like ATOP operation in other docs, not like simple move or visibility, so I would put it in the other group, or make it some kind of blend mode (hidden) or pre process in blend operations. It "modifies" pixels, by looking at the bg alpha.

The traditional document about digital composition is from Siggraph 84, by Porter & Duff, just in case people want to read more this ATOP thing. Scanned copy at http://www.keithp.com/~keithp/porterduff/.

- Grouping of layers in such a way that a merged image of the layers is stored in a virtual layer and some operations can be applied to

[...]

(merged view + results) and to apply the PDB function only to the regions that have been modified, but this is only an optimization.

You say they are the same, which from the one point of view is correct. But from other they have some differences that would make nicer to consider them a bit special. Layer effects would allow external ops, and use two drawables only, "in" and "out", with "in" one being updated rarelly (and thus "out" too). They are more artistic oriented, to say it quickly.

Adjustment layers would allow core ops and N inputs, with those N changing a lot, and thus lot of recomputation, like blend modes. What is more, I would see them as blend modes that have some vars to control the formulas, and the RGB channels working as selection does. This also means that, probably, layer effects have a region of interest of multiple pixels for each output pixel, while adjustment layers only get a pixel, operate and put back (use LUTs?).

If the system can be done so fast that there is no big differences, I see no problem with making all the same. Otherwise, maybe a forced separation would be better.

GSR

quinet@gamers.org (2002-11-29 at 1937.59 +0100):

Yes, this is a nice idea, although this is different from the feature that we were talking about.
As a matter of fact, the idea that you present here has already been discussed on this mailing list. This is similar to what is done in a program called "Khoros" and its interface "Cantata". If you do a

It is like some composition engines work, for example NothingReal's Shake (now Apple's). In the world of 3D shaders, too, like ShaderMan or Maya's system. They just have systems capable of passing streams of data thru the nodes, requiring a timeline interface, so you can see that side of the problem too, the offsets from stream to stream. But if you only allow one image per input, you can work with the tree alone.

I do not see why it can not be used for layers, after all, the only limit is what kind of bricks you have avaliable (current layer stack would be a lot of blend:normal, blend:disolve... bricks).

Current way:

Top layer (soflight) Middle layer (burn)
Bottom layer (na) [No Applicable, there is nothing "below"]

In tree:

IN:TL \
IN:ML B:Softlight - OUT
\ /
B:Burn
/
IN:BL

Now lets do groups:

Layer A (softlight) | Group A,B Layer B (na) | (hardlight)
Layer C (burn) | Group C,D
Layer D (na) | (color)
Layer E (na)

And the equivalent:

IN:LA \
B:Softlight
/ \
IN:LB \
\
IN:LC B:Hardlight - OUT \ /
B:Burn /
/ \ /
IN:LD B:Color
/
IN:LE

I can go on, with layer effects, adjustements, channel compose and decompose, plugins and so on. Probably I could do bricks for paint tools, if so inclined (paint in multiple places at the same time, undo by disabling bricks...). Making big boxes would allow clearer grouping, simplify paint ops (all strockes become one box), or reducing the undo steps. :]

Exposing part or all the tree would confuse people, that is true, but could make some other things nicer. Depends in the target. So are we talking about the engine or the interface or both?

And after all this rant... is anybody checking GEGL docs? It would save me doing ascii art. ;]

GSR

On 29-Nov-2002, Raphaël Quinet wrote:

However, here is my point of view (which may be different from what some other developers think, so do not take this for granted). There are two kinds of "grouping":

- Simple linking of layers so that some operations such as toggling their visibility or moving the whole group of layers can easily be applied to them (bug #86337, bug #86277). These operations would not modify the pixels in the layers. This could probably also be used for implementing the clipping groups (bug #51112).

- Grouping of layers in such a way that a merged image of the layers is stored in a virtual layer and some operations can be applied to this merged layer: color adjustments, transformations or even any PDB operation, including the ones done by a plug-in. Whenever a layer in the group is modified, the merged image is rebuilt and the operation associated with it is applied to in order to re-create the updated "active layer". This can be used to implement the Photoshop styles or adjustment layers (bug #79025, bug #98262). In summary, the "active layer" would have a list of layers, a drawable and one PDB function (with its current parameters) associated with it. Whenever something happens to one of the layers in the list, a new (invisible) drawable is allocated, it gets the merged copy of all layers, and then the PDB function is applied to it. When the results are ready, the new drawable replaces the one that was visible. In some cases, it may be better to keep the two drawables (merged view + results) and to apply the PDB function only to the regions that have been modified, but this is only an optimization.

So as you mentioned yourself, there are two ways to define "groups": they have different purposes and need to be implemented differently.

That is a _perfect_ explination of what I want. =)

pippin@users.sf.net wrote:

I've been toying with the idea to create a small program that is built entirely of plug-ins and allows you to build graphs of dataflow between inputs and outputs of the plug-ins (nodes in the graph).

This is exactly what Gimpeon does. It's a Gimp plugin, lets you build a graph (well, actually a line, since I don't have any multi-input nodes yet) of processing nodes, animate parameters over time, display multiple points in the graph, update them as you adjust parameters, and apply the processing graph (line) to a sequence of images.

http://www.ozemail.com.au/~hodsond/gimpeon.html

It's crashable, but you should be able to get the idea.

Hi,

I am one of the "developers" of filmgimp, although really I am mostly bug-fixing and packaging it at the moment. While I'm not going to comment on accuracies of the web site, thats Robins area, but I would like to address some of the other issues raised...

Firstly, like everybody else, I would prefer to avoid the split in code, and cant wait for GEGL to make it into gimp.. However, I feel that filmgimp satifys a short term need which is for a 16 bit and floating point paint package, until the 2.0 release happens.

I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for "High Dynamic Range" imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images.

The next major reason for developing filmgimp is a time-frame issue, VFX houses are rapidly moving to linux as their primary platform, and one of the many missing apps is a basic paint system (such as matador), the hope is that we can develop filmgimp to that level in a short time frame (6 months).
The issues that we are dealing with are: * More recognisable UI - which generally means make it more photoshop like.
The issue here is that many of our artists will only need a paint system once
in a while, so we need a UI that is familiar to them. * Improved brushes (over current filmgimp version). * Better layer and channel support, in-particular for alpha channels.

These have been issues that we have had with gimp for quite a while, and I think its very interesting that RnH (the main filmgimp developers), have been slowly addressing these issues and that their goals are extremely similar to ours. I would like to believe that once 2.0 starts forming, that all of us start migrating over to that new code-base.

While there has been much talk about merging the filmgimp version back into gimp (or even the other way around), the difference are extremely large, even more if we talk about 1.3, I also would prefer to see filmgimp as a short term solution and rather than spend quite a bit of time trying a merge, I would personally prefer to spend the time later on 2.0, since most of the work and fixes that we would be doing during the merge would need to be redone for 2.0.

I would like to know what the roadmap for gimp is after 1.4? When is the merge for GEGL? Are you planning 16 bit support as a separate thing to GEGL? Are there any design docs for 1.3? How much work was it porting to GTK2.0?

Anyway, I have just joined the gimp-developer list, and will try to be more actively envolved, so that hopefully later I can contribute more to 2.0 down the road.

Thanks...

Sam.

On Fri 29 November 2002 18:33, Raphaël Quinet wrote:

On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland

wrote:

Btw, has there been a discussion on how layer grouping will work? I want to be able to both group layers in just a group (aka doesnt change how rendering works at all) then also be able to group layers together, and have the output of that act as a layer (aka, for calculating the "virtual" layer, only the layers inside of it are done, no outside layers interact with these except through the final "virtual" layer.)

There has been some discussion about layer grouping, but I do not think that any concrete implementation proposals have ever been agreed upon. So anyone who could come up with a GUI mock-up is welcome. Code is even more welcome, of course. ;-)

Funny. I did just that (a mockup, not code) a little while ago in a different forum. See
http://boards.lionhead.com/showthread.php?s=&threadid=32671#post298059

Lourens

On Fri, Nov 29, 2002 at 11:29:12AM -0500, Patrick McFarland wrote:

Btw, has there been a discussion on how layer grouping will work? I want to be able to both group layers in just a group (aka doesnt change how rendering works at all) then also be able to group layers together, and have the output of that act as a layer (aka, for calculating the "virtual" layer, only the layers inside of it are done, no outside layers interact with these except through the final "virtual" layer.)

I recently had another idea when someone was talking about MNG export. It should be possible to create an instance of a layer and use it somewhere else. This is especially useful for animations - I imagine a tree of layers. The first level defines the frames. So, the same layer (say, some background) could be used in every frame and the MNG exporter could exploit that fact and create nice, small files.

Apart from that, one often needs a copy of a layer to create some effect. Combined with effect or active layers, one would only need to alter the source layer and everything else would change by itself.

Bye, Tino.

On 30-Nov-2002, Tino Schwarze wrote:

Apart from that, one often needs a copy of a layer to create some effect. Combined with effect or active layers, one would only need to alter the source layer and everything else would change by itself.

That is the coolest thing ever. Santa, I want _that_ for christmas!

Hi. Different thoughts about Film Gimp have been been expressed by Gimp folks on the Gimp-developer list over the Thanksgiving holiday. As the Film Gimp release manager, I've found it stimulating reading. Probably anything interesting about that "debate" has already been thrashed out by others there. All I have to add are a few missing facts.

It is worth noting that the target audience of Film Gimp is motion picture studios. It makes sense for Film Gimp to have goals distinct from Gimp. GEGL is a different codebase from Gimp or Film Gimp. All three are run as independent projects with different management styles and different goals. It is reflection of the diversity and depth of the development and user communities that three projects seem justified. Four, if we also count ImageMagick.

Windows and Mac ports of Gimp already exist. To do the same with Film Gimp is not radical. The Film Gimp porting teams have referred to the Gimp ports, but not followed them closely. The Windows port is not based on gcc or cygwin, rather VC++. Regardless of that, Film Gimp is a unifed codebase. All Film Gimp platforms compile from the same code.

Gimp maintainer Sven Neumann says, "the point is that the new film-gimp maintainer or any of the people working on film-gimp don't communicate with us at all". It's true I haven't sought Sven out. It was Gimp maintainer Yosh Singh, one of the original Film Gimp developers, that I conferred with. He agreed to grant me an account at gimp.org so I could maintain the Film Gimp project at the existing site there, but after months of delays it was mutually agreed that SourceForge would be a better home.

Gimp site maintainer Raphaël Quinet says the Gimp committee didn't really vote against Film Gimp, that "it was only decided that the merge would be done later". I wan't there, and can only report what I've learned from talking with others. Everyone seems to agree that Gimp never said it was in favor of merging with Film Gimp later. What was said was Film Gimp should be thrown away and re-implemented as GEGL. GEGL is not Film Gimp, therefore that imagined later merge would not be with Film Gimp. Raphaël is right, as far as I know, that there was no "us versus them" feeling at the vote. Everyone was "us" (a Gimp developer) and the vote was unanimous against accepting the Film Gimp branch. Although nobody argued Film Gimp should live, it woudn't die. There was no available alternative for its users.

Conspiracy theorists may become doubly alarmed, but I've taken Raphaël's advice and tried to downplay the wording of the Film Gimp history. I've also added more details.

http://filmgimp.sourceforge.net/docs/history.html

Please note that I work on Film Gimp because I enjoy it. What some imagine would be mindless duplication of effort between similar projects I see as an exciting opportunity to create alternative designs to delight users in new ways. Many project leaders seem to feel the same way. We have Linux and BSD, KDE and Gnome, and so forth. Being independent has some advantages. Film Gimp has achieved tremendous progress since July. In addition to that satisfaction, I have the pleasure of working with a team that I enjoy and that say they appreciate me.

Cheers,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

On 30-Nov-2002, Robin Rowe wrote:

A lot of text about how film gimp is trying to be its own thing.

Well, first I would like to say film gimp should be moving to a GEGL target. Not because film gimp is gegl, but because gegl is so damn useful. (Well, will be useful if/when it gets done.) And gegl would be the perfect place for film gimp and gimp to share all the "difficult" base code (like, dare I say it, single precision fp layer rendering code.)

Speaking of that, has anyone seen fg's xcf loader plugin? I heard he was sick... Maybe someone should send him some chicken soup?

Patrick,

Hi. Please don't suggest I said that Film Gimp is merely "trying" to do its own thing. It has been its own thing for many years.

I couldn't help but notice that within minutes of recommending Film Gimp abandon itself to join GEGL, you posted a question to gimp-developer asking how to create a bit converter function using Gimp. May I ask a silly question? Since you are so keen on GEGL, why aren't you developing with it?

A question for everyone who is recommending GEGL, have any of you ever tried it?

Cheers,

Robin
--------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

----- Original Message ----- From: "Patrick McFarland"
To:
Sent: Saturday, November 30, 2002 3:20 AM Subject: Re: [Gimp-developer] Re: Film Gimp and GIMP I want to develop stand alone 24bit -> 8bit converter function, and also a bicubic resizer. Now, I noticed gimp has really high quality versions.... would it be possible to convert gimps functions to do:

(with the converter) take an int 24bitimage[width][height] and return a char 8bitimage[width][height] and a int palette[256], those 256 entries being the 256 most used colors and all colors that dont match are set to the closest palette entry that matches.

(with the bicubic resizer) take an int 24bitimage[width][height], and int newheight, newwidth, and return int 24bitimage[newwidth][newheight]

I probably shouldnt ask this on here, but a) this is the only place that people
familiar with the gimp source go, and b) I cant find what the functions are even called, nor what file they would be in.

-- Patrick "Diablo-D3" McFarland || unknown@panax.com "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

----- Original Message ----- From: "Patrick McFarland"
To:
Sent: Saturday, November 30, 2002 3:13 AM Subject: [Gimp-developer] I am a newbie, yes its true

On 30-Nov-2002, Robin Rowe wrote:

A lot of text about how film gimp is trying to be its own thing.

Well, first I would like to say film gimp should be moving to a GEGL target. Not because film gimp is gegl, but because gegl is so damn useful. (Well, will
be useful if/when it gets done.) And gegl would be the perfect place for film
gimp and gimp to share all the "difficult" base code (like, dare I say it, single precision fp layer rendering code.)

Speaking of that, has anyone seen fg's xcf loader plugin? I heard he was sick... Maybe someone should send him some chicken soup?

-- Patrick "Diablo-D3" McFarland || unknown@panax.com "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

On 30-Nov-2002, Robin Rowe wrote:

Patrick,

Hi. Please don't suggest I said that Film Gimp is merely "trying" to do its own thing. It has been its own thing for many years.

I didnt mean any insult by that.

I couldn't help but notice that within minutes of recommending Film Gimp abandon itself to join GEGL, you posted a question to gimp-developer asking how to create a bit converter function using Gimp. May I ask a silly question? Since you are so keen on GEGL, why aren't you developing with it?

Its for a game, not a graphics program.

A question for everyone who is recommending GEGL, have any of you ever tried it?

You cant try something that is in the early beta (alpha?) stages. Alot of GEGL work hasnt been done because gimp 1.4 comes before 2.0, and there arnt enough developers to do both at the same time.

Hello? Anyone home?

On 1 Dec 2002, at 7:10, Patrick McFarland wrote:

Hello? Anyone home?

Read you loud and clear.

Thus spoke Patrick McFarland

because the development teams dont communicate enough. I agree with a lot of what you said, but in the end, its silly to have two branches like this.

Maybe not. Consider that having competing branches can push the advancement of both. This is true of any research or commercial development. In this case, the discussion on 16bit support has been nudged yet again - perhaps enough to make real progress in the mainline. Who knows?

Competition - even within branches of the same project - can be a very good thing.

Thus spoke Carol Spears

On 2002-11-28 at 1259.18 -0500, Patrick McFarland typed this:

Hrm. Side note, They got $1k from Linuxfund to further their project... hrm...

$1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly).

But it might be enough for an outside contractor to produce a specific feature (probagbly not 16 bit support, but perhaps something else) and release it back to the community. This might be enough to keep the project moving in a direction acceptable to everyone.

Since dividing money up between all the current developers is extremely difficult, funding should be considered as a way to move the project forward in very specific ways, using external resources. For some open source projects that often means acquiring specific hardware. For GIMP, it could mean outsourcing feature and bug fix requests.

Of course, it would also mean having to establish a non-profit in order to accept the funding and use it to pay for the work. That would definitely move GIMP into a new area, one the developers might not want to deal with right now.

On 01-Dec-2002, Michael J. Hammel wrote:

Maybe not. Consider that having competing branches can push the advancement of both. This is true of any research or commercial development. In this case, the discussion on 16bit support has been nudged yet again - perhaps enough to make real progress in the mainline. Who knows?

I asked Santa for 16bit and/or sp fp rendering support in Gimp, and he said it was easier for me to ask for a Buzz Lightyear doll. =/

Thus spoke Robin Rowe

It is worth noting that the target audience of Film Gimp is motion picture studios. It makes sense for Film Gimp to have goals distinct from Gimp. GEGL is a different codebase from Gimp or Film Gimp. All three are run as independent projects with different management styles and different goals. It is reflection of the diversity and depth of the development and user communities that three projects seem justified. Four, if we also count ImageMagick.

Also worth noting is that GIMP has already spawned a major player in the open source world - the GTK+ toolkit. It would not be unexpected - nor necessarily unwanted - if it were to spawn another major project. The fact that Film GIMP is another editing tool should not be the only reason to merge the two. If the target audiences and needs are distinct enough, then separate development paths may be warranted.

What should not be lost, however, is an open communications path between the projects.

Please note that I work on Film Gimp because I enjoy it. What some imagine would be mindless duplication of effort between similar projects I see as an exciting opportunity to create alternative designs to delight users in new ways. Many project leaders seem to feel the same way. We have Linux and BSD, KDE and Gnome, and so forth. Being independent has some advantages. Film Gimp has achieved tremendous progress since July. In addition to that satisfaction, I have the pleasure of working with a team that I enjoy and that say they appreciate me.

Robin had an itch and he scratched it - it's the open source way. I hope no one chastises him for that. I, for one, encourage him and wish he and his team much success.

Carol,

$1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly).

It's true that $1k isn't generally considered a lot of money in funding a software project, but I appreciate getting anything. Linux Fund was very kind to give me a grant. None of the grant is going toward beer, by the way. It is for Film Gimp GUI enhancements and a keyboard/mouse macro recorder/player.

You've piqued my curiosity. How large is GIMP's development budget? How is it funded?

Cheers,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

Patrick,

...how many _film gimp_ developers are there?

The list is here:

http://filmgimp.sourceforge.net/people/index.html

Cheers,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

----- Original Message ----- From: "Patrick McFarland"
To:
Sent: Friday, November 29, 2002 5:01 AM Subject: Re: [Gimp-developer] Re: Film Gimp and GIMP

On 29-Nov-2002, Raphaël Quinet wrote:

On Thu, 28 Nov 2002 14:55:06 -0500, Carol Spears

wrote:

On 2002-11-28 at 1259.18 -0500, Patrick McFarland typed this:

Hrm. Side note, They got $1k from Linuxfund to further their

project... hrm...

$1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly).

That depends... If you consider those who write GIMP code on a daily or weekly basis to be the real "developers" and if you consider those (like me) who submit patches from time to time as "contributors", then I think that $1K would be more than enough to buy beer for all developers, unfortunately. I wish there were more developers...

On the other hand, if you divide $1K among all contributors, then we would all be very thirsty. ;-)

Yeah, but how many _film gimp_ developers are there? Less than a handful?

-- Patrick "Diablo-D3" McFarland || unknown@panax.com "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

Robin ...
On 2002-12-01 at 0842.07 -0800, Robin Rowe typed this:

Carol,

$1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly).

It's true that $1k isn't generally considered a lot of money in funding a software project, but I appreciate getting anything. Linux Fund was very kind to give me a grant. None of the grant is going toward beer, by the way. It is for Film Gimp GUI enhancements and a keyboard/mouse macro recorder/player.

You've piqued my curiosity. How large is GIMP's development budget? How is it funded?

first, this should be very clear. i am just guessing. observation, dirk gently like deduction and i probably have a lot of it wrong, as i tend to idealize things.

The GIMP was originally a college project. a showcase of what people had learned from their coding class? i hope it got an A! from what i can see, many of those people working on the early gimp have gotten jobs from that work.

i know of five developers (maybe there are more) whose companies might be allowing them some of their work time to work on gimp. this is cool, as long as that big plan (to 1.4) is respected.

some have gotten jobs elsewhere doing other things, and show their gimp-love by letting The GIMP go.

others have gotten jobs doing other things, yet maintain an active interest in things gimp.

The GIMP artists were all hired as well. but this is for good work that they did. not in advance. the work, i think, was done for love of a project.

some are able to contribute to The GIMP and get a trip to someplace nice where lots of other neat linuxy people are. that is sort of nice and much closer to funding. but generally the work is still done before hand and accepted or not.

one of the news things i read about Film Gimp was that only half of the funding was gotten so only half of the proposal would be achieved.(?) i might have that wrong, and if i do, please forgive me. but from a user point of view, let me use "Map To Object" as an example. in the last year, i have used all of the Objects available there. i am glad that the whole thing was written.

what i have found to be The GIMP's most charming quality is the lack of funding. i have heard it called the flagship Linux app. i tend to think that the lack of funding had a lot to do with that. this is where i am probably the most clueless though. i don't really believe in money. i am fiddling with The GIMP while i recover from some life changes. this is not a new thing either. some very nice gimp things have been "funded" this way.

Robin, i can be pretty sure about this fact though. you will know you are in on the big developer funding when they send you to one of those public relations grooming classes. we will all know when that happens because you will cease typing stupid things. you will also not be so fun or charming (or honest) i bet.

btw, if you had presented to me, a list of hardware they "donated" i would have liked you and the news about Film Gimp much more. but that is how to market things to me. and i don't have any money. so don't worry if it didn't sound so good to me ;) crap. i don't even believe in money.

i volunteered to host tigerts site when it went down. i got laughed at. i had no idea tigerts site was so popular. it would cost me about $1000 to host tigerts site for three months. i mention this now because it is an example of funding "The GIMP" is getting that isn't obvious. i wanted to host it because it was important to me, because i use. i had *no* idea there were so many others out there that agree with me and visit often or whatever is going on there.

so, to answer your question about gimp funding: define funding.

carol

Carol,

one of the news things i read about Film Gimp was that only half of the funding was gotten so only half of the proposal would be achieved.(?)

The Newsforge story didn't quite get the details right. Linux Fund asked me to cut the proposal in half, and to complete the first half before asking for the second half.

what i have found to be The GIMP's most charming quality is the lack of funding.

GIMP hasn't always lacked funding. The original Film Gimp sponsors (before it became Film Gimp) funded two GIMP developers for a year. That is, paid them full salaries to work on GIMP.

i don't even believe in money.

That's interesting.

Cheers,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

Hi,

pippin@users.sf.net writes:

A little while ago I added another little code project to my todo queue, it's just a toy project but might end up providing useful ideas for the implementation. I've been toying with the idea to create a small program that is built entirely of plug-ins and allows you to build graphs of dataflow between inputs and outputs of the plug-ins (nodes in the graph). And thus enable the coding of a function that only blurs the brightness and not the color of an image to be "coded" visually like this:

RGBA value_blur(RGBA,radius){ .--RGBA------.
| split_RGBA |
`-R--G--B--A-'
| | | |
| | | `---.
.-R--G--B-. \
| rgb2hsv | \
`-H--S--V-' \
| | \ \
| | \ |
| | .---V------. |
| | |blur(radius)|
| | `---V------'/
| | | /
| | / /
| | / /
.-H--S--V-. /
| hsv2rgb | /
`-R--G--B-' /
| | | /
.-R--G--B--A-.
| join_RGBA |
`--RGBA------'
}

looks very much like the Pupus rendering pipeline that Adam suggested for GIMP-2.0. It's basically the framework that we'd like to put on top of GEGL.

Salut, Sven

Hi,

Sam Richards writes:

I would like to know what the roadmap for gimp is after 1.4? When is the merge for GEGL? Are you planning 16 bit support as a separate thing to GEGL? Are there any design docs for 1.3? How much work was it porting to GTK2.0?

This document is probably still valid in a lot of points:

http://developer.gimp.org/gimp-future

We will try to come up with something more uptodate soon.

Salut, Sven

Hi,

Patrick McFarland writes:

To cut this all short, how long will it be until I can do higher precision rendering in any gimp whatsoever? FG's xcf plugin is broke, gegl isnt done yet....

GEGL is being worked on and it has already come a long way.

Btw, why hasnt Gimp gone to linuxfund and get some funding? With $1k you probably could hire someone to push a single precision float rendering pipeline ahead of schedual. Or atleast put a huge dent in it.

iirc, there is some money we could spend but until today noone has come along who has the skills and the time to hack on GIMP and wants that money. Personally I don't think that it helps to pay developers. Money should be spent on infrastructure (hardware, web services, ...) and can be used to allow developers to come together on conferences.

Salut, Sven

* Sven Neumann [021202 15:00]:

RGBA value_blur(RGBA,radius){
.--RGBA------.
| split_RGBA |
`-R--G--B--A-'
| | | |
| | | `---.
.-R--G--B-. \
| rgb2hsv | \
`-H--S--V-' \
| | \ \
| | \ |
| | .---V------. |
| | |blur(radius)|
| | `---V------'/
| | | /
| | / /
| | / /
.-H--S--V-. /
| hsv2rgb | /
`-R--G--B-' /
| | | /
.-R--G--B--A-.
| join_RGBA |
`--RGBA------'
}

looks very much like the Pupus rendering pipeline that Adam suggested for GIMP-2.0. It's basically the framework that we'd like to put on top of GEGL.

Salut, Sven

I read a little on Adam's pupus pipeline, I'm think I'll start with a less advanced approach than the one he suggests, with a basic design that hopefully works, and can be enhanced.

I will also read a little about GEGL to refamiliarize myself with the concepts and data structures planned, to make integration of code or design easier if what I end up with is useful.

skål, /pippin

Sven,

This document is probably still valid in a lot of points:

http://developer.gimp.org/gimp-future

Who is working on GEGL and how active is that?

Your GIMP team list at http://www.gimp.org/the_gimp_org_about.html includes Mattis and Kimball. Have they done anything with GIMP since 1997? What are Mattis and Kimball doing now?

Who is actively working on GIMP?

Thanks,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

Hi,

"Robin Rowe" writes:

Who is working on GEGL and how active is that?

http://cvs.gnome.org/lxr/source/gegl/ChangeLog

Your GIMP team list at http://www.gimp.org/the_gimp_org_about.html includes Mattis and Kimball. Have they done anything with GIMP since 1997?

no, they haven't but of course they are still in the list of developers. The list on the web is not uptodate however.

What are Mattis and Kimball doing now?

who knows? Why are you asking?

Who is actively working on GIMP?

http://cvs.gnome.org/lxr/source/gimp/ChangeLog

Salut, Sven

On 2 Dec 2002, at 10:23, Robin Rowe wrote:

Your GIMP team list at http://www.gimp.org/the_gimp_org_about.html includes Mattis and Kimball. Have they done anything with GIMP since 1997? What are Mattis and Kimball doing now?

See .

On 2002-12-04 at 1831.12 +0100, Rapha?l Quinet typed this:

From the list on www.gimp.org, the only developers who are still active

are Sven Neumann (neo in CVS logs), Michael Natterer (mitch) and Manish Singh (yosh). The other people listed there haven't contributed much in the last months.

as the owner of several gimp source trees, i sort of trust that the AUTHORS file included in each tree is up-to-date and includes everyone who touched the gimp source in some way as it appears in that tree. now i wonder how this file is updated.

(importance of latest contributions? but who would estimate that?).

only a complete idiot would probably attempt such a thing. let me volunteer.

A Fairly Good List of GIMP Contributions: --the last 10 or the last 24 hrs of entries would be interesting--
from gnome annoncvs (updated once daily): gimp ChangeLog
gimp-1-2 ChangeLog
gimp-help ChangeLog
gegl ChangeLog
from sourceforge anoncvs (need info on updates): gimp-print (a cvs changelog could be gotten) filmgimp ChangeLog
from gnome bugzilla (once a day would be enough) bug reports upon the first change bug reports marked as FIXED
from registry.gimp.org (again, a once a day query) new plug-ins
modified plug-ins

i might have left something out. please feel free to add and subtract from this list. i actually had a script that would query the registry, but my cable company moved the site on me.

Who is actively working on GIMP?

http://cvs.gnome.org/lxr/source/gimp/ChangeLog

Another way to see this is to have a look at the CVS checkins in the last week (about 168 hours). This link will give you the full list including the number of lines of code added or changed by each contributor. But do not call this too frequently, because this query puts some strain on the server:
http://cvs.gnome.org/bonsai/cvsquery.cgi?dir=gimp&date=hours&hours=168

it is such simple information, and a daily looksee would be plenty, which could be gotten from any computer that updates from two annon servers every day.

i could provide an html template for anyone interested in helping me to figure out how to get these files out of my cvs trees and off from the web.

or, we can wait for me to figure out how to do it.

In summary, the most active developers are Mitch and Sven who get the lion's share, followed by Yosh, Maurits Rijk, Dave Neary and some others who contribute from a few dozens to a few hunded lines of code or documentation per week. There are also some contributions through Bugzilla, but this is harder to evaluate.

i would like to see what they are up to more easily than i can now.

all of them. you too, if you are working on The GIMP. :) carol

Hi,

Carol Spears writes:

On 2002-12-04 at 1831.12 +0100, Rapha?l Quinet typed this:

From the list on www.gimp.org, the only developers who are still active

are Sven Neumann (neo in CVS logs), Michael Natterer (mitch) and Manish Singh (yosh). The other people listed there haven't contributed much in the last months.

as the owner of several gimp source trees, i sort of trust that the AUTHORS file included in each tree is up-to-date and includes everyone who touched the gimp source in some way as it appears in that tree. now i wonder how this file is updated.

from time to time I add people who have made contributions. It may thus very well be that the file is not uptodate.

About a year ago I asked for volunteers to port the authors file to XML and volunteered to do the necessary hacking in the gimp about dialog. Unfortunately there wasn't much response and we are still stuck with the plain old text file.

However I don't think we want to build this file automatically from CVS. We often apply patches from people that don't have CVS commit access. I'd like to see the names of the patch authors in the list of contributors but it's not trivial to extract them from the ChangeLog entries. So perhaps we should continue to update the file manually.

Salut, Sven

On 2002-12-05 at 1320.57 +0100, Rapha?l Quinet typed this:

On 05 Dec 2002 12:42:28 +0100, Sven Neumann wrote:

However I don't think we want to build this file automatically from CVS. We often apply patches from people that don't have CVS commit access. I'd like to see the names of the patch authors in the list of contributors but it's not trivial to extract them from the ChangeLog entries. So perhaps we should continue to update the file manually.

Yes. When I suggested the Bonsai cvsquery in my previous mail, I did not mean to suggest that it should be used to get a list of contributors automatically. This was only a way for someone to get an overview. Counting the CVS commits would be unfair because that would exclude those who do not have CVS commit access. And although the names of the patch authors are usually mentioned in the ChangeLog entry, they are sometimes mentioned by first name only, sometimes by full name, sometimes by e-mail address and sometimes by giving a reference to a Bugzilla entry.

So it would be rather difficult to extract the names of the contributors from the CVS logs automatically. The best solution is to rely on the AUTHORS file that is updated by hand, until we find a better solution.

you guys can play with the cvs logs as much as you want. having filled out a cvs log and a hand edited ChangeLog -- i would really rather use (and read) the hand edited one.

just something to run it the directory, grab the first 10 entries and spit it into some html. the only cvs log i would need is for gimp-print.

i am worried that if you make it too hard of a job, you will scare away anyone that might like to help.

On 2002-12-05 at 1759.57 +0100, Rapha?l Quinet typed this:

On Thu, 5 Dec 2002 10:20:28 -0500, Carol Spears wrote:

On 2002-12-05 at 1320.57 +0100, Rapha?l Quinet typed this:

On 05 Dec 2002 12:42:28 +0100, Sven Neumann wrote:

However I don't think we want to build this file automatically from CVS. [...]

So it would be rather difficult to extract the names of the contributors from the CVS logs automatically. The best solution is to rely on the AUTHORS file that is updated by hand, until we find a better solution.

i am worried that if you make it too hard of a job, you will scare away anyone that might like to help.

Well, I think that both Sven and I agree on the fact that we should not try to build the list of GIMP contributors automatically. Updating it by hand is the best solution for the moment, because any automated solution would be far too complex or unfair (having an unfair list is probably worse than having no list or an outdated list).

i would like a web page that shows the last 10 people who contributed are mentioned in the ChangeLog. i don't know of asking any opinions. is there something there in the list of the last 10 which should not be shared?

i am not going to change this by hand everyday.

you guys are very frustrating. perhaps i need to ask elsewhere for help.

What do we want to do with the AUTHORS file (or any list of GIMP contributors)? The last time this was discussed on this list, the decision was that it should list the names of all those who have ever made a significant contribution to the GIMP, without trying to evaluate how important this contribution was nor in which area it was (core code, plug-in code, documentation, translations, bug hunting, etc.). People who stop contributing are not removed from the list; that's why Spencer and Peter are still there (and they should be, IMHO).

the AUTHORS list gets copied as is to a page now. i have no idea how the information gets there. i like the alphabetical listing also.

the ChangeLog is a completely different matter. chronological and lists what is going on, without ranking the importance of the contribution. just listing it. i think that a page that displays the last 10 ChangeLog items in all of the different gimp projects would be an extremely interesting read.

If most people on this list agree that we should not try to sort this list in any way or to make it more detailed than it is now, then keeping the AUTHORS file up-to-date is not very difficult: we only have to add the names of those who have made a significant contribution since the last update. But if, on the other hand, you want to change the purpose of that list and remove those who haven't contributed recently or sort the list by area or by "importance of the contribution" (whatever that means), then we should first decide on what we want before trying to implement something.

yes. i don't really want to watch it get "sorted out". i would like a way to read the last 10 additions to each of the gimp projects and deliver them to a web page.

already, the AUTHORS page is delivered in what ever order to a page. i am sorry that my last mail casted doubt on where the AUTHORS list comes from. do you think that dealing with how these files get there to begin with will keep my little web page from happening?

carol

Hi Carol,

Carol Spears writes:

the AUTHORS list gets copied as is to a page now. i have no idea how the information gets there. i like the alphabetical listing also.

the ChangeLog is a completely different matter. chronological and lists what is going on, without ranking the importance of the contribution. just listing it. i think that a page that displays the last 10 ChangeLog items in all of the different gimp projects would be an extremely interesting read.

I agree that ChangeLogs are an interesting read and I would very much welcome a page that gives access to a bunch of GIMP-related ChangeLogs. You could just link to the pages on bonsai.gnome.org and lxr.gnome.org and perhaps mirror the results of a bonsai query for the last 24 hours (or more) since these queries put a high load on the server.

It seems that we don't disagree at all. Your mail only gave me the impression you wanted to try to maintain a list of gimp contributors by means of some scripts that operate on the ChangeLog. Sorry if my response offended you, it was just a misunderstanding.

Salut, Sven

A Fairly Good List of GIMP Contributions: --the last 10 or the last 24 hrs of entries would be interesting--
from gnome annoncvs (updated once daily): gimp ChangeLog
gimp-1-2 ChangeLog
gimp-help ChangeLog
gegl ChangeLog
from sourceforge anoncvs (need info on updates): gimp-print (a cvs changelog could be gotten) filmgimp ChangeLog
from gnome bugzilla (once a day would be enough) bug reports upon the first change bug reports marked as FIXED
from registry.gimp.org (again, a once a day query) new plug-ins
modified plug-ins

i might have left something out. please feel free to add and subtract from this list. i actually had a script that would query the registry, but my cable company moved the site on me.

it is such simple information, and a daily looksee would be plenty, which could be gotten from any computer that updates from two annon servers every day.

i could provide an html template for anyone interested in helping me to figure out how to get these files out of my cvs trees and off from the web.

and onto a web page.

or, we can wait for me to figure out how to do it.

it seems like the people involved with The GIMP are already doing an enormous amount of work, or would prefer to watch the walls. i wonder if "thesis" is german for "work on an ircbot" even.

i am so interested in getting the web site for 1.2 off from my computer and start work for the wgo-1.4. as it is, i cannot even share the location.

i had this week off from work, which is a very very rare thing. i had really wanted to move things during this week where my time was uninterupted, but the last commit to the cvs module for the site (that wasn't me) was on November 26. and now my week is almost over.

i have the week of December 15 to 21 off also. i am going to wait a few days to see if someone off from the list would like to help me with these scripting needs, then i really must get this site out of my life and off my computer. so if no one here is interested, perhaps a trip to the perl monks would help me to get these little things done.

one person understood my request though :) Robin Rowe volunteered with some scripting. i had really thought that there were enough people in the various gimp places, clever and talented people, that this would not be an issue. Robin volunteering was a nice spot in my day, however, i was hoping that some of those gimp people whom are just typing away at email or into an irc window to help so that actual gimp work did not suffer.

Sven, nothing in your post offended me. mostly i felt bad as i tried to tag the AUTHORS file way back then. i seem to have issues with tags. maybe if you could whip together a template, i could work rocks script into spitting the AUTHORS out an xml form to your liking. his little script already does this nicely:
http://carol.gimp.org/authors.png
should be simple enough for even me to change the web page into whatever xml tags you see fit.

a long time ago, Sven and mitch made me promise not to touch The GIMP source if i were going to take on the web site. i really think i have lived up to my end of that bargin. it has been so long now, perhaps you could start to assume that my intentions are *never* with the GIMP source. i have been very very good about following this rule, i thought.

the source is a good thing to mine for information that makes it look like someone cares for the web site, however.

i am so frustrated and disillusioned, that i am probably making it sound like i haven't had help with the web site so far. this is not true. the tutorial section is almost finished, due to the work of one person, not me. and the outlay of the site, a nice simple ssi thing was put into place by someone not me. and it works very nicely.

as i mentioned earlier, Rock wrote a script that drops the AUTHORS into a page, and prolly i would be able to work with that and get what i need. but it is a bad thing when the existence of a web site about such a cool app as The GIMP is, relies on one girls learning curve. bad and pathetic.

i am sure i could get the perl monks to help ...

carol

Carol,

one person understood my request though :) Robin Rowe volunteered with some scripting. i had really thought that there were enough people in the various gimp places, clever and talented people, that this would not be an issue. Robin volunteering was a nice spot in my day, however, i was hoping that some of those gimp people whom are just typing away at email or into an irc window to help so that actual gimp work did not suffer.

I'm glad my note cheered you. Thanks for letting me know. My helping you couldn't make "actual gimp work" suffer. At most it might delay my finishing the Windows port of Film Gimp. ;-)

By the way, the release of Mac Film Gimp was announced today.

http://filmgimp.sourceforge.net/press/filmgimp.pr.02.12.5.html

i had this week off from work, which is a very very rare thing.

You work? Didn't you say you don't believe in money, that you oppose on principle open source developers being paid?

Pardon my curiosity. Are you working for free? What do you do?

Cheers,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

On 2002-12-06 at 0001.06 -0800, Robin Rowe typed this:

Carol,

You work? Didn't you say you don't believe in money, that you oppose on principle open source developers being paid?

Pardon my curiosity. Are you working for free? What do you do?

i sell groceries for a small family owned chain of discount grocery stores here in Michigan. and i love it. too bad they can't give me more of that imaginary stuff to do this job. i am pretty good at these fast paced service based jobs. this whole world would cease to function if they were ever to pay me as much of that imaginary stuff as i am worth.

most of this income goes for shelter, heat and light, and transportation. just because i don't believe in it doesn't mean my landlord doesn't.

i have not spent one cent on software. i suck.

poor free software developers have g/f's, children, rent/mortgage, beverage and smoke needs, etc. windows users are used to paying for software, or going some lengths to steal it. i am glad to see that the free software people are able to find some of this money. on a similar note, i have about 5 Borders Bookstores nearby that i frequent. i have taken on the job of moving the gimp books into the photoshop section where they sell. they were getting dusty on the linux shelves.

it is tempting to have a long chat about the acquistion of my computer and working with the fickle finger of fate, rather than money to get it. if you would like more about that, please email me in private ;) truthfully, i did use some money to get it.

being a citizen of the usa, there are alot of crappy stupid imaginary systems that i have to work within.

anyways, here is an ogg http://carol.gimp.org/14-I_Am_A_Grocery_Bag.ogg that will help you to understand my work day and what i like about it. (They Might Be Giants, from their childrens album. good stuff)

one fact so far in my life is this: the amount of money i give for something rarely has anything at all to do with the value or quality of the item. another fact: some of the best things *are* free.

carol

(ps, i guess that winamp can play oggs, if you are on a windows box)

Hi,

Carol Spears writes:

i am so interested in getting the web site for 1.2 off from my computer and start work for the wgo-1.4. as it is, i cannot even share the location.

i had this week off from work, which is a very very rare thing. i had really wanted to move things during this week where my time was uninterupted, but the last commit to the cvs module for the site (that wasn't me) was on November 26. and now my week is almost over.

i have the week of December 15 to 21 off also. i am going to wait a few days to see if someone off from the list would like to help me with these scripting needs, then i really must get this site out of my life and off my computer. so if no one here is interested, perhaps a trip to the perl monks would help me to get these little things done.

pleas excuse me if I missed something but IIRC I'm even subscribed to the gimp-web list and in the last months I haven't heard anything about the stuff you are talking about. There has been rumours about work being done on the new web site in IRC from time to time but I don't remember any official announcements in the last months nor did I see a mail from you asking people for help. I also had no idea that there is a CVS server for the new web site nor who has access to this repository. Carol, if you want people to help you, you should perhaps start asking them for help.

Sven, nothing in your post offended me. mostly i felt bad as i tried to tag the AUTHORS file way back then. i seem to have issues with tags. maybe if you could whip together a template, i could work rocks script into spitting the AUTHORS out an xml form to your liking. his little script already does this nicely:
http://carol.gimp.org/authors.png
should be simple enough for even me to change the web page into whatever xml tags you see fit.

well, using AUTHORS is probably a bad idea since it is the ASCII-only version generated from the file contributors which also has UTF8 encoded names. I'd really like to replace this mess by something saner and I was hoping that we could come up with something that also fits the needs of the web-site authors. If you don't want us to cooperate on this subject, I'll just change the files to fit my needs (or rather the needs of the GIMP core hackers) and you'll have to do script hacking to get your page done. However I'd rather see use a format we have discussed beforehand. If you don't like XML as I suggested, perhaps we can come up with something else...

Salut, Sven

On 06 Dec 2002 14:54:37 +0100, Sven Neumann wrote:

pleas excuse me if I missed something but IIRC I'm even subscribed to the gimp-web list and in the last months I haven't heard anything about the stuff you are talking about. There has been rumours about work being done on the new web site in IRC from time to time but I don't remember any official announcements in the last months nor did I see a mail from you asking people for help. I also had no idea that there is a CVS server for the new web site nor who has access to this repository. Carol, if you want people to help you, you should perhaps start asking them for help.

I have exactly the same feeling. The last useful information posted to the gimp-web list (besides some spam and viruses) was in February. I thought that it was dead and that I would have to maintain the old site forever, until I saw some links to something that could look like a new site. But there was no discussion about the structure of that site, how it would be managed, and so on. This is very frustrating because I had made some suggestions on the gimp-web mailing list and it looks like the discussion died and some things were developed without taking any suggestions or offers for help into account.

-Raphaël

On Thu, 5 Dec 2002 12:55:00 -0500, Carol Spears wrote:

On 2002-12-05 at 1759.57 +0100, Rapha?l Quinet typed this:

On Thu, 5 Dec 2002 10:20:28 -0500, Carol Spears wrote:

i am worried that if you make it too hard of a job, you will scare away anyone that might like to help.

Well, I think that both Sven and I agree on the fact that we should not try to build the list of GIMP contributors automatically. Updating it by hand is the best solution for the moment, because any automated solution would be far too complex or unfair (having an unfair list is probably worse than having no list or an outdated list).

i would like a web page that shows the last 10 people who contributed are mentioned in the ChangeLog. i don't know of asking any opinions. is there something there in the list of the last 10 which should not be shared?

It looks like there was a misunderstanding about what you were trying to do. The discussion started around an attempt to get an updated version of the list of GIMP contributors. When you posted your questions and proposal, I thought that you intended to update the AUTHORS file automatically, because it was not obvious that you were talking about something different.

Sorry for not understanding you correctly. But next time, please explain clearly what your goals are. ;-)

i am not going to change this by hand everyday.

Yes, this makes sense now that the context is clear.

Best regards, -Raphaël

On 2002-12-06 at 1454.37 +0100, Sven Neumann typed this:

Hi,

pleas excuse me if I missed something but IIRC I'm even subscribed to the gimp-web list and in the last months I haven't heard anything about the stuff you are talking about. There has been rumours about work being done on the new web site in IRC from time to time but I don't remember any official announcements in the last months nor did I see a mail from you asking people for help. I also had no idea that there is a CVS server for the new web site nor who has access to this repository. Carol, if you want people to help you, you should perhaps start asking them for help.

the list is still up and working at your request. they don't answer me. i think most of the people on this list are looking for a loving little community and gug would fill their gimp interests better.

if you would like me to ask them for help, again, how long should i give them to respond this time? my experience with this list is that they don't respond.

from the first moment that list became a fact, i was able to see the gimp mechanism at its best. from the original news being sat upon until something more interesting could supercede it (and in all due respects, a polish tutorial simply is more important than any web site project) to the complete lack of any response to any mailing .... anyways, my design will hopefully help to keep other new unsuspecting gimp users from some of the same problems i had.

but that list still exists because someone else insisted on it staying alive.

i have a problem. i am not able to get the site far enough along to move it off from my computer. there is a good chance that this is because i am a control freak, i dunno. but on the otherhand, i am not able to announce the site because it is on a poopy little server.

i am very proud of what is there. i still have hope for the news part, but i have to get out irssi to get an email. for all my bitching and whining, i have had a good team so far. i just don't know why i need to be on the irc for them to commit. a flaw in the construction design, i guess. this flaw will not translate into the actual operation of the site. i have done everything humanly possible to keep the information easily maintainable, as long as the stuff i grab from this tree or another is being kept up to date. and hopefully the information on the website will be objective, not subjective as it has been in the past.

so, the situation with 1/3 of a site designed and working but on a poopy server has reduced me to farts and burps and the occasional belch when asking for help. i am sorry to have such communitive gas on the developer list.

i am also sorry that i have to stop having this gas to assure everyone that i am not interested in messing with the gimp source. why is that? is there a list of everyone who has solemnly vowed not to touch the gimp source that could be emailed to this list once a week so that everyone can relax?

carol

On 2002-12-06 at 1454.37 +0100, Sven Neumann typed this:

Hi,
well, using AUTHORS is probably a bad idea since it is the ASCII-only version generated from the file contributors which also has UTF8 encoded names. I'd really like to replace this mess by something saner and I was hoping that we could come up with something that also fits the needs of the web-site authors. If you don't want us to cooperate on this subject, I'll just change the files to fit my needs (or rather the needs of the GIMP core hackers) and you'll have to do script hacking to get your page done. However I'd rather see use a format we have discussed beforehand. If you don't like XML as I suggested, perhaps we can come up with something else...

Simon Budig made an xml form that worked somewhat, however all the web designer could say was "uck". i worked and worked with the form to see if i could get it to obey the css. no go. i asked for help, lord knows. there is a good chance that i don't ask while you and mitch are about, as i really don't want to interrupt what you are doing. i believe in what you are doing very much.

i found the form very difficult to work with, and i was only able to view it in a browser that could interpret xml. i could not get any of the html rendering apps to work. it was really looking once again like a plan that only Rapha?l could maintain.

the site i have (which is somewhat working) uses the apache mod_include http://httpd.apache.org/docs/mod/mod_include.html and i have been trying to steer everyone towards using python for any cgi needs. why python? because even i can understand the way it handles regexp. maybe i can't write it very eloquently yet, but i can read it. if i can work with this ssi stuff and python, my bet is that anyone can.

are the files in gimp-1.2 going to change much? i guess "no", and that the script that rock wrote will work perfectly until gimp-1.2 disappears. if the AUTHORS file will be in a different form for gimp-1.4 then that will need to be addressed for that web site. maybe the way that my current plan handles it will work there also, i dunno. right now, a different sort of AUTHORS file is hypothetical.

i feel like i am racing mitch, and loosing. i will be ready with the 1.2 site sometime after 1.4 is released. seems silly to spend a lot of time making this version of the site able to handle information that doesn't exist yet.

i tell you what though. the guest lecturer stopped me from making a million little includes files, one each for the name, homepage and email of urls that will be on the site. i am sort of mad and frustrated about that as well. it was a solution to a problem i have, and that is how to easily update urls and emails and such. probably it is better that i was stopped, but i prefer to be redirected than simply stopped.

perhaps a little address book for the gimp, something that could be accessed by anything needing up-to-date urls and emails. something that could be maintained in *one* place. would this meet both the needs of the web and the developers?

some of the problem might be that i am unable to ask for help. look at all of this typing to this list!! crap. i hate spam to this list and today and yesterday, i am the *worst* offender.

carol

On 2002-12-06 at 1516.57 +0100, Rapha?l Quinet typed this:

On 06 Dec 2002 14:54:37 +0100, Sven Neumann wrote:

pleas excuse me if I missed something but IIRC I'm even subscribed to the gimp-web list and in the last months I haven't heard anything about the stuff you are talking about. There has been rumours about work being done on the new web site in IRC from time to time but I don't remember any official announcements in the last months nor did I see a mail from you asking people for help. I also had no idea that there is a CVS server for the new web site nor who has access to this repository. Carol, if you want people to help you, you should perhaps start asking them for help.

I have exactly the same feeling. The last useful information posted to the gimp-web list (besides some spam and viruses) was in February. I thought that it was dead and that I would have to maintain the old site forever, until I saw some links to something that could look like a new site. But there was no discussion about the structure of that site, how it would be managed, and so on. This is very frustrating because I had made some suggestions on the gimp-web mailing list and it looks like the discussion died and some things were developed without taking any suggestions or offers for help into account.

i will write a history of the design, and a plan to finish the design and send it to that list. however, if only people that own gimp.org addys or people who respond often on this list reply, lets agree to close it. i really think the people joined on that list are interested in a community thing, like gug.

as Robin pointed out earlier this week, it can be very difficult to work with the eh, gimp machine. in some ways, i feel like i lied to a nice dane, then threw him into the crazed duck pit and was still able to get a great design from him. probably there exists a better way to get things going, but i was unable to find it.

also, i don't really want to be part of a site whose contents get determined by a vote. i have one clear example of an intelligent yet uninformed user to make a page for. i am going to make that site for her. i would like to make a site where she can feel involved and not feel over her head. i don't know if the gimp web mail list can help me with that.

here is some history that i don't want to share with the web list though. i had a techie. one of the good old stable gimp people, one of my favorites. since trying to be involved with gimp things, i have felt like ultimately, i need to keep two entities happy (two entities consisting of three people, btw). my first techie was axed by one of the entities yet the other entity kept insisting that i wait for him to return. it took approximately 9 to 10 months to work through this. so other offers of help were ignored or what have you.

i am sorry that so many offers where shunted away. carol

On 2002-12-06 at 1526.22 +0100, Rapha?l Quinet typed this:

It looks like there was a misunderstanding about what you were trying to do. The discussion started around an attempt to get an updated version of the list of GIMP contributors. When you posted your questions and proposal, I thought that you intended to update the AUTHORS file automatically, because it was not obvious that you were talking about something different.

Sorry for not understanding you correctly. But next time, please explain clearly what your goals are. ;-)

i have been living eating breathing this damn web site for too long. i cannot share things about it until i advance with it. i cannot advance without sharing it.

perhaps we can move it to a server where it can be shared?

i am not ready to move it to another cvs server. i am happy to give cvs access. i could prolly even wheedle through getting annoncvs access as well.

i am having problems though, where i see everyday web business and get all excited about a simple web solution.

there was an idea of a gimp cookbook on the irc. this one idea has done so much to destroy my life and happiness, i cannot tell you. now, i cannot see people getting script help without feeling dismay at all the knowledge that continually gets lost because there is no apparatus to store it nicely. i can't stand it sometimes.

i am not going to change this by hand everyday.

Yes, this makes sense now that the context is clear.

i dunno why i have to constantly remind Sven that they made me vow not to ever touch the gimp source. you can trust that any of my ideas since then are only how to use what is there already. if i need a change, i will ask nicely through bugzilla i guess.

so, when i am typing incoherently due to frustration, secrets and an inability of mine to keep a secret, please give me the benefit of the doubt and don't be so damn protective of your precious source. i promised not to touch it already and have been not touching it, thank you.

carol

On 6 Dec 2002, Sven Neumann wrote:

well, using AUTHORS is probably a bad idea since it is the ASCII-only version generated from the file contributors which also has UTF8 encoded names.

Actually, it reads contributors and not AUTHORS. It's just your script that creates AUTHORS, etc, hacked up to generate a web page.

I'd really like to replace this mess by something saner and I was hoping that we could come up with something that also fits the needs of the web-site authors.

I'm certainly willing to discuss this.

If you don't want us to cooperate on this subject, I'll just change the files to fit my needs (or rather the needs of the GIMP core hackers) and you'll have to do script hacking to get your page done. However I'd rather see use a format we have discussed beforehand. If you don't like XML as I suggested, perhaps we can come up with something else...

XML is probably overkill, but anything is fine as long as it is easily parsed. Our biggest need right now is a latin-1 version of the names with special charactors. The web page needs to be in latin-1 because most web browsers aren't very good with UTF-8. Right now I'm running recode manually, and then hand-editing the file because recode seems to chew off some perfectly normal looking characters from the file.

Perhaps the header/footer text of the web/AUTHORS/*.h files can be embedded in the contributors file, or, more cleanly, the script would take two files, one of which is a stylesheet-type thing that the script uses to create the output file from the contributors file.

Rockwalrus

On 2002-12-06 at 1320.24 -0800, Nathan Carl Summers typed this:

On 6 Dec 2002, Sven Neumann wrote:

well, using AUTHORS is probably a bad idea since it is the ASCII-only version generated from the file contributors which also has UTF8 encoded names.

Actually, it reads contributors and not AUTHORS. It's just your script that creates AUTHORS, etc, hacked up to generate a web page.

I'd really like to replace this mess by something saner and I was hoping that we could come up with something that also fits the needs of the web-site authors.

I'm certainly willing to discuss this.

If you don't want us to cooperate on this subject, I'll just change the files to fit my needs (or rather the needs of the GIMP core hackers) and you'll have to do script hacking to get your page done. However I'd rather see use a format we have discussed beforehand. If you don't like XML as I suggested, perhaps we can come up with something else...

XML is probably overkill, but anything is fine as long as it is easily parsed. Our biggest need right now is a latin-1 version of the names with special charactors. The web page needs to be in latin-1 because most web browsers aren't very good with UTF-8. Right now I'm running recode manually, and then hand-editing the file because recode seems to chew off some perfectly normal looking characters from the file.

rockwlrs, is this something that i can do?

carol

On Wed, 04 Dec 2002 10:56, Robin Rowe wrote:

[Raphaël Quinet wrote:]

I don't know if this list should be updated or not. Maybe when the new site design is ready?

For an up-to-date GIMP contributor list see the bottom of http://filmgimp.sourceforge.net/people/index.html .

As you have probably seen in the recent discussions on the gimp-developer mailing list, it is not easy to get a correct list of contributors. ;-) Looking only at the CVS commits or at the authors of the ChangeLog entries is unfortunately not fair to those who do not have CVS write access and whose patches are committed by someone else. Let's see what comes out of the discussion on the gimp-developer mailing list...

Offer an optional MDI interface and menubar on top of the window (bug #7379 and bug #52305).

Film Gimp already has menus across the top of the window. MDI is coming as part of a GUI redesign in 2003.

Yes, this is interesting. I hope that we can cooperate on that and share some code instead of implementing the same feature twice in slightly different ways. I have just posted some comments about that in bug #7379. Feel free to add your own comments there or to discuss it on one of these lists if you think that we can do some things together.

Implement a macro recorder (bug #51937).

I'll be implementing that in Q1 2003 for Film Gimp. My approach to macro recorder/player design is very different from yours. I'm won't be using Scheme, and intend to implement at the GTK+ toolkit level rather than the application level. Although our purpose is similar, you need not worry that our designs would be any duplication of effort. You may write as much Scheme as you like with no concern I would be doing the same. ;-)

The GIMP macro recorder will not be using Scheme either. I think that you misunderstood how it is supposed to work, but hopefully the comments that have been added recently to bug #51937 by Hans Breuer and myself should clarify this issue. Basically, the macro recorder will be a core function that records the list of PDB calls made by the tools or plug-ins. Once the list of calls has been recorded, it can be written as a Python script, or Perl, or Script-Fu (Scheme) or maybe Tcl, depending on what the user wants. The user will then be able to edit this script to add customizable parameters to some functions or to add some comments and documentation before distributing it.

It looks like what you have in mind is not a script recorder, but something closer to an event recorder. If I understand you correctly, you plan to record the GTK+ events and play them back later. This is very similar to what is done by GERD. See bug #82648 for more details. The advantage of this approach is that it is easier to implement (especially if you re-use the GERD code) but it is not very flexible: it would be hard to convert this into a script that can be called with different parameters (i.e., allowing the user to select some colors, patterns, fonts, effects, etc.) because these things are not seen on the GTK level.

Merging both does not require the removal of features from either tool.

GIMP has a reputation for adding more and more features. Film Gimp developers are of the opinion that some features are worth removing.

Film Gimp users and developers are not satisfied with the way Film Gimp works now, and are willing to entertain radical change. At the same time, Film Gimp has a priority for stability and bug removal that comes ahead of features. In these ways Film Gimp is both more radical and more conservative than GIMP.

I would say that the GIMP is also more radical and more conservative than the GIMP. ;-) It just depends on what version you are talking about. Version 1.2.3 has been released in February and we are still fixing bugs before the 1.2.4 release, so there is obviously a strong focus on stability. Personally, I haven't done much on the 1.3.x branch and I have spent most of my time taking care of Bugzilla and fixing bugs on the stable branch. The 1.3.x branch is a radical change from the previous branch because many parts have been re-written in order to have a cleaner separation between the core and the GUI. Also, it has been ported to GTK+ 2.0, which should provide a better stability and portability. You will not find many new user-visible features in the development branch (new docks, new text tool, re-organization of some tools) because most of the work is about cleaning up the code, not adding new features.

Film Gimp provides an opportunity to accomplish things that wouldn't be done in GIMP. However, nothing is lost. We are watching what GIMP and other open source projects do, looking for ways to incorporate features that seem desirable for Film Gimp. And, perhaps something we implement for Film Gimp will later prove useful to other projects.

I don't know how I should understand these statements. After reading some of the previous mails, it looked like it would be possible to merge GIMP and Film Gimp again, although not in the near future. But now, after reading this and some other comments (i.e., suggesting to re-write Film Gimp in C++), I have the feeling that it will not be possible. Some users or developers would like Film Gimp to become more and more independent from the GIMP, without attempting to converge whenever possible. This is sad. This means that some Film Gimp developers do not want to contribute anything back to the GIMP. On the other hand, this means that a lot of work will have to be invested in re-implementing some GIMP features in Film Gimp. :-(

-Raphaël

Raphaël,

For an up-to-date GIMP contributor list see the bottom of http://filmgimp.sourceforge.net/people/index.html .

As you have probably seen in the recent discussions on the gimp-developer mailing list, it is not easy to get a correct list of As you have probably seen in the recent discussions on the gimp-developer mailing list, it is not easy to get a correct list of contributors. ;-) Looking only at the CVS commits or at the authors of the ChangeLog entries is unfortunately not fair to those who do not have CVS write access and whose patches are committed by someone else. Let's see what comes out of the discussion on the gimp-developer mailing list.

The point is that the ChangeLog is more accurate than the credits list on GIMP's own Web site. Because I brought the topic up, the GIMP list is now debating how best to put together a perfect contributor list. Some people feel that being fair means being perfect sometime later, but I think that being fair involves doing your best with what you have now.

For the time being anyway, the Film Gimp Web site has a more accurate list of GIMP contributors than GIMP's own Web site. When you have something better please let me know so I can update our Web page appropriately.

Some users or developers would like Film Gimp to become more and more independent from the GIMP, without attempting to converge whenever possible.

We are independent. It is only certain people who imagine otherwise. ;-)

Cheers,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

On 7 Dec 2002, at 18:19, Robin Rowe wrote:

Raphaël,

For an up-to-date GIMP contributor list see the bottom of http://filmgimp.sourceforge.net/people/index.html .

As you have probably seen in the recent discussions on the gimp-developer mailing list, it is not easy to get a correct list of As you have probably seen in the recent discussions on the gimp-developer mailing list, it is not easy to get a correct list of contributors. ;-)

Hi Robin,

Seeing how you got everything the past few days, from light rebukes that you don't want to live with your parents anymore ("but it'll be so much cheaper if we can do the laundry together!") to outright abuse ("Windows user!" -- and the little troll meant it, too), I would like to compliment you and your team on following The Right Way. You felt an itch, nobody was going to scratch it for you (despite numerous requests -- "no, no, first we do the laundry, then we implement 16bpp/fp)"), so you scratched it yourself. In the free software world, that _is_ the right thing to do.

However, one small negative criticism: that photo on ... Do you know
that there is a free photo editing tool called the GIMP that can fix it? You should try it someday. ;-)

Simple way to fix red eye: select the eye, select only the red channel, desaturate. Repeat for other eye. Try other channels for Bowie effect.

On Sun, Dec 08, 2002 at 12:31:18AM +0100, Rapha?l Quinet wrote:

Offer an optional MDI interface and menubar on top of the window (bug #7379 and bug #52305).

Film Gimp already has menus across the top of the window. MDI is coming as part of a GUI redesign in 2003.

Yes, this is interesting. I hope that we can cooperate on that and share some code instead of implementing the same feature twice in slightly different ways. I have just posted some comments about that in bug #7379. Feel free to add your own comments there or to discuss it on one of these lists if you think that we can do some things together.

I'm sorry, I must have missed it. Was the plan to have MDI as an option, or to make everything MDI only?

Branko,

... I would like to compliment you and your team on following The Right Way.

The Film Gimp team deserves more credit than I for what's been accomplished. Others toiled in secret for years on Film Gimp before I joined the project this summer. Since going public, new developers have joined Film Gimp and helped it succeed even more.

The Mac Film Gimp port team, all Film Gimp newcomers by the way, have done a fabulous job! The Mac version released this week had been planned for 2003. Completed ahead of schedule.

Simple way to fix red eye: select the eye, select only the red channel, desaturate. Repeat for other eye. Try other channels for Bowie effect.

Thanks for the great tip on how to remove red-eye! I may put that into the Film Gimp documentation.

Removing the red-eye in my "glamour" shot on the People page wasn't high on my to-do list, but since you point it out as objectionable I will correct that right away. Appreciate the feedback!

Cheers,

Robin --------------------------------------------------------------------------- www.FilmGimp.org
www.LinuxMovies.org
www.OpenSourceProgrammers.org

jdboyd@cs.millersville.edu (2002-12-08 at 1225.19 -0500):

I'm sorry, I must have missed it. Was the plan to have MDI as an option, or to make everything MDI only?

I hope option. BTW, anybody know how to disable the film gimp menu in each window and get back to plain old gimp window?

GSR

On 08-Dec-2002, Branko Collin wrote:

You felt an itch, nobody was going to scratch it for you (despite numerous requests -- "no, no, first we do the laundry, then we implement 16bpp/fp)"), so you scratched it yourself. In the free software world, that _is_ the right thing to do.

Yes yes, but what about people like me who are both too busy with other projects, and dont have the coding expertise to build a spfp rendering pipeline for gimp? I need the spfp rendering pipeline for my project. So, um, could someone scratch an itch for me? I cant reach...

rower@MovieEditor.com (2002-12-08 at 1133.54 -0800):

Hi. Pardon a silly question, but if you want "plain old gimp" why not use plain old GIMP?
Just curious.

I hope option. BTW, anybody know how to disable the film gimp menu in each window and get back to plain old gimp window?

Err, not clear enough? Another try: "Make Film Gimp not show the menu in the top area of every window, only make it visible via MB3 click or by being dettached (doable with GTK+1.2, but new feature, so probably a no-no) or click arrow in top left corner (new feature, so probably another no-no)."

I guess the reply is no too, I have not found any hint about the top menu being removable if the user does not need it. If anybody know what I did not saw in the code, and that would make the "always visible" menu go away cleanly (currently nuked by removing some code), please tell me.

GSR

Hi,

Joshua D Boyd writes:

Yes, this is interesting. I hope that we can cooperate on that and share some code instead of implementing the same feature twice in slightly different ways. I have just posted some comments about that in bug #7379. Feel free to add your own comments there or to discuss it on one of these lists if you think that we can do some things together.

I'm sorry, I must have missed it. Was the plan to have MDI as an option, or to make everything MDI only?

there is no such plan. Raphael is only discussing some ideas he has. We might add an option to have a menu-bar per display but Raphael will have a hard time to convince Mitch and me to add any kind of MDI interface with windows in windows, not even optional.

Salut, Sven

On Fri, 29 Nov 2002, Sam Richards wrote:

I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for "High Dynamic Range" imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images.

Notice that the latest series of graphics cards from nVidia and ATI (and others) support floating point all the way through to the frame buffer. This will mean that the 3D rendering community (games, simulation, etc) will be very interested in floating point image processing and storage in the very near future.

I would urge everyone to consider floating point pixels rather than just going to 16 bit. This is a big change and you only want to make it once.

----
Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On 09 Dec 2002 12:44:31 +0100, Sven Neumann wrote:

Joshua D Boyd writes:

I'm sorry, I must have missed it. Was the plan to have MDI as an option, or to make everything MDI only?

there is no such plan. Raphael is only discussing some ideas he has. We might add an option to have a menu-bar per display but Raphael will have a hard time to convince Mitch and me to add any kind of MDI interface with windows in windows, not even optional.

I expected that you and Mitch would be against it. ;-) I was originally against it as well, because this is hard to implement in GTK (or X11 in general) and other environments (Windows) seem to be moving away from the MDI model. However, I have changed my mind since then.

I will add some comments about that in bug #7379 so I recommend that you take a look at http://bugzilla.gnome.org/show_bug.cgi?id=7379 for more details, but in summary let's say that after reading some documents about user interface guidelines, I think that the WiW MDI model would be appropriate for the GIMP (as an option, of course).

The GIMP is currently using a Controlled Single Document Interface (CSDI) and would not work well with a modal MDI for the images (tabbed interface like in Mozilla or gedit) but it would work well with a WiW MDI like in Photoshop, Paint Shop Pro or most other painting tools. There are several reasons for that. I am in a hurry for the moment so I cannot write a longer mail (sorry!) but I will try to add some comments later today in bug #7379.

Best regards, -Raphaël

On 09-Dec-2002, Stephen J Baker wrote:

On Fri, 29 Nov 2002, Sam Richards wrote:

I would like to stress that some of the film-industry interest in filmgimp is as much for the floating point as the 16 bit. The need for floating point is for "High Dynamic Range" imagery which is used as a lighting tool, and not for final delivery. So while I can believe that many films can sucessfully be rendered in 8-bit, its quite possible that at least some of those films will be using HDR imagery, so there will be a need for a paint system that can help touch up these images.

Notice that the latest series of graphics cards from nVidia and ATI (and others) support floating point all the way through to the frame buffer. This will mean that the 3D rendering community (games, simulation, etc) will be very interested in floating point image processing and storage in the very near future.

I would urge everyone to consider floating point pixels rather than just going to 16 bit. This is a big change and you only want to make it once.

Erm, thats kinda cool, but unless we can access that framebuffer, it wont be useful to us. We'll still be stuck writing to the 8bit per channel 2D framebuffer. (Now, of course, we could chop the final display image into GL texturers, and display that, but that requires a spfp per channel GL texture mode.)

Ive been asking for spfp per channel rendering for a totally different reason: not only can you have numbers above pure white (> 1.0) and below pure black (< 0.0), but you can properly use SSE to accelerate FP calculations (using gcc 3.2.x and up with -msse and -mfpu=sse,387. On my Intel P3, apps that heavly used spfp math had a speed increase of 2x-4x, all due to the extra execution units chugging along.)

This also helps with HDR too. HDR is a spfp per channel storage mode, used by several high end industry apps. Those included is Lightwave, the famous 3D modeling/rendering application. With HDR enabled (and saving in a HDR format), you can alter the final image to bring out more detail from shadows and such by just altering the gama ramp, Due to the huge ammount of data, you wouldnt notice the difference the "fixed" copy, and the entire image rerendered with new lighting settings to correct the "mistake:" the least significant bit of data is still below even 16-bit per channel display modes.

On Mon, 9 Dec 2002, Patrick McFarland wrote:

Notice that the latest series of graphics cards from nVidia and ATI (and others) support floating point all the way through to the frame buffer. This will mean that the 3D rendering community (games, simulation, etc) will be very interested in floating point image processing and storage in the very near future.

I would urge everyone to consider floating point pixels rather than just going to 16 bit. This is a big change and you only want to make it once.

Erm, thats kinda cool, but unless we can access that framebuffer, it wont be useful to us. We'll still be stuck writing to the 8bit per channel 2D framebuffer. (Now, of course, we could chop the final display image into GL texturers, and display that, but that requires a spfp per channel GL texture mode.)

I'm not suggesting that this would be useful to GIMP - but that other developers who are working in 3D using modern rendering hardware will soon need support for 32 bit floating point texture maps.

So, I was pointing out that floating point imagery is soon going to be important to many other user communities outside of the film industry and it follows that floating point images ought to be loadable, editable and save-able from within mainstream GIMP.

IMHO, that's a better route to take than going to 16 bit or even integer 32 bit.

Ive been asking for spfp per channel rendering for a totally different reason: not only can you have numbers above pure white (> 1.0) and below pure black (< 0.0), but you can properly use SSE to accelerate FP calculations (using gcc 3.2.x and up with -msse and -mfpu=sse,387. On my Intel P3, apps that heavly used spfp math had a speed increase of 2x-4x, all due to the extra execution units chugging along.)

You could use a modern graphics pipeline for that too - but it's a lot less friendly to code for - and it won't port to all graphics cards - so it's probably not likely to be a thing that GIMP would want to make use of.

On something like an ATI Radeon 9700 or the upcoming nVidia GeForceFX, you can create floating point texture maps - and use the incredibly fast 'fragment shader' processor to composite, scale, rotate, perspect, tile or otherwise process them into the floating point frame buffer, then read that back into the CPU at the end. Whether that's faster than doing it in the CPU alone depends on the complexity of the per-pixel processing - for complex per-pixel operations, I'd expect the graphics card to be able to beat the CPU - but for simple operations the data transfer overheads into and out of the graphics card would kill you.

The nVidia card also supports a 16 bit 'half float' format which would be interesting for HDR.

This also helps with HDR too. HDR is a spfp per channel storage mode, used by several high end industry apps. Those included is Lightwave, the famous 3D modeling/rendering application. With HDR enabled (and saving in a HDR format), you can alter the final image to bring out more detail from shadows and such by just altering the gama ramp, Due to the huge ammount of data, you wouldnt notice the difference the "fixed" copy, and the entire image rerendered with new lighting settings to correct the "mistake:" the least significant bit of data is still below even 16-bit per channel display modes.

There were a bunch of papers at SigGraph last year about rendering HDR images on a standard display without losing important visual information.

All interesting stuff.

---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On 09-Dec-2002, Stephen J Baker wrote:

I'm not suggesting that this would be useful to GIMP - but that other developers who are working in 3D using modern rendering hardware will soon need support for 32 bit floating point texture maps.

So, I was pointing out that floating point imagery is soon going to be important to many other user communities outside of the film industry and it follows that floating point images ought to be loadable, editable and save-able from within mainstream GIMP.

IMHO, that's a better route to take than going to 16 bit or even integer 32 bit.

Im not saying Gimp3D here: Im just saying using GL as an advanced framebuffer. Unless X (or win32) itself supports the spfp bitdepths, then our only recourse would be to use GL textures as a framebuffer to display the image.

Ive been asking for spfp per channel rendering for a totally different reason: not only can you have numbers above pure white (> 1.0) and below pure black (< 0.0), but you can properly use SSE to accelerate FP calculations (using gcc 3.2.x and up with -msse and -mfpu=sse,387. On my Intel P3, apps that heavly used spfp math had a speed increase of 2x-4x, all due to the extra execution units chugging along.)

You could use a modern graphics pipeline for that too - but it's a lot less friendly to code for - and it won't port to all graphics cards - so it's probably not likely to be a thing that GIMP would want to make use of.

On something like an ATI Radeon 9700 or the upcoming nVidia GeForceFX, you can create floating point texture maps - and use the incredibly fast 'fragment shader' processor to composite, scale, rotate, perspect, tile or otherwise process them into the floating point frame buffer, then read that back into the CPU at the end. Whether that's faster than doing it in the CPU alone depends on the complexity of the per-pixel processing - for complex per-pixel operations, I'd expect the graphics card to be able to beat the CPU - but for simple operations the data transfer overheads into and out of the graphics card would kill you.

The nVidia card also supports a 16 bit 'half float' format which would be interesting for HDR.

All of thats basically worthless to us _except_ for non-real "preview" modes where it doesnt matter if the image looks perfect, because its just an approximation. We cant use it for real rendering, because an xcf has to look the same on _all_ machines that view it. That means no matter what video card I have, it has to look the same on someone else's box, no matter what video card he/she has.

The half float mode might be slightly useful for imitating a 16-bit per channel display. But that goes back to using gl textures as a framebuffer.

There were a bunch of papers at SigGraph last year about rendering HDR images on a standard display without losing important visual information.

All interesting stuff.

That wouldnt make alot of sense. HDR isnt ment for "displaying." Its ment for holding extra data that otherwise would be lost. For a final end target (eg png, jpg, dvd) the extra HDR data is thrown out because it is no longer needed.

On Mon, 9 Dec 2002 17:12:45 +0100, Raphaël Quinet wrote:

The GIMP is currently using a Controlled Single Document Interface (CSDI) and would not work well with a modal MDI for the images (tabbed interface like in Mozilla or gedit) but it would work well with a WiW MDI like in Photoshop, Paint Shop Pro or most other painting tools. There are several reasons for that. I am in a hurry for the moment so I cannot write a longer mail (sorry!) but I will try to add some comments later today in bug #7379.

FYI, I have added some comments to bug #7379 yesterday. Simon has already added an interesting suggestion. So if you want to know what this is about, please have a look at: http://bugzilla.gnome.org/show_bug.cgi?id=7379 Feel free to add your comments to that bug report or to discuss this on the mailing list(s).

-Raphaël

P.S.: I don't know if the FilmGimp developers are interested in this. Should I continue cross-posting to the FilmGimp list?

Hi,

"Stephen J Baker" writes:

So, I was pointing out that floating point imagery is soon going to be important to many other user communities outside of the film industry and it follows that floating point images ought to be loadable, editable and save-able from within mainstream GIMP.

IMHO, that's a better route to take than going to 16 bit or even integer 32 bit.

the plan is not to have 16 bit or 32 bit or floats but to offer a framework that allows to handle image data more or less independently of its representation. GEGL is the framework and it already supports floating point, 8bit and 16bit integer. Adding more data formats shouldn't a the major problem.

Salut, Sven

On 10-Dec-2002, Sven Neumann wrote:

the plan is not to have 16 bit or 32 bit or floats but to offer a framework that allows to handle image data more or less independently of its representation. GEGL is the framework and it already supports floating point, 8bit and 16bit integer. Adding more data formats shouldn't a the major problem.

This is why I want film gimp to use gegl at its core, instead of the old gimp engine. Gimp and Film Gimp cant be limited in any way in the core of the program, so being able to support any bitdepth is extreamly important.

Though, what needs to happen is that the internal rendering core, and all plugins need to support _atleast_ one major format, and that would be RGB/RGBA 32-bit float (aka spfp) per channel.

Preferably, gegl would choose the best format (RGBA spfp for RGB, CYMK spfp for CYMK, and maybe a YUV spfp format? That could be useful for film gimp) for rendering and data transmission between modules/plugins. (It would choose the highest bitdepth option for the colorspace.)