On 2002-12-03 at 1839.16 -0800, Jonathan Cohen typed this: > Hi, > > 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). 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. > i have been watching Sven gently break it to the artists that newer gimps might not be able to index until time to save. and truly, indexing is a terrible thing to do to an image, except the GIMP index changes and reduces the number of colors so nicely. that is just one mode. i use the other modes (grayscale i guess is left) as plug-ins demand them. it seems like the plans for the gimp i use has been to strip many many of the plug-ins from it, which is fine by me. overdue even. could the image modes be stripped also and made into plug-ins? i am trying to make sense of this paragraph of the R&H post. i think it says that if many of the things in the gimp core were split off, into plug-ins say, then development could continue in many camps and work not be duplicated. carol
