Hi everyone,
The documentation of the Blur Node states under the section Size:
The optional Size input will be multiplied with the X and Y blur radius values.
It also accepts a value image, to control the blur radius with a mask.
The values should be mapped between (0 to 1) for an optimal effect.
After some testing I found that the last statement doesn’t seem to be true anymore.
In all cases that I tested there was no difference between having the Size input between (0 to 1) and using a Size input that is larger than 1.
For example the input combination of X = 100; Y = 100; Size = 0.3 gives exactly the same output as X = 10; Y = 10; Size = 3.
Is it possible that the statement The values should be mapped between (0 to 1) for an optimal effect. is outdated and doesn’t hold true anymore?
It would be nice if someone from the compositing team could clarify. @OmarEmaraDev
The CPU code is probably the one in the wrong, so the manual is correct. GPU is correct already.
No need to report a bug, this code will be removed anyways.
By “wrong” do you mean that the output is different when Size is greater than 1?
Size is clamped between [0, 1].
So after some more testing I found that it’s the GPU code that clamps the Size input, while the CPU code doesn’t.
Is there a reason why it’s being clamped on the GPU? From a user standpoints it’s annoying to have to remap the Size input into a [0, 1] interval.
When you said:
Did you mean the CPU code will be removed, i.e. the Size input will also be clamped for the CPU compositor in the future? If yes, I think that would be a rather unfortunate change, it would be much better to have both CPU and GPU variants have an unclamped Size input.
Size is already clamped even in CPU if you are doing variable size blurring, so it doesn’t make sense to change the range of an input depending on weather something is connected to it or not. Further, it doesn’t make sense to provide two inputs that does the same thing. And [0, 1] range is much safer in case users accidentally plugged in huge values, which is how other nodes handle that case.
Blur radius will be exposed as an input, so controlling it would be preferred in that case.
1 Like