> - 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
