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 ([EMAIL PROTECTED]) 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
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
> - 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
> - 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
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
- 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
- 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
> - 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
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
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
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
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Gimp-developer mailing list