To: Federico Mena cc: rayl@netrover.com, Calvin Williamson , Bill Bishop , Larry Ewing , Lauri Alanko Subject: Re: happy new year! In-reply-to: Your message of "Mon, 19 Jan 1998 17:32:01 CST." <199801192332.RAA16505@luthien.nuclecu.unam.mx.unam.mx> Date: Mon, 19 Jan 1998 20:24:59 -0500 I'll begin by noting that I haven't had an opportunity to fully review all of Ray's work. At this point I would like to lay out a skeleton of where I'd like to see the Gimp going and let everyone else decide how much they agree with it. Some of this is rather ambitious. My first reaction to Ray's work is that there are a number of good ideas, but that it will be difficult to reintegrate them into the core product. I'll comment more on Ray's work when I have an opportunity to review it more closely; for now I'll limit myself to what is obvious from the toplevel of his home page. I like the idea of the tag and paint structures, but will need to look at the implementation more closely before making any recommendation. Support in here for multiple colorspaces would be a good idea as well; I know there is some interest in LAB, and possibly for other spaces such as CMYK. Might also be a good idea to support 8-bit and 16-bit resolutions with headroom and footroom; my understanding is that some types of studio video expect 0-15 and 240-255 (or perhaps other ranges) to be in the toe and head, leaving 16-239 for actual distinct colors. (This is mainly an issue when projecting an image.) Significant thought needs to be put into how plugins will interact with these changes. Lauri Alanko (who I've added to this discussion) and I have discussed schemes for backward compatiblity for plugins, so that the addition of a new image format won't necessarily require recoding every plugin to support it. ("Compatibility mode" will be slow, and may lose precision, but it's better than nothing.) Quartic mentioned my recent work with pulling drawables under Gtk's object system. I made GimpDrawable a subclass of GtkData, derived Layer and Channel from GimpDrawable, and further derived LayerMask from Channel. The implementation is not perfectly clean. However, on reflection, I'm not sure that this class structure is ideal. My present preference for class structures is the following: FrameStack (a Frame container class) Image LayerStack (a Layer container class) Frame Layer (abstract base class) DrawableLayer (contains a Drawable) AdjustmentLayer CompositeLayer (contains a LayerStack) Drawable Mask FloatingSelection (contains a reference to another Drawable) Images may also contain a FloatingSelection and one or more Masks (currently called auxillary channels). Layers may also contain a layer Mask. Masks are mostly Drawables that are limited to some grayscale type. I'm not sure if there will be any use for FrameStack except through its derived class, Image; but I'd prefer to separate them for the sake of consistenct with LayerStacks, which _do_ have a use other than through the derived Frame class. CompositeLayers are used to implement layer trees; AdjustmentLayers are "layers" that lack a drawable (except perhaps a mask) and, instead of compositing their pixels with those below them on the projection, perform some fixed operation on them. An example would be to rotate hue clockwise 60 degrees, or to flip them across the horizontal centerline. (The latter may be harder to implement efficiently.) Frames are for implementing animations without the current kludge of faking them with layers. Anyone who's tried to develop animations in the Gimp knows how annoying the restriction that each frame is a single layer is. Frames obviate this problem. Somewhat coupled with this are shared drawables, a concept Larry developed and partially implemented a few months ago. Shared layers make it much easier to put the same layer in each frame without chewing up obscene amounts of memory, and have other interesting uses as well. (Right now they suffer from an update propogation problem; the solution is obvious and would be relatively easy if TileManagers were Gtk objects.) I have a lot of concerns about how we should deal with indexed drawables. Doing composition between indexed layers is obviously problematic: you either compose their indices and get interesting, if useless, effects, or you convert to RGB or other full-spectrum colorspace and compose in that colorspace, in which case you have the problem of deciding how to convert back to indexed for the top level projection. I see no good answers here.