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

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

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

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

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

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

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

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