On Tue, 3 Dec 2002 18:39:16 -0800 (PST), Jonathan Cohen <jcohen@xxxxxxxxxx> wrote:
> I am one of the R&H engineers working on film gimp. I have previously
> posted a message describing our short term plans for film gimp
> development. Unfortunately, we have not really had time to begin on any
> of these issues yet, but we are planning on starting within the next few
> weeks to a month.
Thanks a lot for these explanations. I also have to apologize for not
being able to reply yet to some of the interesting messages in the
discussion that I started last Friday, but I will try to send some
replies later today.
[...]
> Programmer manpower is an expensive thing, and R&H allocates resources
> (Calvin, Caroline Dahllof, and myself) to gimp because it is a cost
> effective way of getting a suitable high-end paint tool. If filmgimp went
> in the direction of becoming a more general painting tool, it is entirely
> possibly that we would branch yet again and maintain our own "r&h" branch
> so that we can customize it as needed to meet our immediate day-to-day
> needs. This is not any kind of veiled threat-- it is the reality of r&h's
> relationship with gimp. gimp is a tool we will support to the extent that
> it meets our production needs.
I fully agree with this. You have your own needs and your are
certainly allowed to customize the software in such a way that it
suits you. Of course, this is even better if some of these changes
can be contributed to a larger community, but private changes are OK.
> That said, the software engineer in me is slightly saddened by the fact
> that we are duplicating (some) efforts from the gimp programmers. I'm
> sure most of what is on our todo list is on the gimp's todo list as well
> (or has already been done).
Yes, and this is the part that I was worried about. For instance, here
are the things that I am planning to work on personally (once I buy my
new PC):
1) Better support for metadata: EXIF (bug #56443) and XMP/IPTC (bug
#94416).
2) Offer an optional MDI interface and menubar on top of the window
(bug #7379 and bug #52305).
3) Implement a macro recorder (bug #51937).
This is only my personal list of goals and I do not know when these
will be implemented or whether some other GIMP contributors are
interested in these things. But this is what I am interested in, and
I certainly see a large overlap with some of the things that are
mentioned on the FilmGimp goals list. Point (1) is probably useful
for the GIMP only, but points (2) and (3) could be shared if there was
a more common codebase. These are the parts that I am the most
worried about and that encouraged me to start this discussion. This,
and the other features that are already part of GIMP-1.3.x and are
being implemented slightly differently in FilmGimp (Windows and Mac
ports, Python, etc.).
> However, some of things on our list
> definately are *not* the same. For example, we are eager to remove the
> color & index modes we do not need for performance and cleanliness
> reasons. We are seriously considering ripping out all modes except for
> 32-bit floating point. This would drastically simplify the internal
> rendering engine and allow us to optimize it significantly. Since we
> don't see any real reasons why high-end paint work could not be done
> entirely in 32-bit float, this is a reasonable thing. Obviously, for a
> general paint tool like gimp, there is no question of maintaining 8-bit
> support. For us, the need to maintain this kind of flexibility with the
> code and independence from non-high end feature requirements far outweigh
> any software engineering ideals.
Yes, this makes sense. It would be nice if this could still be
achieved by keeping a common codebase and linking a different library
for the rendering engine and/or having suitable #ifdef's in the code.
If this would be too difficult or if the resulting code would not be
clean enough, then you can of course strip out all the parts that you
do not need.
Anyway, I do not expect the GIMP and FilmGimp to be merged in the next
few weeks (or months?). But I hope that there will be some efforts
from both development teams to converge rather than diverge, at least
for the parts of the code for which this makes sense. Even if some
FilmGimp developers prefer to keep a separate branch for the code, it
would be nice if more parts of the code could be shared so that any
improvements done on one branch can also benefit the other branch. I
think that the first step is to communicate more and exchange more
ideas between the development teams. I am glad that this has started.
> I hope this clarifies our position and bit and explains the current state
> of r&h's gimp plans.
Yes, thanks!
If you are curious, here are some direct links to the bug reports
mentioned in this message:
- http://bugzilla.gnome.org/show_bug.cgi?id=51937 (macro recorder)
- http://bugzilla.gnome.org/show_bug.cgi?id=7379 (MDI model)
- http://bugzilla.gnome.org/show_bug.cgi?id=52305 (menubar in image window)
- http://bugzilla.gnome.org/show_bug.cgi?id=56443 (EXIF metadata)
- http://bugzilla.gnome.org/show_bug.cgi?id=94416 (XMP and IPTC metadata)
-Raphaël
