Composition rendering time instance

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Nicolas Robidoux]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Nicolas Robidoux]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Nicolas Robidoux]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Nicolas Robidoux]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Nicolas Robidoux]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Danko Dolch]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Danko Dolch]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Øyvind Kolås]

On Wed, Jul 8, 2009 at 7:26 PM, Tobias Ellinghaus<houz@...> 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Danko Dolch]

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 Kolås wrote:

On Wed, Jul 8, 2009 at 7:26 PM, Tobias Ellinghaushouz@... 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer