We recently started a project which aims to expose all compositor node options into inputs, allowing you to create node groups that can control everything in the node.
For instance, this:
Becomes this:
However, some nodes are not very straightforward for their options to be exposed. And since we are already doing changes that require versioning, we might make some changes while at.
So I create this thread to gather some feedback.
Color Balance
Turning options into inputs would change the looks of the node quite a bit. Is this acceptable?
We got feedback from compositors that they don’t like how the Color Balance node is so big in Blender. Other software have a small equivalent, like the Grade node in Natron, which artists really like. So some artists might like that change nonetheless.
If Premultiplied is not zero, then the Convert Premultiplied is ignored and does nothing.
It was originally added to replace the Convert Premultiplied option, back when there was no consistent alpha handing in the compositor, but that never happened.
It was marked as a legacy option in the manual since 2.8, but I can’t find out why. Maybe the decision was made to keep the Convert Premultiplied option instead.
Should we keep Convert Premultiplied and remove the Premultiplied?
Or should we keep the Premultiplied slider and remove the Convert Premultiplied option?
Or should both be removed and we just assume the input is premultiplied?
Blur
Variable Size seems redundant. We can just always have it enabled and if the user leaves the size unconnected or connects a single value, then it becomes a non variable size.
Bokeh has nothing to do with bokeh. It forces the filter to be implemented using a separable filter even if it wasn’t separable as a form of approximation for speedier execution. And it does nothing for filter types that are already separable like Gaussian, Fast Gaussian, Box, and so on.
Should we rename bokeh to essentially mean something like “use faster approximation”.
Gamma is a legacy option and converting into an option doesn’t seem worth it.
If Size X and Size Y became input, then the existing Size input would be redundant, should it be removed?
The Relative option has the sub-options Aspect Correction, how will this be handled when the option becomes an input?
Relative blur has its own X and Y sizes. If we reuse the same inputs, then users might end up with a setup that has 100% relative sizes because relative was disabled and had some pixel sizes in already.
Relative sizing is a problem global to all filter nodes, so we need to think of a general solution.
How about we split the relative option into its own node that takes in relative sizes and converts them to pixel sizes given an image. An in-node operator could be provided to create this setup quickly to keep the workflow fast and discoverable?
Color Correction
A really big node that we will have to use panels for.
Though are the Red/Green/Blue options really useful to warrant creating three boolean inputs for?
Bright And Contrast
There is a Convert Premultiplied option that is enabled by default and does the adjustment on straight alpha instead.
It seems this is the only node that needs to operate on straight alpha. Why is that?
Even if it is a niche option, why it it enabled by default? This node breaks images with transparent emission by default.
Should this be removed instead of being turned into an option?
Composite And Viewer
It was decided that the Use Alpha option would be removed instead of being made an input.
Should this happen in 4.5 or in 5.0?
Defocus
Sigh …
Should we expose the shape enum with an integer that controls the number if sides in the bokeh shape?
Or should we expose the entire shape as an image like the Bokeh node?
This seems a lot nicer in my opinion really, I don’t miss seeing the huge color wheels. On the subject of the Color balance node, the Lift/Gamma/Gain mode is sort of broken and blender users are usually steered away from it in tutorials. Offset/Power/Slope tends to be the go to so, do you think there would be a reason to make it the default since changes are happening anyway?
I think so yes, regrettably.
Might as well do it in 4.5, test the waters. Dumping every potential “wild” change into 5.0 isn’t always the best idea imo
Regarding Premultiplied alpha, I am on the side of removing duplicated functionality and just use Convert Alpha node. Makes nodes simpler and node trees easier to read.
Should this happen in 4.5 or in 5.0?
4.5, do it. Every time I try to move these nodes I disable Use Alpha instead. Every damn time!
Relative sizing is a problem global to all filter nodes, so we need to think of a general solution.
It would be nice to have generic way of handling relative vs absolute values in compositor since not all nodes have relative value option, for example Displace node.
Removing redundant nodes for 5.0
Transform node – it’s worse in every way than separate transform nodes.
The Alpha Over node expects the foreground image to use Premultiplied Alpha. If it uses Straight Alpha instead, you can enable this checkbox to convert it.
So you can’t just assume it’s Premult, and remove the checkbox. If it’s straight, the artist would expect it to stay straight until they change it themselves.
As far as the Premultiplied Slider/Factor option, I don’t see the reason for this to be there at all. I understand the manual description, but creating a mix of straight & preMult - have literally never done that in a comp.
This is not really a breaking change and can be done anytime, so sure, we can look into it, and if there is a good argument, we can change the default.
We also got the feedback that other nodes should be joined to the transform node. That is, improve it and remove separate transform nodes. So we will look into this if the time allows.
Not sure what you mean. The compositor already expects and converts everything to be premultiplied, the artist would need to explicitly convert it to straight to have an image with straight alpha. And it is not going to stay straight either way after alpha overing. Because the alpha over node pre-multiplies the alpha by definition. The checkbox just says, “Is it already premultiplied or should I premultiply it?”.
Other compositing software assume alpha is premultiplied for their over merge operations. But they do provide an operation that operates on straight alpha, which they usually call a Matte operation.
I am not advocating for removing the checkbox by the way, just presenting the arguments. If it is up to me, I would probably just rename it to something more clear.
The slider with the checkbox on this node is really confusing to use at first. Simplifying that would be great.
I’ve done a straight and premultiplied mix (can’t say I’m proud of it lol), but with an Alpha Convert and a Mix. So you can do the same thing without the node already. For whatever reason the previous alpha had gotten screwed somewhere along the line and that seemed to force it back. I’d be very surprised if anyone’s doing that often enough to need it as an option here though.
Haven’t used it ever before and now that I gave it a try I couldn’t get it to work. Changing the Alpha threshold doesn’t seem to affect anything in my quick tests.
I know what the code tries to do, which is to try to darken the edges of the result as you increase the alpha value. But the code uses a very small darkening factor that it only has marginal effect on the image, and for the user it apparently does nothing.
So I am thinking of removing it for now.
And if you guys think it is really necessary, we can later introduce a new mechanism to “darken the edges”.
I really like the new color balance and it is in line with all the other nodes, so absolutely acceptable.
For me less is more if there is already a node able to convert alpha, it is simply a repetition and we must assume that over means what A*(1-A.Alpha * B) actually is, A is therefore assumed to be already multiplied by alpha.
In my opinion it is ok to eliminate variable size and size but I do not agree with not exposing sockets for XY (obviously variable size always active), but more generally I believe that all the parameters of the node should be exposed for reasons of coherence and not in terms of possible uses, even if I realize that this can mean more work at times. Instead, and here I open an off topic, has anyone ever thought of focusing attention more on the nodes of the filter and transform category and making most of all the other nodes (most of the Color and Keying categories for example) groups of nodes? In this way it could be more advantageous to develop and maintain a few low-level nodes.
For the aspect correction options they should be transformed into a drop-down menu. The idea of ​​having a resolution-independent compositor for the filter nodes fascinates me and the proposed idea seems very valid to me. Could it be another idea to directly add a global option that in one go makes the entire compositor “relative”? “20” could be “pixel” or “%” at the same time… This would obviously imply the user choosing in principle which unit of measure to use in the compositor but it would eliminate the addition of dozens of nodes.
For color correction, in order to create procedural workflows, it is very useful to expose the three boolean inputs.
For brightness and contrast, in my opinion convert premultiplied should also be removed here and its behavior should be consistent and predictable with all the other color nodes.
Absolutely expose sockets for images, this, in addition to the use of the bokeh image node I imagine would open the possibility of creating custom and complex kernels (perhaps obtained from live action images).
We will definitely expose Size X and Size Y, the problem was just how we were going to handle the relative case.
Yes, that’s the plan. And that’s one of the reasons why we are doing this project. But we still need to improve the extensibility aspect of the compositor before we are able to do that.
We intent to support implicit relativism in common cases like proxy resolution and anamorphic images. But that’s a problem for another day, and we will likely create another devtalk thread for this specific issue.
As per the Defocus node. If exposing the sockets opens the door to reevaluate/extend the nodes functionality, I have some thoughts:
The main issue at the moment is that the node itself doesn’t allow you to select a focal plane and a bokeh size easily. I found that you need to convert the depth info to a “blur amount” by doing some math on it that depends on the focal plane, so that things in front of and behind the focal plane are defocused, but the focal plane is not. This is the math I’m doing, It’s not super accurate, rather more of a simple approximation:
I have a detailed explanation of how I defocus in the compositor here:
As a general rule of thumb, it would be great to have the settings line up as close as possible with the DOF settings in Blender’s camera, just changinf the Fstop setting by a “size” input (measured in px). As per the “Bokeh shape” conversation - in my opinion - it would be awesome to get two options as a dropdown: predefined os custom.
By choosing the predefined option, the user should be able to shape their bokehs the same way they do with blender’s internal camera, by choosing:
Blades
Rotation
Ratio
These options can or cannot be exposed.
Alternatively, by choosing custom the user should be presented with an image socket for them to connect their own bokeh image - either created through the bokeh node or loaded as a bitmap.
So, to sum up, I think the Defocus node should look something like this:
The Defocus node already gets its defocus distance from the selected scene based on the camera settings, and they are physically accurate. I am guessing you are not aware about this possibility, but would you use it now? Or would you rather define the defocus distance manually?
F-Stops is necessary to compute an accurate circle of confusion size, which would be in contrast to the size we provide in the node.
I feel like your proposal would be rather similar to the Bokeh blur node, so I guess we could might as well merge them into a single node?
Thank you for the detailed response, @OmarEmaraDev. As per the Ideas we discussed on Providing this functionality as a Node group asset, I’d love to suggest a mockup of how that could look @izo.
This is closer to what I’m used to from production work in other software. Please let me know your thoughts in case this is useful!
