New feature inquiry.
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.
| New feature inquiry. | Fredrik Alstromer | 11 Jul 19:46 |
| New feature inquiry. | Simon Budig | 11 Jul 20:44 |
| New feature inquiry. | Øyvind Kolås | 12 Jul 19:39 |
| New feature inquiry. | Christopher W. Curtis | 18 Jul 03:07 |
| New feature inquiry. | Daniel Egger | 18 Jul 17:47 |
| New feature inquiry. | Øyvind Kolås | 22 Jul 12:15 |
New feature inquiry.
Hi all!
I've had this idea going around my head for a while, and I was just going to ask if someone already had this idea (most probably), and if any work has been done or planned regarding this. I haven't been monitoring this list for very long, so this might be an old and already discarded idea. If that's the case, I apologize, and will withdraw to the rock from under which I came.. :)
The idea has been inspired by photoshop's effect layers, and the basic concept would be plugins that registers a new layer type. When sampled, the plugin is more or less simply executed, and the results are cached until any layer below the "programmable layer" has been modified. Layer modes and opacity are applied as if it was a normal layer, along with any layer mask.
Im not really familiar with the gimp source, and have mostly been doing script-fu stuff up until now. Perhaps this could be accomplished using a plugin? Or maybe it needs to be done in the core gimp source.
Does any one have any ideas or suggestions, as to why this might or might not work? Or possibly better solutions?
Thanks for your time.
New feature inquiry.
Fredrik Alstromer (roe@chs.chalmers.se) wrote:
The idea has been inspired by photoshop's effect layers, and the basic concept would be plugins that registers a new layer type. When sampled, the plugin is more or less simply executed, and the results are cached until any layer below the "programmable layer" has been modified. Layer modes and opacity are applied as if it was a normal layer, along with any layer mask.
Ideas similiar to this are floating around for quite a while now. In the meantime there is a pretty clear proposal on how to implement this. You may want to research about GEGL for more information.
I am not familiar with GEGL but I think dynamically adding new effect layers was on the list of stuff that should be possible.
Im not really familiar with the gimp source, and have mostly been doing script-fu stuff up until now. Perhaps this could be accomplished using a plugin? Or maybe it needs to be done in the core gimp source.
It definitely needs a new infrastructure - and there are lots of other reasons to exchange the current infrastructure. GEGL is supposed to solve the other problems as well.
Bye, Simon
New feature inquiry.
On Sun, 11 Jul 2004 13:46:09 -0400, Fredrik Alstromer wrote:
Hi all!
The idea has been inspired by photoshop's effect layers, and the basic concept would be plugins that registers a new layer type. When sampled, the plugin is more or less simply executed, and the results are cached until any layer below the "programmable layer" has been modified. Layer modes and opacity are applied as if it was a normal layer, along with any layer mask.
You actually want even more,. you want to be able to group layers and apply an effect to the group, instead of all layers below. An extensive example with an upside down layer list (should actually be flippable by just using a proxying GtkTreeModel), where the entire image contents is generated using procedural plugins and effects is at:
http://freedesktop.org/~pippin/aluminium/screenshots/bauxite/2004-06-20b.png
At the moment the application where this happens is a testbed, but it seems like design decisions done there about how to apply GEGL to an advanced layer stack seem sane.
In it's current incarnation that implementation is disassembling the current layers into it's more atomic parts,. making the opacity of a layer an effect layer in itself, creating layers consisting of multiple atomic effects, is not a problem in this model and would allow creating a ui that in basic usage is equvialent, (or preferabbly more equvialent) to the current layers and channels dialog.
New feature inquiry.
On 07/12/04 13:39, Øyvind Kolås wrote:
On Sun, 11 Jul 2004 13:46:09 -0400, Fredrik Alstromer wrote:
Hi all!
The idea has been inspired by photoshop's effect layers, and the basic concept would be plugins that registers a new layer type. When sampled, the plugin is more or less simply executed, and the results are cached until any layer below the "programmable layer" has been modified. Layer modes and opacity are applied as if it was a normal layer, along with any layer mask.
You actually want even more,. you want to be able to group layers and apply an effect to the group, instead of all layers below. An extensive example with an upside down layer list (should actually be flippable by just using a proxying GtkTreeModel), where the entire image contents is generated using procedural plugins and effects is at:
http://freedesktop.org/~pippin/aluminium/screenshots/bauxite/2004-06-20b.png
And we want it rendered using glitz!
http://freedesktop.org/Software/glitz
... but seriously, does anyone think it's possible to offload processing to the GPU? Is that part of the GEGL pipe goals? I didn't see anything at the site in the docs ...
Chris
New feature inquiry.
On 18.07.2004, at 03:07, Christopher W. Curtis wrote:
And we want it rendered using glitz!
http://freedesktop.org/Software/glitz
... but seriously, does anyone think it's possible to offload processing to the GPU? Is that part of the GEGL pipe goals? I didn't see anything at the site in the docs ...
This has been discussed some time ago and was tossed because it seemed unfeasible back then, partly due to the hard coded assumptions in the RGBA rendering model.
However with the integration of GEGL and more flexible data types it might be worth to look into that again. I'd certainly enjoy the idea of doing the composition using the GPU and shader programs.
Servus,
Daniel
New feature inquiry.
On Sun, 18 Jul 2004 17:47:05 +0200, Daniel Egger wrote:
... with the integration of GEGL and more flexible data types it might be worth to look into that again. I'd certainly enjoy the idea of doing the composition using the GPU and shader programs.
The problem might be when you have some operations that you can accelerate with the GPU, and some operations that you need to perform using the CPU. As long as you can assume memory transfers in both directions are free there is no problem, apart from this hurdle, there is no reason not do gradually start porting GEGL nodes to use optional,. hardware acceleration,. sacrificing some quality for speed. Each node ported would be a separate change,. a wider change would be to specify the "glitz'ness" as a property of the pixel representation,. and somehow attempt using that special "blessed" pixel representation throughout the pipeline,. this is rather unfeasible IMO
/Øyvind K,
