Make it clear viewport compositor is not supported
Built packages for windows, macos and linux
Made color part of filters, so its color is now purple
Since the kernel size is an absolute value in pixels, its effect is highly dependent on the size of the input image. For 1k-4k images the value 1 almost has no effect. That’s why I chose 4.
Another reason is the anisotropic variation will only be free of visible artefacts for values >= 4 (ideally should be >=8 actually). I also adjusted the default for smoothing accordingly, where the effect starts to get noticeable starting from the value 2.
I don’t think strength reflects the effect well. Kernel size (now called “size”) is the value actually affecting strength. Sigma (now called “smoothing”) only influences edges but not how “stylized” the image looks. So I went with the user-centric name “smoothing” : )
The image sequence is PNG 1920*1080, and I’m not sure if there is a way to log the execution time, but it updates on frame change in about 0.6 or 0.7s on this machine (gtx970).
Anisotropic variation is now 4x faster. However, results are less accurate, and this is what this post is about.
The patch #108796 speeds up the anisotropic variation significantly, but results are less accurate. We would like to ask for artist feedback regarding the significance of the difference.
Following images show how the new patch affects results (left: original, middle: fast and inaccurate, right: slow and accurate):
Hello! First of all, let me congratulate you on getting this into main, thanks for your awesome work and for adding this long awaited node !
Here’s my two cents on the speed vs accuracy, coming from a studio perspective that specializes in stylization in Blender:
It’s true that the “accurate” version can run prohibitively long sometimes, in a sense where it almost hinders the artistic process of iterating over the settings to adjust the node tree (it’s also a limitation of the compositor which has no caching, meaning any variation in a node tree containing the Kuwahara filter basically grinds to a halt at every variable change.) That being said, the results are very promising and great in most cases, and stable enough for animation.
The fast version enables faster tweaking which is great for the compositors, but as @sunkper demonstrated, the artifacts generated (and flicker heightened during animation) in some cases unfortunately simply render the shots unnacceptable from a quality standpoint, making the filter unusable in some demanding production settings.
Ideally, I would say the best option is to have a “preview” toggle such as with the defocus node, which switches between the fast and accurate algorithms:
However, I understand that this might not be the most optimal option for you as you’d have to maintain and update both implementations.
If I really had to pick one, I would choose the accurate version, even if it means much slower performance (and keep my fingers crossed for performance updates, and more importantly, the GPU implementation, as it could resolve all performance issues!)
