Re: 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=123112&id=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 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. This disk cache could be stored into the main files as a parasite (some 3d rendering application's store global illumination photon maps inside of 3D scene files on request but it's good to have a choice if it's stored with the "workspce" file or externaly...



best Regards to all GIMP devs out there - you do a great job!!

Danko Dolch
3D artist & compositor