Re: Composition rendering time instance

Danko Dolch <forum@xxxxxxxxxxxxxxx> · Wed, 08 Jul 2009 19:26:45 +0200

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