RSS/Atom feed Twitter
Site is read-only, email is disabled

a GEGL integration strategy

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

4 of 5 messages available
Toggle history

Please log in to manage your subscriptions.

a GEGL integration strategy Øyvind Kolås 14 Dec 00:05
  a GEGL integration strategy Robert Ögren 07 Mar 22:55
   a GEGL integration strategy Øyvind Kolås 14 Mar 15:16
200412132134.13878.gwidion@... 07 Oct 20:23
  a GEGL integration strategy Øyvind Kolås 14 Dec 00:42
Øyvind Kolås
2004-12-14 00:05:09 UTC (over 19 years ago)

a GEGL integration strategy

The suggestion of starting the integration process of GEGL into gimp with the paint tools came up on irc today.

I have put some thought into the order such a conversion might happen in,

blend pencil
paintbrush
eraser
dodge
blur
clone
smudge
airbrush
ink

The order lists what I think is increasing level of complexity in usage of gegl for the
tasks, such a multipurpose gegl tool can probably be implemented and coexist with the rest of the tools while the migration happens.

This will not give us high bit depth yet though.

the list with icons can be found at:

http://pippin.gimp.org/gegl_paint_tools/

I might add more ponderings to that page later.

/pippin

Øyvind Kolås
2004-12-14 00:42:44 UTC (over 19 years ago)

a GEGL integration strategy

On Mon, 13 Dec 2004 21:34:13 -0200, Joao S. O. Bueno Calligaris wrote:

Sounds nice!

Will this take in account recent requests here of archiving changes do a drawable by event, instead of by pixel modifications ?

The first thing to do would probably to make the vector based tools fully parameterized, performing the stroke will be the same as performing an operation, along with the coordinates, and input measurements (midi devices, tilt and pressure sensors etc.).

This information can be logged, series of operations or alterations could be stored in a "hidden" effect layer chain belonging to the drawable. And serve as it's local undo history. such things bring in larger portions of the gimp
though, I think gradual inclusions and thus perhaps focus on replacing existing functionality before starting to exploit the new possibilities.

/pippin

Robert Ögren
2005-03-07 22:55:26 UTC (about 19 years ago)

a GEGL integration strategy

Hi everybody,

On Tue, 14 Dec 2004, Øyvind Kolås wrote:

The suggestion of starting the integration process of GEGL into gimp with the paint tools came up on irc today.

I have put some thought into the order such a conversion might happen in,

blend pencil

...

The order lists what I think is increasing level of complexity in usage of gegl for the tasks, such a multipurpose gegl tool can probably be implemented and coexist with the rest of the tools while the migration happens.

Please forgive me if this question is too basic, but I don't understand in which way the paint tools are going to be implemented as GEGL ops. Will each stroke be a separate node in the graph, or will several strokes be accumulated into one node? Or am I completely misunderstanding things here? What will the graph look like after a stroke with the pencil tool?

What happens when you save an image into xcf2 (or whatever it will be)? Is there a point where parts of the graph are flattened, or will all manipulations that have ever been done to the image be replayed when the image is loaded again?

(I have looked through the GEGL API docs and the GGGL pages so I think I understand the graph and operation stuff, it's the integration with GIMP I'm interested to hear more about.)

Thanks in advance Robert

Øyvind Kolås
2005-03-14 15:16:43 UTC (about 19 years ago)

a GEGL integration strategy

On Mon, 7 Mar 2005 22:55:26 +0100 (MET), Robert Ögren wrote:

Hi everybody,
On Tue, 14 Dec 2004, Øyvind Kolås wrote:

The suggestion of starting the integration process of GEGL into gimp with the paint tools came up on irc today.

I have put some thought into the order such a conversion might happen in,

blend pencil

...

The order lists what I think is increasing level of complexity in usage of gegl for the tasks, such a multipurpose gegl tool can probably be implemented and coexist with the rest of the tools while the migration happens.

Please forgive me if this question is too basic, but I don't understand in which way the paint tools are going to be implemented as GEGL ops. Will each stroke be a separate node in the graph, or will several strokes be accumulated into one node? Or am I completely misunderstanding things here? What will the graph look like after a stroke with the pencil tool?

This depends on the implementation of drawables, drawables are nodes within the graph that provide an image buffer. The simplest approach is that this node is
backed by an in memory buffer/set of tiles. With such an approach the paint tools would replace this backing image data, by filtering it through stroke operations.

What happens when you save an image into xcf2 (or whatever it will be)? Is there a point where parts of the graph are flattened, or will all manipulations that have ever been done to the image be replayed when the image is loaded again?

Such a procedural "cache" of operations is useful for more things than an infinite undo history, small file size etc. It also means it would be possible to resize an image after interactive operations.

For the GEGL ops themselves it shouldn't matter if they are used in one mode, or the other. Initially the simplest mode, by mangling tiles directly will probably be implemented since the integration would deviate the least from current code base.

(I have looked through the GEGL API docs and the GGGL pages so I think I understand the graph and operation stuff, it's the integration with GIMP I'm interested to hear more about.)

After discussions it has been found more probable that integration should start with the display filters, and color management.

/Øyvind K.