Re: [Gimp-developer] Composition rendering time instance
hi, Nicolas Robidoux schrieb: At start-up, the user could be presented with a list of unfinalized workspaces, and asked whether to finalize each, or open each. just for clarification: by workspaces you're referring to nip2 workspaces, which roughly translate to GIMP compositions, correct? greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
hi, Martin Nordholts schrieb: On 07/07/2009 01:35 PM, yahvuu wrote: I see two poles for the rendering strategy, both of which have downsides: - eager rendering: render as soon as possible, latest when saving the composition Hi yahvuu I don't see why the whole composition would have to be rendered just because it is saved. Or did you mean latest when exporting the composition? no, by eager rendering i indeed mean that the saved file contains a rendered bitmap of full image resolution. And yes, when rendering takes just a few seconds, this stragegy wastes disk space. I wonder if we really need to let the user manage this Consider a huge panorama image with some operations like denoise and unsharp mask applied, that takes, say 2 hours, to render. If we go with lazy rendering, the following might happen: The user sends a JPEG to a colleague for review -- takes 2 hours to render. The image is OK, the user creates a TIFF for the print shop -- takes 2 hours again. I think in this case, the user would be better off if he had some control about when the rendering happens. I'm not shure: just a corner case or something GIMP should care about? wouldn't it work pretty well to lazily render an area around the currently showed part of the image (so that performance when scrolling in the vicinity is good), but limit it in size (so that memory usage is limited). IIUC, you're targeting quick re-opening of a composition here. Me too, thinks that some persistent caching can be useful. Regarding image browsing, a thumbnail plus a preview of the whole image at screen resolution might be useful, too. However, that's different from controlling the rendering of the full resolution. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Peter: just for clarification: by workspaces you're referring to nip2 workspaces, which roughly translate to GIMP compositions, correct? Yes. (More or less, a (possibly unfinalized) tree.) (I suppose composition sounds a little more artistic ;-) Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Am Mittwoch, 8. Juli 2009 schrub yahvuu: [...] The user sends a JPEG to a colleague for review -- takes 2 hours to render. The image is OK, the user creates a TIFF for the print shop -- takes 2 hours again. I think in this case, the user would be better off if he had some control about when the rendering happens. What about caching the rendered image? As long as nothing is changed it can be reused. And when anything is altered in the image it has to be rerendered anyway. At least if it's not possible to cache intermediate results of the rendering or just rerender the changed parts. [...] Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GSoC] Midterm surveys have begun
Attention students and mentors, the midterm surveys for Google Summer of Code 2009 have begun. Mentors: the results will decide about the fate of student's projects. Please log in to http://socghop.appspot.com/ and follow the survey links in the navigation bar on the left. The deadline for the survey is July 13 at 19:00 UTC. If you have any questions or comments, please post to the gimp-developer or gegl-developer lists. If you feel that your inquiry should not be handled in public, feel free to mail me directly. Regards, Michael -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] to render or not to render - Composition rendering time instance
Oh interesting topic! To decide for a good "composition rendering strategy" I would suggest to take a look at some verry similar applications like motion compositig software. This type of software is used to do non destructive image editing to motion picture sequences in a way like GEGL does. It's used to create visual effects for blockbuster movies, compose 3D animation sequences or key out green or blue screen footage for example. These programms exist for a long time - they all have to deal with this rendering question and there is operational experience since many years. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- something about terminology: some posters are unsure if "to render" would be the right terminus to describe what's going on with a composition when the GEGL tree is computed for an final output image. With GEGL gimp changes the way it's working with images in a fundamental way. So it's not unlikely that this fundmental change will result in some new words to describe the new things going on. Is the thing that GEGL does something completeley new to the world of image processing? No - we already know this way of processing images for example from 3D rendering compositing software for years. For 3D animators and compositors it's a common concept "to render" a 3D image or a composition to get all the calculations done in final resolution and precision after they had a look at a OpenGL shaded 3D preview or the low res. composition proxy image. IMHO "to render" is exactly the word describing whats going on here. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Let's take a look at some more known examples: Adobe After Effects/ Autodesk Combustion They save only "workspace files", if you want to "export" the final mage you have to "render" it to disk. So if you want do get the final result you have to rerender the image all the time you open the "workspace" file. good: You don't waste disk space. bad: You have to rerender all the time - but that's not a problem in 90% of daily work because moden multi core CPU's can calculate the output image typicaly in seconds... -- But what's if you have a huge mega composition with really computaion intensive processing nodes? In this case Autodesk combustion has some handy thing called "proxy node" you can place this image processing node everywhere in your visual node composition to "precalculate" the complete composition graph at the position the node is snapped in. The result is written to a single layer image file on harddisk. This brings back realtime even to the most complex compositions you can think of - als long as you don't change node settings before the proxy node - in this case the proxy will become invalid and you have to recalculate it. The great thing is - you can place a simple color correction node after the proxy node to made small adjustments without long rendertimes to complex compositions. -- You only need a "precalculated rendering" of your "workspace" (or part of your workspace graph) if you have really really highend sophisticated stuff - in this case it's not a problem to save it in a discreete "disk cache file" -- As you can think a visual node editor is verry handy for this type of complex composition work ;-) Ok this was something about how it works since many years for the compositing dudes. But it may be interesting to take a look at some of the newer software designs. And there I would recommend to take a closer look to Autodesk Toxik - a brand new highend compositing system build with instant user feedback for floating point HDR composites in mind. Toxic is strictly tile based and distributes the rendering of the composition to all available CPU cores. To further increase speed a large disc cache computes all the nodes of a composition and stores it automatically to it's disc cache to create a display preview or render a composition. To use this feature you have to activate the disc cache in your "workspace" settings to avoid unnecessary disk IO overhead for smaller projects that can be "rendered" in realtime. -- Another great thing with Toxik as also with combustion is a small "Feedback" checkbox in the UI that ensures that the compositing graph isn't computed with a given resolution and a given quality but in a given timeframe of some ms - to get a unblocked response to user changes - Great Thing by the way!! some useful Links: corporate website http://usa.autodesk.com/adsk/servlet/index?siteID=123112id=5561949 user guide: http://images.autodesk.com/adsk/files/autodesk_toxik_2009_user_guide0.pdf SUMMARY 1. Workspace files (with embedded?) source files for the GEGL graph are small and lightwight an can be computed on demand in output resolution. 2. To output an image from an GEGL graph would be called "render" by some media industry folks. 3. If You create highend sophisticated GEGL graphs that take long long to render
Re: [Gimp-developer] Composition rendering time instance
hi, Tobias Ellinghaus schrieb: Am Mittwoch, 8. Juli 2009 schrub yahvuu: [...] The user sends a JPEG to a colleague for review -- takes 2 hours to render. The image is OK, the user creates a TIFF for the print shop -- takes 2 hours again. I think in this case, the user would be better off if he had some control about when the rendering happens. What about caching the rendered image? As long as nothing is changed it can be reused. And when anything is altered in the image it has to be rerendered anyway. At least if it's not possible to cache intermediate results of the rendering or just rerender the changed parts. that gives a very nice solution! Some disk cache is needed by GEGL anyway, and if that cache is persistent across sessions, unnecessary recalculations can be mostly avoided. Personally, i wouldn't mind to assign some GBs to GIMP in order to make my life easier. Those who do mind, could set the 'persistent cache' size to zero in order to make shure GIMP cleans up when closing the session. In case someone really needs to save the rendered bitmap together with the composition, there's still the possibility to put that option into the finalize command. Or something like that. regards, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Hi Peter! yahvuu wrote: hi, Tobias Ellinghaus schrieb: Am Mittwoch, 8. Juli 2009 schrub yahvuu: [...] The user sends a JPEG to a colleague for review -- takes 2 hours to render. The image is OK, the user creates a TIFF for the print shop -- takes 2 hours again. I think in this case, the user would be better off if he had some control about when the rendering happens. What about caching the rendered image? As long as nothing is changed it can be reused. And when anything is altered in the image it has to be rerendered anyway. At least if it's not possible to cache intermediate results of the rendering or just rerender the changed parts. that gives a very nice solution! Some disk cache is needed by GEGL anyway, and if that cache is persistent across sessions, unnecessary recalculations can be mostly avoided. What about taking the cache with you? e.g. switch to another workstation - would be cool to have an option to store the cache external too... Personally, i wouldn't mind to assign some GBs to GIMP in order to make my life easier. Those who do mind, could set the 'persistent cache' size to zero in order to make shure GIMP cleans up when closing the session. That would be fine - question is: a) save only the final image b) save all the results of the GEGL graph nodes during a session so that not all nodes have to be calculated if only the last one is changed... c) create a dedicated "cache" or "proxy" node that can be assigned by the user In case someone really needs to save the rendered bitmap together with the composition, there's still the possibility to put that option into the finalize command. Or something like that. Use case? A) I have a comp. that takes 2h to render and I want to take the cache with me because I want do do some final color adjustments with my client. If I reopen the comp and change the color node settings the rendered bitmap beomes invalid and I need another 2h to recalculate all again... In this case I just hat to export a PNG or something like and start a new comp. to do the final color tweaks. But that would be bad for the workflow because now I have 2 comp. to work with... B) I've set a "GEGL "cache node" ontop of the GEGL nodes that took 2h to render and stored the "cache node" data into my Gimp comp. file. In my clients office I load the comp. into Gimp and add another GEGL color correction node ontop of the "cache node" - now I do some quick "realtime" adjustments to get the approval for the image from my client. 2h of rendering saved... A simple prerendered cache won't save the day i think... regards Danko Dolch 3D artist compositor ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] to render or not to render - Composition rendering time instance
hi, Danko Dolch schrieb: Oh interesting topic! To decide for a good composition rendering strategy I would suggest to take a look at some verry similar applications like motion compositig software. very interesting input, indeed! IMHO to render is exactly the word describing whats going on here. true enough. For GIMP, though, graph-based compositing is only a back-end technology. The details should not show up in the UI unless absolutely necessary. (This doesn't rule out that a plugin could offer full tree editing and a corresponding render command...) Toxic is strictly tile based and distributes the rendering of the composition to all available CPU cores. To further increase speed a large disc cache computes all the nodes of a composition and stores it automatically to it's disc cache to create a display preview or render a composition. this is quite exactly what i understand what GEGL does (i'm not a devel) ... unless you're picky about every node being cached ;) -- Another great thing with Toxik as also with combustion is a small Feedback checkbox in the UI that ensures that the compositing graph isn't computed with a given resolution and a given quality but in a given timeframe of some ms - to get a unblocked response to user changes - Great Thing by the way!! that's also a very interesting approach for dealing with slow filters: render a small area of the screen in full resolution and fill the rest of the screen with an interpolated low-resolution result. I will post that to the brainstorm so it doesn't get forgotten. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
hi, Danko Dolch schrieb: What about taking the cache with you? e.g. switch to another workstation - would be cool to have an option to store the cache external too... cool, yes. But even more corner cased than the case of very expensive compositions already is for GIMP. yahvuu wrote: Personally, i wouldn't mind to assign some GBs to GIMP in order to make my life easier. Those who do mind, could set the 'persistent cache' size to zero in order to make shure GIMP cleans up when closing the session. That would be fine - question is: a) save only the final image b) save all the results of the GEGL graph nodes during a session so that not all nodes have to be calculated if only the last one is changed... c) create a dedicated cache or proxy node that can be assigned by the user a) only the tree gets saved. The final image aka full resolution bitmap gets only created when exporting (e.g. to JPEG). This bitmap is then available from the disk cache in case subsequent actions need it. In the example, that was exporting again to a different file format. b) yep, that's what the disk cache should do (for expensive calculations) and ideally this data should persist across editing sessions. c) This is a very interesting idea. Allow me to translate for GIMP, a better name would probably be something like a render full resolution operation. - render, because GEGL cares for all necessary caching automatically during editing (please correct me if i'm wrong). So for GIMP, the real purpose is to save some intermediate results together with the composition, that is to render them. (During editing the full resoluton will almost never get rendered when the screen is smaller than the image size) - operation, because GIMP will not expose the GEGL tree on the UI, but instead will have linear operation chains. So indeed, that's a cool way to give the user fine-grained control about how much (redundant) rendered data should be saved with the composition. That's clearly an expert feature, so it won't hurt much if it has to be controlled by some 'scary' operation. ... i'm convinced now. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] The Export spec should be augmented to handle an important usecase
The spec is here: http://gui.gimp.org/index.php/Save_%2B_export_specification#exporting_files Quick version: The default export path needs a settings switch for whether the original file path (number 3) is higher-priority than the most-recently-used paths (numbers 1 and 2). This would support the use-case where input and output files are associated by directory, but you may open multiple input files at once. Detailed version: My photo-storage hierarchy looks like .../photos/(date)/(filenames). Whenever I modify an image, I save it to .../photos/(date)/pp/(original filename) — pp means post-processed Now, I open two images in gimp from different dates using my image viewer. I edit them, and then try to save them. The first one works fine. When I go to save the second file, however, I end up (by default) in a directory associated with the first file. Furthermore, because I was in the image viewer (and not the command line), I often have _no idea_ what the directory is that I now need to manually navigate to. In the case where I open a couple (=3) images in a row from different directories, this means that I have to re-find the images in the image viewer, mentally remember the directory names, then manually navigate to the appropriate directories in the export dialog. Suffice it to say, this is more of a roadblock than a workflow. On the other hand, there are other situations where I want all the photos to end up in one place. For instance, when I post-process photos for a blog post, they will all end up in .../photos/pblog/(year-month)/(post title)/ . Thus, it seems like both ways of handling this default ([1, 2, 3] priority as well as [3, 1, 2] priority) are viable and useful. This is why I suggest having a setting to switch between the behaviors. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] to render or not to render - Composition rendering time instance
On 07/08/2009 03:45 PM, Danko Dolch wrote: 3. If You create highend sophisticated GEGL graphs that take long long to render even on you brand new Intel Beckton 16 core workstation ;-) it would be handy to insert precalculated proxy nodes into the GEGL node graph to speed things up by caching the whole or a part of the graph. Alternatively an automatic caching of the inbetween calculations of all compositing nodes would be more comfortable but harder to implement into the first version and it would require much more disk space than a single proxy node. Even better, the proxy node should be managed automatically by GIMP. If you, say, move a layer, the proxy node would be inserted right below the composition below the moved layer. By clever managing of the proxy node we get the best of both worlds, good interactive performance without the need for manual work by the user. Interesting mail btw / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Hi Peter! yahvuu wrote: hi, Danko Dolch schrieb: What about taking the cache with you? e.g. switch to another workstation - would be cool to have an option to store the cache external too... cool, yes. But even more "corner cased" than the case of very expensive compositions already is for GIMP. ok, corner cased sounds like a typical working scenario for me ;-) I've a screenshot for you - showing a layer tree and a node based view side by side. The node view is more pleasing to read if you try to understand whats going on. http://www.dolchonline.net/prj/gimp/combustion_scr01.jpg in short: I load a image of a bird - apply a blue screen key - correct the colors - and send it to the first layer. Second I load a background image - blur it - draw a mask on it - and send it too to layer. Third I load a image and place it on a layer behind the masked hole in the background of the second layer. then I composite the 3 layers - sharpen the result - and scale it with a layer to 720p highdefinition video res. - I send it to he final composite. To save me render time I added an "proxy operator" that caches the whole compositing and virtually switches the image input to the disk cache. That proxy gets color corrected in realtime without any hassle and saved to different output settings at once - cool feature to created all needed res. and file formats without needing a custom script to doing that ;-) Also I saved the keyed bird with the "key-out" render output without manually repeating this every time I adjust the key parameters. A node view is your friend and sould not be hidden from the user - just entry level users have a better understnding from a "physical pipeline based view" than a complex layer tree... But Rome wasn't build in a day either - I know - first things first ;-) Not to mention the wonderful way of correcting colors with the color warper system and high quality histogram + vector scope something I miss in still image editors... yahvuu wrote: Personally, i wouldn't mind to assign some GBs to GIMP in order to make my life easier. Those who do mind, could set the 'persistent cache' size to zero in order to make shure GIMP cleans up when closing the session. That would be fine - question is: a) save only the final image b) save all the results of the GEGL graph nodes during a session so that not all nodes have to be calculated if only the last one is changed... c) create a dedicated "cache" or "proxy" node that can be assigned by the user a) only the tree gets saved. The final image aka full resolution bitmap gets only created when exporting (e.g. to JPEG). This bitmap is then available from the disk cache in case subsequent actions need it. In the example, that was exporting again to a different file format. b) yep, that's what the disk cache should do (for expensive calculations) and ideally this data should persist across editing sessions. this would be the best solution - but memory requirements have to be considered carefully - think about someone editing a simple satelite image (eg. blue marble second generation) 86400x43200px - it takes about 14GB per 32bit RGBA layer - if you store 10 operator states you will have a lot of GB for only one still image ;-) hmm... 1. small projects don't need caching becuse they can be rendered in realtime 2. larger projects need a powerful caching on operator/node base to speedup things 3. extra large projects need some cache management to prevent one composition to kill all the cache of the other projects only by opening once ;-) c) This is a very interesting idea. Allow me to translate for GIMP, a better name would probably be something like a "render full resolution" operation. - "render", because GEGL cares for all necessary caching automatically during editing (please correct me if i'm wrong). So for GIMP, the real purpose is to save some intermediate results together with the composition, that is to render them. (During editing the full resoluton will almost never get rendered when the screen is smaller than the image size) - "operation", because GIMP will not expose the GEGL tree on the UI, but instead will have linear operation chains. in this case you could have a small "cache" checkbox for all operators of the layer chain... So indeed, that's a cool way to give the user fine-grained control about how much (redundant) rendered data should be saved with the composition. That's clearly an expert feature, so it won't hurt much if it has to be controlled by some 'scary' operation. ... i'm convinced now. fine... than we can try to convince some devs ;-) greetings, peter greetings, Danko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Am Mittwoch, 8. Juli 2009 schrub Danko Dolch: [...] I've a screenshot for you - showing a layer tree and a node based view side by side. The node view is more pleasing to read if you try to understand whats going on. http://www.dolchonline.net/prj/gimp/combustion_scr01.jpg I personally love the node editor of blender and would like to see something like that in GIMP. The only problem with these node setups (like the one in your screen shot) is that they are only graphs but no trees. And AFAIK GEGL uses trees of nodes. Thus the cool things like several sources or forward edges (think of a bumpmap on a layer which uses the same layer as source) are not possible. [...] Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Export spec should be augmented to handle an important usecase
Am Mittwoch, 8. Juli 2009 schrub Omari Stephens: [...] Thus, it seems like both ways of handling this default ([1, 2, 3] priority as well as [3, 1, 2] priority) are viable and useful. This is why I suggest having a setting to switch between the behaviors. What about providing some kind of pre-populated drop down box in the export dialog with both alternatives, so you can quickly select one of those or just use the dialog the way it currently works. The box could be filled like this: last used directory associated directory last (say) 5 directories other than the two above If you select either one of the first two entries, that one becomes the default in subsequent exports. So if GIMP ships with last used directory and you export to associated directory, the next time you open the dialog it will default to associated directory. To make the whole thing unobtrusive it could be reduced to a little triangle next to the path at the top of the dialog which gives the list when clicked. Well, I guess that's the way drop down boxes work. :-) I hope this makes some kind of sense. Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
hi, Tobias Ellinghaus schrieb: [..] Thus the cool things like several sources or forward edges (think of a bumpmap on a layer which uses the same layer as source) are not possible. GEGL has a 'clone' operation that should enable what you're seeking. Have a look at the example with the same name from http://gegl.org/gallery/index.html greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
On 07/08/2009 08:26 PM, Tobias Ellinghaus wrote: And AFAIK GEGL uses trees of nodes. This is wrong, GEGLs image processing structure is a directed acyclic graph, one output node can be connected to several input nodes. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
On 07/08/2009 08:45 PM, Martin Nordholts wrote: On 07/08/2009 08:26 PM, Tobias Ellinghaus wrote: And AFAIK GEGL uses trees of nodes. This is wrong, GEGLs image processing structure is a directed acyclic graph, one output node can be connected to several input nodes. / Martin Make that the output pad of a node can be connected to input pads of any number of other nodes. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
On Wed, Jul 8, 2009 at 7:26 PM, Tobias Ellinghaush...@gmx.de wrote: Am Mittwoch, 8. Juli 2009 schrub Danko Dolch: I personally love the node editor of blender and would like to see something like that in GIMP. The only problem with these node setups (like the one in your screen shot) is that they are only graphs but no trees. And AFAIK GEGL uses trees of nodes. Thus the cool things like several sources or forward edges (think of a bumpmap on a layer which uses the same layer as source) are not possible. GEGLs XML serialization format is a tree, the data structure exposed in the API is a fully general directed acyclic graph. As long as you restrict the set of node types involved to: sources, sinks, filters and composers with two input pads and one output pad, any graph can be expressed as a tree with clones. In earlier incarnations (not in GEGL) of the same tree serialization I also allowed embedding free-form graphs as one of the nodes in the tree, thus more complex ops with multiple inputs and outputs could be inserted there. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Am Mittwoch, 8. Juli 2009 schrieb Martin Nordholts: On 07/08/2009 08:45 PM, Martin Nordholts wrote: On 07/08/2009 08:26 PM, Tobias Ellinghaus wrote: And AFAIK GEGL uses trees of nodes. This is wrong, GEGLs image processing structure is a directed acyclic graph, one output node can be connected to several input nodes. / Martin Make that the output pad of a node can be connected to input pads of any number of other nodes. / Martin Thank you for the clarification. I have to admit that I never programmed with GEGL and only knew what I read. Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
