TSL Separable blurs and map-driven blurs

[Glypse]

Description

The current blur implementations of gaussian and box blur are inconsistent (API-wise) and could make with optimisations (separable implementation). I also think a Node<float> driven blur, like hashBlur does, would be very welcome (it surely is welcome in my use case).

Solution

As mentioned in Additional context, I'd be okay to implement those changes and utilities, but have design questions.

Alternatives

Each user would have to implement their own version of these utilities if they needed them, since they wouldn't be included in three/tsl.

Additional context

I'm working on a library, so far called three-tsl-lab, whichs goal is to facilitate the usage of three/tsl for graphic-design/2D purposes. I've already implemented a Typescript version of separable boxBlur and gaussianBlur and map-driven ("luma") box and gaussian blur as well. Porting it over wouldn't be hard, but the three/tsl codebase isn't designed the same way (see uniformBlur.ts and lumaBlur.ts). Feedback on how to approach this is welcome.

In which case, how do you recommend to structure the API? Each blur with a single export, with a boolean option to be separable? Or a separable blur and a one-pass blur as two different blur exports? Maybe even no difference between a map-driven blur and a uniform blur, where the map would be optional and if not provided, would default to uniform?

[Mugen87]

inconsistent (API-wise)

Do you mind explaining in more detail?

and could make with optimisations (separable implementation)

A separable approach is not necessarily an optimization for already small kernels because you need a separate render pass which is always an expensive operation even more in WebGL/WebGPU.

[Glypse]

Do you mind explaining in more detail?

Each of the three blurs mentioned have different inputs. While this makes sense, it isn't particularly plug-and-play, and I think making a consistent API would be nice. A very idealistic way I'm imagining this is (pseudocode):
blur(input: Node, radius: Node<float> | number = 1, options?: { premultipliedAlpha?: boolean, separable?: boolean, resolutionScale?: Node<float> | number = 1 }): Node<vec4>, where radius could be non-uniform (a float map, also commonly known in other softwares as "Luma Blur"), and where other blur-implementation-specific options would be included in options, such as sigma for gaussianBlur, repeats for hashBlur, etc.

A separable approach is not necessarily an optimisation for already small kernels because you need a separate render pass which is always an expensive operation even more in WebGL/WebGPU.

I understand. In my use case though, huge blurs are what I sometimes need. We could put separable as an option to be able to choose between the two methods.

I believe that these additions would be welcome because a custom blur implementation isn't trivial and would be a nice addition as a utility.