Google
  Web www.spinics.net

Re: [Gegl-developer] Path to the GIMP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


[Video For Linux]     [Photo]     [Yosemite News]    [Yosemite Photos]    [gtk]     [GIMP Users]     [KDE]     [Scanner]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]     [Webcams]