search

chaiNNer-org / chaiNNer

A node-based image processing GUI aimed at making chaining image processing tasks easy and customizable. Born as an AI upscaling application, chaiNNer has grown into an extremely flexible and powerful programmatic image processing application.
https://chaiNNer.app
GNU General Public License v3.0
4.58k stars 283 forks source link

Caching node (memoization) #1466

Open zopieux opened 1 year ago

zopieux commented 1 year ago

Motivation A typical use-case of chaiNNer that I'm sure many people have is to do an expensive operation (e.g. upscale image), then proceed with further cheap processing using that expensive output as input. One needs to iterate a lot of that cheap processing. It would be great if chaiNNer could expose a caching mechanism so the expensive stuff is only done once and doesn't require manually saving/loading from disk. I propose two approaches below.

Description

  1. One option is to introduce a Cache node which is basically a passthrough with state (memory and/or disk). I don't know if the current architecture can detect dirty inputs for any stage – looks like at least the Image preview node has a concept of "outdated" that would apply here. For a v1 the node could not have any smartness and just have a "Clear cache" button. If dirty detection becomes available, I'd suggest just implementing 2. instead.
  2. Another (better IMO) option is to automatically cache all operations (for nodes where it makes sense) behind the scene instead of having to create cache nodes manually.

Alternatives Today I need to rely on a clunky setup where I have a Save image node and a Load image node, depending on whether I need to refresh the output or just read it. This is a huge pain when there are a few such cacheable operations, especially in the absence of i/o selectors (#1465).

joeyballentine commented 1 year ago

We actually were planning on implementing that second option at some point, but a cache node sounds like an even better idea

zopieux commented 1 year ago

Cool! As I mentionned I think the user shouldn't be in the business of manually adding such node, because ideally the default should be for the app to be smart and detect changes. Of course this is likely more difficult to imlement correctly compared to a simple caching node.

joeyballentine commented 1 year ago

Yeah i think the issue there is how we define what needs to be cached. We obviously don't want to cache everything, so we'd need to specify what things would be worth caching (upscaling nodes being one of those). I do think we should still have a cache node though, since there may be times where a user is working with incredibly large images on a low end machine, and even simple nodes take a while to process, and they'd benefit from adding a bit of caching around. @RunDevelopment probably has a better idea of what would be the best approach than me though