Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
* Sven Neumann <[EMAIL PROTECTED]> [021202 15:00]:
> > RGBA value_blur(RGBA,radius){
> > .--RGBA--.
> > | split_RGBA |
> > `-R--G--B--A-'
> > | | | |
> > | | | `---.
> > .-R--G--B-. \
> > | rgb2hsv | \
> > `-H--S--V-' \
> > | | \ \
> > | |\ |
> > | | .---V--. |
> > | | |blur(radius)|
> > | | `---V--'/
> > | | | /
> > | |/ /
> > | | / /
> > .-H--S--V-./
> > | hsv2rgb | /
> > `-R--G--B-' /
> > | | | /
> > .-R--G--B--A-.
> > | join_RGBA |
> > `--RGBA--'
> > }
>
> looks very much like the Pupus rendering pipeline that Adam suggested
> for GIMP-2.0. It's basically the framework that we'd like to put on
> top of GEGL.
>
> Salut, Sven
I read a little on Adam's pupus pipeline, I'm think I'll start with a less
advanced approach than the one he suggests, with a basic design that hopefully
works, and can be enhanced.
I will also read a little about GEGL to refamiliarize myself with the concepts
and data structures planned, to make integration of code or design easier
if what I end up with is useful.
skål, /pippin
--
.^.
/V\Øyvind Kolås, Gjøvik University College, Norway
/(_)\ <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
^ ^
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
Hi,
[EMAIL PROTECTED] writes:
> A little while ago I added another little code project to my todo
> queue, it's just a toy project but might end up providing useful
> ideas for the implementation. I've been toying with the idea to
> create a small program that is built entirely of plug-ins and allows
> you to build graphs of dataflow between inputs and outputs of the
> plug-ins (nodes in the graph). And thus enable the coding of a
> function that only blurs the brightness and not the color of an
> image to be "coded" visually like this:
>
> RGBA value_blur(RGBA,radius){
> .--RGBA--.
> | split_RGBA |
> `-R--G--B--A-'
> | | | |
> | | | `---.
> .-R--G--B-. \
> | rgb2hsv | \
> `-H--S--V-' \
> | | \ \
> | |\ |
> | | .---V--. |
> | | |blur(radius)|
> | | `---V--'/
> | | | /
> | |/ /
> | | / /
> .-H--S--V-./
> | hsv2rgb | /
> `-R--G--B-' /
> | | | /
> .-R--G--B--A-.
> | join_RGBA |
> `--RGBA--'
> }
looks very much like the Pupus rendering pipeline that Adam suggested
for GIMP-2.0. It's basically the framework that we'd like to put on
top of GEGL.
Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On Fri 29 November 2002 18:33, Raphaël Quinet wrote: > On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland <[EMAIL PROTECTED]> wrote: > > Btw, has there been a discussion on how layer grouping will > > work? I want to be able to both group layers in just a group > > (aka doesnt change how rendering works at all) then also be > > able to group layers together, and have the output of that act > > as a layer (aka, for calculating the "virtual" layer, only the > > layers inside of it are done, no outside layers interact with > > these except through the final "virtual" layer.) > > There has been some discussion about layer grouping, but I do not > think that any concrete implementation proposals have ever been > agreed upon. So anyone who could come up with a GUI mock-up is > welcome. Code is even more welcome, of course. ;-) Funny. I did just that (a mockup, not code) a little while ago in a different forum. See http://boards.lionhead.com/showthread.php?s=&threadid=32671#post298059 Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
[EMAIL PROTECTED] wrote: I've been toying with the idea to create a small program that is built entirely of plug-ins and allows you to build graphs of dataflow between inputs and outputs of the plug-ins (nodes in the graph). This is exactly what Gimpeon does. It's a Gimp plugin, lets you build a graph (well, actually a line, since I don't have any multi-input nodes yet) of processing nodes, animate parameters over time, display multiple points in the graph, update them as you adjust parameters, and apply the processing graph (line) to a sequence of images. http://www.ozemail.com.au/~hodsond/gimpeon.html It's crashable, but you should be able to get the idea. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On 29-Nov-2002, Raphaël Quinet wrote: > However, here is my point of view (which may be different from what > some other developers think, so do not take this for granted). There > are two kinds of "grouping": > > - Simple linking of layers so that some operations such as toggling > their visibility or moving the whole group of layers can easily be > applied to them (bug #86337, bug #86277). These operations would > not modify the pixels in the layers. This could probably also be > used for implementing the clipping groups (bug #51112). > > - Grouping of layers in such a way that a merged image of the layers > is stored in a virtual layer and some operations can be applied to > this merged layer: color adjustments, transformations or even any > PDB operation, including the ones done by a plug-in. Whenever a > layer in the group is modified, the merged image is rebuilt and the > operation associated with it is applied to in order to re-create the > updated "active layer". This can be used to implement the Photoshop > styles or adjustment layers (bug #79025, bug #98262). In summary, > the "active layer" would have a list of layers, a drawable and one > PDB function (with its current parameters) associated with it. > Whenever something happens to one of the layers in the list, a new > (invisible) drawable is allocated, it gets the merged copy of all > layers, and then the PDB function is applied to it. When the > results are ready, the new drawable replaces the one that was > visible. In some cases, it may be better to keep the two drawables > (merged view + results) and to apply the PDB function only to the > regions that have been modified, but this is only an optimization. > > So as you mentioned yourself, there are two ways to define "groups": > they have different purposes and need to be implemented differently. > That is a _perfect_ explination of what I want. =) -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989 msg03144/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On Fri, 29 Nov 2002 19:10:20 +0100, [EMAIL PROTECTED] wrote: > * Raphaël Quinet <[EMAIL PROTECTED]> [021129 18:38]: > > There has been some discussion about layer grouping, but I do not > > think that any concrete implementation proposals have ever been agreed > > upon. So anyone who could come up with a GUI mock-up is welcome. > > Code is even more welcome, of course. ;-) [...] > A little while ago I added another little code project to my todo queue, it's > just a toy project but might end up providing useful ideas for the implementation. > I've been toying with the idea to create a small program that is built entirely > of plug-ins and allows you to build graphs of dataflow between inputs and outputs > of the plug-ins (nodes in the graph). And thus enable the coding of a function that > only blurs the brightness and not the color of an image to be "coded" visually > like this: [... nice ASCII graph snipped ...] > It'll take a little while until I have the time to start working on it, this is a >much > more general approach, but if I end up with something viable at least the ideas can >be > used to implement most kinds of layer grouping etc. since they will be graphs with > special constraints. Yes, this is a nice idea, although this is different from the feature that we were talking about. As a matter of fact, the idea that you present here has already been discussed on this mailing list. This is similar to what is done in a program called "Khoros" and its interface "Cantata". If you do a search on your favorite search engine and look for "gimp" and "khoros", you may find some interesting links. This idea has been discussed in January 1997, August 1998 and December 2000. You will find a summary of the last proposal by Adam on the following page (section "4. Pupus Pipeline"): http://kt.zork.net/gimp/gd20001231_25.html It is not easy to find the complete archives of this mailing list before 2001 (except in my private archives), but I found the following pages: August 1998 http://groups.yahoo.com/group/gimp-developer/message/4578 (a quote from my January 1997 message): http://groups.yahoo.com/group/gimp-developer/message/4582 December 2000 (Pupus pipeline: what Adam has been doing, etc. etc.): http://www.mail-archive.com/gimp-developer%40scam.xcf.berkeley.edu/thrd3.html As far as I know, nobody has ever managed to implement all these nice features... -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
* Raphaël Quinet <[EMAIL PROTECTED]> [021129 18:38]:
> On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland <[EMAIL PROTECTED]> wrote:
> > Btw, has there been a discussion on how layer grouping will work?
> > I want to be able to both group layers in just a group (aka doesnt change
> > how rendering works at all) then also be able to group layers together, and
> > have the output of that act as a layer (aka, for calculating the "virtual"
> > layer, only the layers inside of it are done, no outside layers interact with
> > these except through the final "virtual" layer.)
>
> There has been some discussion about layer grouping, but I do not
> think that any concrete implementation proposals have ever been agreed
> upon. So anyone who could come up with a GUI mock-up is welcome.
> Code is even more welcome, of course. ;-)
>
> So as you mentioned yourself, there are two ways to define "groups":
> they have different purposes and need to be implemented differently.
A little while ago I added another little code project to my todo queue, it's
just a toy project but might end up providing useful ideas for the implementation.
I've been toying with the idea to create a small program that is built entirely
of plug-ins and allows you to build graphs of dataflow between inputs and outputs
of the plug-ins (nodes in the graph). And thus enable the coding of a function that
only blurs the brightness and not the color of an image to be "coded" visually
like this:
RGBA value_blur(RGBA,radius){
.--RGBA--.
| split_RGBA |
`-R--G--B--A-'
| | | |
| | | `---.
.-R--G--B-. \
| rgb2hsv | \
`-H--S--V-' \
| | \ \
| |\ |
| | .---V--. |
| | |blur(radius)|
| | `---V--'/
| | | /
| |/ /
| | / /
.-H--S--V-./
| hsv2rgb | /
`-R--G--B-' /
| | | /
.-R--G--B--A-.
| join_RGBA |
`--RGBA--'
}
At the moment I'm pondering about reference counting to avoid exhausting memory,
It'll take a little while until I have the time to start working on it, this is a much
more general approach, but if I end up with something viable at least the ideas can be
used to implement most kinds of layer grouping etc. since they will be graphs with
special constraints.
http://phpweb.hig.no/~oey_kola/graph.txt <- some more of my ascii ramblings.
I don't want to try to implemnt this in gimp directly since it's mostly playing
with some design ideas I have, but if the ideas work out nicely,. gimp should be
able to benefit from the fact that the problem has been attacked a little outside
gimp.
--
.^.
/V\Øyvind Kolås, Gjøvik University College, Norway
/(_)\ <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
^ ^
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] layer groups (was: Film Gimp and GIMP)
On Fri, 29 Nov 2002 11:29:12 -0500, Patrick McFarland <[EMAIL PROTECTED]> wrote: > Btw, has there been a discussion on how layer grouping will work? > I want to be able to both group layers in just a group (aka doesnt change > how rendering works at all) then also be able to group layers together, and > have the output of that act as a layer (aka, for calculating the "virtual" > layer, only the layers inside of it are done, no outside layers interact with > these except through the final "virtual" layer.) There has been some discussion about layer grouping, but I do not think that any concrete implementation proposals have ever been agreed upon. So anyone who could come up with a GUI mock-up is welcome. Code is even more welcome, of course. ;-) However, here is my point of view (which may be different from what some other developers think, so do not take this for granted). There are two kinds of "grouping": - Simple linking of layers so that some operations such as toggling their visibility or moving the whole group of layers can easily be applied to them (bug #86337, bug #86277). These operations would not modify the pixels in the layers. This could probably also be used for implementing the clipping groups (bug #51112). - Grouping of layers in such a way that a merged image of the layers is stored in a virtual layer and some operations can be applied to this merged layer: color adjustments, transformations or even any PDB operation, including the ones done by a plug-in. Whenever a layer in the group is modified, the merged image is rebuilt and the operation associated with it is applied to in order to re-create the updated "active layer". This can be used to implement the Photoshop styles or adjustment layers (bug #79025, bug #98262). In summary, the "active layer" would have a list of layers, a drawable and one PDB function (with its current parameters) associated with it. Whenever something happens to one of the layers in the list, a new (invisible) drawable is allocated, it gets the merged copy of all layers, and then the PDB function is applied to it. When the results are ready, the new drawable replaces the one that was visible. In some cases, it may be better to keep the two drawables (merged view + results) and to apply the PDB function only to the regions that have been modified, but this is only an optimization. So as you mentioned yourself, there are two ways to define "groups": they have different purposes and need to be implemented differently. The first and second kind of groups would probably have to be defined differently in the user interface. So again, some GUI mock-ups would be welcome. Note that it is important to become familiar with all features and their distinct purposes before trying to think about how they could be used, otherwise it is easy to miss some important things. Here are some direct links to the relevant bug reports: - "clipping groups or masking groups (like in Photoshop files)" http://bugzilla.gnome.org/show_bug.cgi?id=51112 - "Add support for Photoshop Styles and adjustment layers" http://bugzilla.gnome.org/show_bug.cgi?id=79025 - "use the linking of layers for more useful action than moving only" http://bugzilla.gnome.org/show_bug.cgi?id=86277 - "add support for layer trees or layer groups" http://bugzilla.gnome.org/show_bug.cgi?id=86337 - "Adjustment Layers (like in Photoshop)" http://bugzilla.gnome.org/show_bug.cgi?id=98262 (marked as dup. of #79025, but contains some useful descriptions) -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
