Hi, I implemented a new compositor node “Kuwahara filter” that I want to get user feedback on. The node lets you create stylized image from a realistic one.
Demo:
Note: only full-frame compositor is supported for now. Full-frame compositor is an experimental feature. To activate it:
Go to Edit → Preferences → Experimental → Enable “Full Frame Compositor”
Then go to Compositor → Optionsl and set Execution Mode to Full Frame:
Hi ! I think this filter will be familiar to anyone having used an image editor. It’s usually presented as a way to denoise. I haven’t seen “Kernel size” used in Blender anywhere. The compositor’s various blur nodes just call it “size”, but the meaning may be more obvious in the case of blurring than it is here. I think “size” might be enough.
Same goes for “sigma”, not sure the term is very meaningful to the average user, even though they can consult the doc. I would go for something that describes the effect, which you already did in the tooltip description. Perhaps “Smoothing”. edit or “Strength” ?
In any case the build doesn’t work for me. The node is a no-op, and doesn’t update on frame change.
I forgot to mention the node is only implemented for the full-frame compositor. I will add a note on the node and prevent it from crashing when used with viewport compositor.
Makes sense, I will consider renaming the parameters.
I think color of the node is inconsistent, as other filter nodes have dark purple color but this one is yellow like color nodes.
Just curious. Is there a particular reason that the soft minimum value for size is set to 4? I can see that 4 would be a good default value but the soft minimum value could be 1 in my opinion. I imagine 1~3 values have many use cases (subtler stylized look for example) and think putting in behind a soft limit makes it less discoverable.
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).
