I just realized, that the Cc: of the original mail was sent with the wrong From: line. So here it is again for the list members...

Mark Shuttleworth (mark@hbd.com) wrote:

Image manipulation is one of the key application areas that needs to be addressed for open source tools to become the mainstream desktop environment. I'm currently funding a number of different open source projects, and am considering funding work on the GIMP or CinePaint.

Nice to hear that.

I've had some discussions with Robin Rowe on the CinePaint front, and would also like to hear from the GIMP community, to help me figure out what the most effective strategy will be.

My goals are:

- to help open source tools reach the point where they compete with Adobe Photoshop for professional use. I understand that the GIMP is a fantastic tool already, as is CinePaint, and that both have some features which are better than any commercial tool, but it's also clear that they both need considerable further work before they become a "no brainer" choice for any professional

We definitely work towards a mature and professional image manipulation program, but we don't want to permanently have to catch up with Photoshop. We want to develop our own ideas and limiting our scope to the set of features of Photoshop won't bring new ideas into image manipulation.

So our goal is to develop an image manipulation program that rocks, is ready for professional use, and also have lots of fun while developing it.

- to create capacity in these tools for high end digital photography, cinematography and printing

We definitely want to be able to provide this.

- to integrate with the best and latest in open source desktop environments, to comply with user interface guidelines and to perform well in usability and discoverability

While we are careful before adopting each and every idea of some guidelines, we indeed want to enhance the usability. We are also very eager to enhance the interoperability. The two major desktop environments - Gnome and KDE - collaborate to enhance their interoperability. When they agree on a common standard (usually published at freedesktop.org) we usually adopt this standard. Examples are Drag'n'Drop (XDND), the WMspec guidelines, desktop entries and thumbnail management.

- there is no goal number 4

You forgot "have fun with it" :-)

I've asked Robin if he will allow me to publish our correspondence to date, on which I'd very much like your feedback and commentary. Regardless of whether we do that, I'd like to hear from the GIMP developers and community.

You probably are aware that there are - uhm - differences between the CinePaint and GIMP developers. I'll address some of the key points below.

- Is the GIMP a good platform to build on to try to achieve these goals?

Very much so. If you look at the latest 2.0 prereleases you'll notice that there has been a great improvement on the GIMPs User-Interface. We got some enthusiastic feedback on the new user interface (compared to GIMP 1.2), and the code quality has improved a lot. It is more modularized, which e.g. enables to run the GIMP without a user interface and makes it easier to extend the GIMP with new functionality. GIMP 1.2 was a mess compared to the current codebase.

- What functionality would need to be added to the GIMP to challenge Photoshop?

I can tell you the current plans after the 2.0 release. Stuff like this has been mentioned to us as a blocker of a PS->GIMP migration and we believe that these things will help people to decide in favor of the GIMP.

- Right now GIMP internally is basically restricted to 8-bit RGBA, which is a pretty severe limitation. We want to introduce an abstraction layer for the actual image data. This enables us to use different colorspaces and different number formats for the imagedata (16-bit, float etc.). We plan to integrate with GEGL, which is currently under heavy development. As first integration step it is planned to have a GIMP release that will not yet add new colorspaces, but will be based on GEGL.

- We need to introduce a color calibration framework. Here we need to agree on a standard with other application developers.

- another issue we want to address is the layer stack. Right now it is limited to a linear stack of layers, where each layer might have a layer mask. We want to extend this to a layer tree (not necessarily visible to the user). This will enable us to have layer groups with a common mask.

- we want to introduce layer effects, i.e. layers that have an filter-like effect on the layers below (e.g. a blur layer). If we manage to do this properly this will be a killer feature.

- As mentioned above we want to further improve the interoperability. Badly needed for example is a code to cut'n'paste image data between different applications.

- How would the GIMP team use funding that was made available to them to achieve these goals?

The most important thing probably would be to fund person-to-person meetings with other GIMP developers. We had two gimp-developers conferences up to now, and they usually result in a lot of activity in the code. It also helps to improve the communication between the developers. Mail and IRC are nice tools, but cannot substitute a more personal communication.

Since the GIMP developers are distributed across the world, getting them all together is a hard task, funding would help us a lot here (We are looking for donators for the GIMPCon 2004 btw, which is scheduled to be held in parallel to the GUADEC in Kristiansand. For more information please look at http://developer.gimp.org/gimpcon/2004/ :-)

For other ways to fund the GIMP development there will be another mail by Daniel Rogers soon.

- What impact could funding have in terms of specific deliverables and timeframes?

Here I'd also like to refer to the upcoming Mail from Daniel Rogers.

- Why would the GIMP be a better project to support than CinePaint (for the purpose of attaining these specific goals)?

Ok, this is a minefield of hurt feelings and miscommunication. I'll try to keep this as prudent as possible, but there are different perceptions of the history out there, and that doesn't make it easier for me to judge about that. I'll skip the miscommunication part (feel free to ask about that) and try to stick to our perception of the facts.

FilmGimp/Cinepaint has been forked off the GIMP to explore the possibilities of higher bit-depths and movie-related editing. It came to a point where it was a useful tool for some companies and some efforts have been done to keep its codebase up to date with the codebase of GIMP up to GIMP version 1.0.4 (1998). It then became obvious that some fundamental architectural changes to the internal structure for image data had to be done to support different colorspaces and bit-depths. The goal was, to implement a sane architecture in the GIMP and then incorporate the features of FilmGimp/Cinepaint into the GIMP itself.

Up to now neither GIMP nor FilmGimp have a sane infrastructure for non-RGBA images.

However, this is basically the only part of the GIMP that still remains in the past. Everything of the GIMPs code has been refactored, redone and modularized. The relations between the internal GIMP objects (images, layers, GUI) has been clarified, so that extending the GIMP with additional functionality had become a great deal easier. Along this process it was natural to also make the GUI more consistent and I believe it was worth the effort.

I am optimistic, that with GEGL slowly becoming visible on the horizon the image-data-related architectural change is on a good track. Its integration will be a great deal easier, because the non-image-data-related architecture is lightyears ahead of Gimp 1.2.

I am not very comfortable about comparing CinePaint and GIMP, since I don't know CinePaint in-depth.

However: From what I hear about FilmGimp/Cinepaint its codebase is still basically on the level of the original fork and has not seen similiar improvements. Also it uses ancient versions of libraries, so that the CinePaint developers also have the burden to maintain this code, and when they don't upgrade the libraries, they will struggle a lot to keep up to date with e.g. current and future interoperation standards.

We believe that when we have a sane architecture for the Image data (i.e. a sane GEGL integration) it will be fairly easy to integrate movie-specific features into the GIMP. But the crucial point is the underlying architecture, and we want to get that right.

Feel free to further discuss these items. We would be very glad if you'd decide to fund the GIMP development.

On behalf of the GIMP developers Simon Budig