-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Neary wrote: | Hi, | | I hope people don't think it's out of place for me to make this | suggestion. If so, I guess ye'll just ignore it anyway... | | I think it might be useful for gegl, as well as for the GIMP, to | have a clear roadmap of things that absolutely, positively must | get done before the GIMP can use gegl. I don't really know what | those things are, but I imagine that finishing GeglImage is one, | although that goal is probably too vague to be a proper | milestone. Well, here I how I have seen things progressing. First finish GeglImage and use it and its associated classes as a first step in integrating gegl. This will make color management, 16 bit+ support, and CMYK support much easier to achieve. This will involve: 1. Eliminating TileManager and GimpDrawable and replacing it with GeglBufferedImage. (GeglBufferedImage will be the name of the concrete GeglImage subclass that just stores its Tiles in a GeglBuffer (as opposed to fetching them from an op)). GimpDrawable is the thing closest in concept to a GeglImage, atm. 2. Changing all the compositing functions to operate on a GeglImage instead of a TileManager. This shouldn't be too hard. At least while we are still using 8 bits per pixel and haven't introduced CMYK. 3. Modifing GimpImage to GeglImage. Currently, GimpImage is more akin to a stack of GeglImages. This change shouldn't be too hard (at first), from what I can tell. Mostly, the stuff that changes will be the things that use a GimpImage to get the TileManagers and GimpDrawables, and those will need to change to to acomodate (1) anyway. Anywhoo, the GimpImage, at this point, will do same thing, just keep a few pieces of data in a difference place. This will pretty much convert the core stuff to GeglImage. (if we want to avoid converting plugins we can just modifiy libgimp and preserve the existing plugin api). THIS WILL BE MILESTONE 1 After this point we need to set priorities. If getting 16 bit (higher) support is a priority we need to: 4. Revisit all the compositing functions and provide a generic version (using doubles) and probably provide specialized versions to speed up specific case. Then make sure that the correct versions of the functions are called for the correct types of GeglImage. 5. Rewrite every plugin to support these higher bit depths. If getting CMYK support is a priority we need to: 4. Revisit all the compositing functions and provide equivilent CMYK versions. 5. Rewrite every plugin (or some important ones) to know about CMYK. If we want to Do It The Right Way (TM): 5. Now start refactoring GimpImage to be a list of GeglOps instead of a list of GeglImages. GimpImage is probably where the code should go that maintains all the proper connections between the GeglOps, but, I am pretty sure, these connections don't need to be exposed to the outside world. Everything that grabs a specific layer will probably not need to be modified because it can just use the functions provided by GimpImage for manipulating layers. 6. Change GimpLayer to delegate to a GeglOp. Nothing special here. I am not sure this change will affect much that hasn't been affected already. THIS COMPLETES MILESTONE 2 Now we come the the point where adding high bit depth, CMYK, Layer groups, or layer effects means rewriting the plugins, so lets try to do this as efficiently as possible. We can try and fix the plugin alpha handling bugs as well. 7. Rewrite all the plugins. There should be a standard set of resuable implementations that delegate some amount of functionality to a GeglOp. ~ This will, obviously, require that libgimp gets revised as well. There should be things like GimpFileWritingPlugin and GimpFileReadingPlugin, GimpLayerFilterPlugin, GimpLayerTypePlugin, etc. 8. Visit all the plugins and see how the standard set of GeglOps can be used to avoid some of the work implemented in the plugin, and probably subclass a GeglOp to do the plugin specific magic. THIS COMPLETES MILESTONE 3 9. If 8 is done is a way gegl intended, we will now have 16 + bit depth support. CMYK would be able to be added, by adding the implementations for the filters in the correct slot already set aside for it. This is actually quite a bit of detail work. THIS COMPLETES MILESTONE 4 Now start considering layer groups and layer effects. 10. Layer groups requires revisiting GimpImage yet again. We will need to modify its api to work with a graph (or at least nested lists) instead of just a flat list. This will require a change to several gui elements too. THIS COMPLETES MILESTONE 5 11. Layer effects. Well, hopefully, if 8 is done in the way I concieved, it will be possible to leave a plugin running persistently. (with some modifications to libgimp, I'd imagine). This will allow layer effects to be added by simplying allowing a GimpLayer or a GimpImage to have a filter op connected to it that delegates its work to a plugin. An adjustment layer would simply me a layer that does exactly the same thing, but has no content, other than the layer effect. THIS COMPLETES MILESTONE 6 This, obviously leaves out a lot of detail, and is perhaps to far-reaching, but I think outlines an effient (in programmer time) means to move forward with gegl integration, with clearly defined milestones. ~ I deliberately left out details about how these milestones will get broken across releases. I also left out details about color management. That is a bit of an oversight, but I think that clearly defining the color spaces the Gimp works in will drasticly improve things. Besides gegl makes you consider the color space of the data you create and move around, so moving to GeglImage means to get color management for almost free. The exception being the file plugins should start reading and writing color profiles where possible. However, if you get your color into the gimp in a well defined state, the app won't need to do anything but transfrom data to the monitor colorspace on the way to the screen. | What do ye think? I think I have been thinking about this. What do you think of this stuff? I also think gegl should start releasing as soon as it is possible to move image data through the graph again. - -- Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAAYqXad4P1+ZAZk0RAtCcAJ45f3wFL02XiDbhKqnuUE0V7ine5QCffQSz RO6Df+dvCKHus9UOq/Ipd0I= =OKjR -----END PGP SIGNATURE-----
