ok, corner cased sounds like a typical working scenario for me ;-)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.
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.
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...
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 ;-)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 usera) 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.
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 ;-)
in this case you could have a small "cache" checkbox for all operators of the layer chain...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.
fine... than we can try to convince some devs ;-)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.
_______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer