Re: [Gimp-developer] Composition rendering time instance
that seems really powerful to me, and I hope to see some form of visual node representation beside the classic layer view some day... (yes the one in Blender is great ;-) Today a motion compositor is sometimes the better tool to do a complex non destructive still composit because of things like the node editor or external referenced image sources. Adobe After Effects for example is hardly criticized for its lack in true node editing. -- A question about the planned new Gimp layer chain: Will we have a chain of layers with different operators applied to them and the option of linking child layers to parent layers and building groups for esay tranformation? -- The input of such a layer is stored in native resolution and processed by the layers trasnformation settings to match the composition? Can the input be externaly referenced? Will there be a resampling option to be able to reduce file size if I loaded a 24MP image but only want do design a web banner and don't want to save all the 24MP input dat with my composition? greetings Danko yvind Kols wrote: 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. ___ 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: 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 ;-) well, we'll talk about that later... when GIMP 3.x users already have finished their compositions by the time you're still fiddling with your beloved node view :- [..] 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 ;-) actually, it's not that bad -- only what's on the screen has to be rendered and cached. So unless you take the time to pan through the whole image at 100% view, the cache size should stay within reasonable limits. 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
2009/7/8 yahvuu yah...@gmail.com: 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? For reference, here's how nip2 handles this: - the workspace (tree of operators) is saved to the temp directory every time you make a change (it keeps the most recent 10 I think) for undo and crash recovery - workspaces do not include thumbnails, it's almost always faster to recalculate them - import files (eg. when you load a PNG or SVG) are kept on disc in the temp directory and then mmaped for processing - image display windows have a small ram cache of recently-calculated tiles to speed scrolling and expose operations - there's a cache operator you can add to the graph explicitly if you wish, but no one uses it (it slows down calculation and increases memory use to some degree, and you are not guaranteed to win that invested time back again unless you start heavily editing certain parts of the composition, which you often don't) - if you use the paintbox (a very simple destructive image editor) on a node, it renders that node to a file in the temp directory at full resolution and you edit that image on disc via. a read-write mmap - paintbox undo/redo buffers are kept in ram - if you invalidate a node that's being painted, the associated disc file is deleted and rerendered - when you save an image, the fuil composition is rendered and not cached (they can be extremely large and there is again no guarantee that spending that disc space will produce a benefit) - if you save in a non-compressed format, you can always reload and save as JPG if you wish We have experimented with various caching or persistence schemes over the last 15 years or however long it is, but none of them have ever really stuck. Small, fast workspace files and not filling disc unexpectedly with large, speculative caches seem to be useful principles. On the other hand of course nip2 has few users due to it's hostile nature, heh. Anyway, it is one set of choices. John ___ 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, 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
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] 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
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] 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
[Gimp-developer] Composition rendering time instance
hi all, with GEGL's ability to only render what is visible on the screen (and ideally in that very resolution) we are comfortably spoilt for choice by when to render a composition to full resolution. While saving the user's work -- which amounts to the GEGL tree -- can be done quite quickly (assuming a size from a few KB to a few 100KBs for excessive painting), rendering to full resolution may take minutes to hours and allocate 100s MBs of disk space for huge/complex compositions. 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 - lazy rendering: render only when the full resolution is actually required, that is on export time Eager rendering gets in the way when the user terminates the GIMP session just to continue work the next morning. This breaks Save as in Save-my-Work. Lazy rendering may surprise users when it takes hours to print a composition or to export a JPG to send it to a collegue. Moreover, multiple exports duplicate the rendering effort. I'm not really shure if these are just corner cases. However, following the project vision's 'high-end' 'cutting-edge' adjectives i assume GIMP striving to be a reasonable choice for the 'big' jobs. Then the user needs to be able to control when the composition gets rendered. The first-guess solution to add a checkbox to the save dialog, like ' [X] render to full resolution ' forces the user to think about rendering in advance and is likely to be confusing as the state of that checkbox has to be remembered. Consider a quick CTRL-S in fear of a system crash or save-a-copy to preserve older versions. The best solution i've found so far is to first save the GEGL tree to make shure the user's work is safe. After that, rendering will start, and the image window gets overlayed by a lightbox displaying the rendering progress and a button 'schedule rendering for later'. Some kind of dashboard for controlling scheduled jobs will problably be required for batch processing anyway. CTRL-S could potentially only save the composition without rendering to full resolution. ... still not that nice... any thoughts? regards, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Composition rendering time instance
Peter: The best solution i've found so far is to first save the GEGL tree to make shure the user's work is safe. After that, rendering will start, and the image window gets overlayed by a lightbox displaying the rendering progress and a button 'schedule rendering for later'. I don't think that using the word rendering in a menu will be self-explanatory for non-sophisticated users when used in a save context. I am not sure that I have a better suggestion. Save workspace vs Save image? Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Composition rendering time instance
Nicolas Robidoux writes: I am not sure that I have a better suggestion. Save workspace vs Save image? ... but it makes lots of sense that the tree be saved just before rendering unless this is overridden by the user. Nicolas ___ 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, Nicolas Robidoux schrieb: I don't think that using the word rendering in a menu will be self-explanatory for non-sophisticated users when used in a save context. oh yes, indeed. 'Creating full resolution...' is probably less suspicious but won't solve the problem. The ugly part is that the save/render distinction shows up untimely. I am not sure that I have a better suggestion. Save workspace vs Save image? That is an interesting alternative. Save workspace is expected to be a lightweight command and addresses the problem of quickly interrupting a GIMP session. However, the save-work vs. render-image problem will show up after the command has been applied: shall all images be marked as clean although they haven't been 'fully' saved? Another alternative is to go with lazy rendering and introduce a 'finalize image' command that optionally renders to full resolution. This way, the save/render distinction won't show up until it is really desired by the user. The additional command may be required anyway as a means to reduce file size by dropping some non-destructiveness. See last image in http://gimp-brainstorm.blogspot.com/2009/04/version-control.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
yahvuu writes: Another alternative is to go with lazy rendering and introduce a 'finalize image' command that optionally renders to full resolution. This way, the save/render distinction won't show up until it is really desired by the user. I like finalize image. The additional command may be required anyway as a means to reduce file size by dropping some non-destructiveness. See last image in http://gimp-brainstorm.blogspot.com/2009/04/version-control.html The way nip2/vips deals with a somewhat related issue is that when nip2 is started up, if a lot of disk space is taken up by workspaces, it asks you whether you would like to delete them. A less drastic gui would ask you whether you would like to go through workspaces and mark them for deletion, and then you could pick and choose (and only look through some of them, even) based on thumbnails, size, date of last mod. and whether the result was finalized. Nicolas Robidoux University 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
Nicolas Robidoux writes: The additional command may be required anyway as a means to reduce file size by dropping some non-destructiveness. See last image in http://gimp-brainstorm.blogspot.com/2009/04/version-control.html The way nip2/vips deals with a somewhat related issue is that when nip2 is started up, if a lot of disk space is taken up by workspaces, it asks you whether you would like to delete them. A less drastic gui would ask you whether you would like to go through workspaces and mark them for deletion, and then you could pick and choose (and only look through some of them, even) based on thumbnails, size, date of last mod. and whether the result was finalized. To push the at start-up idea further: At start-up, the user could be presented with a list of unfinalized workspaces, and asked whether to finalize each, or open each. This way, the possibly time consuming rendering would be started at the beginning of a session, not at the end, unless the user explicitly asks to finalize one of the current workspaces. Alternatively, this could be done automatically at start up, in the background. (Just brainstorming here.) 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
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? - lazy rendering: render only when the full resolution is actually required, that is on export time I'm not really shure if these are just corner cases. However, following the project vision's 'high-end' 'cutting-edge' adjectives i assume GIMP striving to be a reasonable choice for the 'big' jobs. Then the user needs to be able to control when the composition gets rendered. any thoughts? I wonder if we really need to let the user manage this, 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). / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
