Hi Alexandre,

On Jan 25, 2008 9:52 PM, Alexandre Prokoudine
> On Jan 25, 2008 11:01 AM, Sven Neumann wrote:
> > Actually, I don't think that we need to put action recording on our list
> > as that will become obsolete with non-destructive editing.
> This is apples and oranges, Sven :-) Non-destructive editing boosts
> productivity as well, but has nothing (or very few things) in common
> with *automation*.

It does, though. If you make a chunk of graph --
say you want to gaussian-blur a layer, gradient-map some part of it,
and posterize the result to 32 levels; you could do this with the
following snippet of graph:

 (graph root)
 posterize (levels = 32)
 +- atop
 | |
 | mask
 | |
 | gradient-map (gradient = <how would you specify this?>)
 | |
+-gauss-blur (hblur = 5, vblur = 5)

In case that isn't clear:

Source layer is gauss blurred, A gradient-mapped version is made,
which is then masked.
This image is then rendered atop the gaussian-blurred image, and the
result is posterized.

This is what is conventionally covered by macros, this kind of thing.

> All the users who ever bugged you asking for macros
> recording did it because they don't feel like programmers to learn
> Script/Python/Perl-Fu.

With non-destructive editing, used as above, almost all the things
that users want to do are things that can be expressed in terms of a
modification of the image graph. The example you see above -- the only
user input required would be to choose which layer becomes
sourcelayer. twould probably be pretty easy to build a 'quick change'
dialog where the user can change all the involved values (eg gauss
blur radius.)

The things which do not fall into that category..
* batch processing (trivial amount of programming. Just keep resetting
   the filenames at the leaf and root of a graph).
* view handling (I'd like to be able to, say, tag an image or
directory as 'pixel art', and when I opened one of those images, have
an additional, 300% view appear (for real size preview). Personally I
think views are one of the things that may end up needing a PDB
interface*, despite the vast obsoletion that should otherwise happen
(gauss blur, gradient map, colorize, what ever filter you name --
won't need a PDB interface any more, they just implement their gegl

I've just gone through the menus.. and the vast majority of actions
available are directly equivalent to inserting, deleting, or shuffling
nodes in a graph. The remainder alter either the context (Tools menu,
View menu) or the GUI (Dialogs menu, View menu).
(We might want to consider implementing a 'meta-load' Op, that would
load a graph from file and pass image data through it. That would be a
pretty simple and flexible way of facilitating macros shared between
images -- just connect the output at a place of the user's choosing.)

What significant sequence of actions that you can take is there, that
cannot be done by simple graph editing?
Gimp-developer mailing list

Reply via email to