Omar,
Blender is fortunate to have you on the board, you are doing a great job.
Do you think it would be reasonable to add new nodes like for example the “Vibrance” node?
As I understand Vibrance raises the saturation of the less saturated parts of the image.
We already have a “Separate channels” node from which we can withdraw the saturation channel to use it as a multiplier for the original saturation of our image.
The same goes for the “Highlights” and “Shadows” nodes and the Lightness / Value channel.
Similar tools could be found in Adobe Lightroom (even my smartphone’s default photo editor has these). So adding these nodes seems like low-hanging fruit.
And although we all can DIY these nodes, it would be cool to have them under the belt to streamline the post-correction workflow.
I think your counterarguments are valid. On the other hand, when the viewer is connected to the same node that feeds into the compositor, seems pretty reasonable to expect that they would output the same result, from an user perspective. Maybe the composite node should have an output, so you could connect the viewer to it?
Edit: I hadn’t see the task link, thanks!. I also commented there
I’d personally prefer the old wrapping behaviour, because it is very usefull to overlay an image with a repeating pattern (for example a small 8x8 dither pattern). A tile node with a defined count would be very handy, too. But imo, filling the canvas with a pattern is more important.
Do you think it would make sense for the compositor to have an overlay that shows the render size similar to how the Camera View works in the 3d viewport? (Including the passepartout opacity).
I think it would be pretty handy to have an overlay like this, easy to toggle on/off as needed and it doesn’t depend on what operations you’re doing on images/footage, and it wouldn’t change any viewer node either.
It surely is interesting…although to me it feels like a workaround for what is an underlying incoherence: that there’s no explicit, simple way to just “view” the final output without testing that you are actually going to get out at render time is what you see with the viewer. And the solution should be provided by the viewer, imo.
I know there are ways to make sure… the thing is, sometimes you’d need them, and sometimes you wouldn’t. But in the current situation, better do it just in case…, or render it to make sure. That’s doesn’t feel right to me.
Is it possible that there is an issue with the multiple in the mix node? it feels like there is some kind of curve adjustment underneath which makes the mix response nonlinear.
The mixed image
Look at the difference between 0.25 all the way to 0.75 (the difference is barely visible) v 0.75 to 0.9 and 0.9 to 1.0
What I don’t understand is that the viewer doesn’t (easily? at all? can’t tell. And that itself, is a problem) show an actual crop of the render size/area in the window. That’s a basic compositing thing; i shouldn’t have to render the composite, to see the final live area.
How does other software handle that or what do you propose to support both use-cases?
A quick look at Natron seems to indicate that they have the same viewer behavior as Blender.
the difference is that the final node (the composite in this case) is actually “viewable”. You can connect it to the viewer, and see what it is really going to output. Like at any other point of the tree.It behaves just like any other node.
One example of how it would work if blender worked the same way:
You load an image that’s 7000x5000px to the compositing tree and connect that directly to the viewer. Then it would show that to you, full format (as if it were a regular image viewer…bonus points if it were an EXR, it would give the option to choose which layer to see somewhere in the UI).
But if you connect that into the composite and feed it to the viewer instead (that’s what’s really lacking IMO), it would show you the same image, but now it would be cropped to the actual output of your composition (which would be taken from the render properties).
And that’s what, to me, seems the weirdest thing. That, just at the very end of the tree, there’s a crucial point in the composition that potencially makes big changes to the final image, and you cannot see what, or if, it does without rendering it. And what @izo is doing with the passepartout and such is very nice, seriously kudos to him, but still to me feels like a workaround for a lack of basic usability of one of the main compositing nodes, which is being able to view the composite output as if it were a regular node…because it’s there in the tree.
In that case, maybe we should allow the user to view the composite node directly. That is, the backdrop would should the active composite node as opposed to the active viewer node. Though in that case we would need to adjust the workflow for quicking viewing outputs.
That’s the plan outlined in the task you referred to above, right?
The thing with that is that is kind of a halfway workflow for compositing. As mentioned earlier, if the workflow is to see things through the viewer, I think there should always be a viewer involved in the process.
But if there is the possibility to see the composite without any viewer node attached…why not make that the workflow and just get rid of the viewer node altogether, and simply indicate visually which node is being showed in the backdrop? And, when nothing’s selected, show the composite. And that would even work with quickly switching viewing nodes. And, in the end, the viewer doesn’t even provide with much functionality other than being a visual clue to what you are showing the user.
To me (sorry for repeating myself) the most straightforward from a user perspective would be to add the possibility to connect the composite to the viewer (maybe there’s a technical reason why it’s not feasible, I don’t know)…in the least it would make the behaviour consistent within the compositor.
On the other hand, what you propose would make it consistent with the geometry nodes workflow. I still think composite-to-viewer is easier and more explicit, but the inconsistency with GN would be there, sure.
What I mentioned in the task was a suggestion, which was not agreed upon, so it is planned.
The main problem I see in your suggestion is two things:
How would it work with the Ctrl + Shift + Click quick viewing experience? Would the shortcut insert both a composite and a viewer node? And how would we differentiate between composite viewing and simple viewing?
One of the design choices of the compositor is that output nodes do not have outputs and only input and output nodes can be implicitly affected by global data like the render region. Adding an output to the composite node would overload the node conceptually, which is something I want to avoid. If we want to go that route, we can just add the same functionality to the Render Size mode of the Scale node.
I am not sure, this seems to be an issue with mixing external images over renders or on generated components. I tried it with the raw view transform the issue seems to be there. I filed a bug if you want to take a look at it.
I understand that, it would be confusing having an output node with an output socket (which would imply that you could insert in the middle of a tree).
One way of dealing with that would be to allow some kind of a dynamic output socket in the output nodes, that would only appear when Ctrl-Shift-Click or Ctrl+0-9 (in the case of izzo’s proof of concept for quick toggling)…something similar to what happens in the geometry nodes, that there is a dynamic input socket that appears/changes when you Ctrl+Shift+Click on a geometry and then an attribute.
I’m not defending that option particularly strongly because I guess it would be creating a not very elegant exception to the workflow. But I think it could work.
Another way would be creating a workflow around what you propose, and is outlined in the task: having a default behaviour of when there is no active viewer node working (either turned off, hidden, muted, deleted…), default to composite. Then it could be something like this?
I’m sure there are things I’m missing, it was a first go at it. But the main idea is:
when you work, you can go and Ctrl+0-9 any node (e.g. Ctrl+1), and it will become the active view.
If you then Ctrl+2 another one, that one becomes the active view, and it gets connected to the viewer node (the viewer node in this case should have a multi-input socket)
Then, working continues normally until one of two things happen: A) Ctrl-Shift-click. or B) press a number key.
A) If you Ctrl-Shift-Click over a node, it becomes active, as is standard. If you click over the background, then the viewer turns off and composite becomes active (as if it would happen with a geometry nodes output node)
B) If you press a number, it can be previously assigned or not. If there is a node assigned, it becomes active.
If it was already active it could toggle the active state between said number connection and composite
If not, nothing happens, but the user should get a message that there is nothing assigned to it (maybe in the status bar?)
The idea here is that the people that don’t find the quick connect workflow handy can safely disregard it. And the viewing behaviour in the case of Ctrl-Shift-Click would be consistent with GN.
And, regarding your question:
And how would we differentiate between composite viewing and simple viewing?
I guess there should be an indication over the backdrop/image viewer that indicated either composite/node/number…but at the same time, GN doesn’t provide a visual clue about what you’re seeing as the output of your tree, am I wrong?
The entire design paradigm of blender’s compositing window has never made sense to me. To illustrate:
Scene set to render 1920x1080. Nothing in this background is showing the actual render area, so i outlined it in pink. (I’m aware of the possible incoming PR, discussed above).
How do other apps do it? Well, i know how AE does it - the comp window shows you what the comp actually IS. Not “everything in the file”, whether within the render “area” or not. (Yeah, you can deal with elements outsite the render area in AE, but at the basic level - what you see is what the comp IS.
This seems sort of basic “how it should work to me”, but again - i’ve never understood the Blender reasoning on why it works as presently done. It’s one of those things I just said “Ok, whatever, I just have to accept this weird thing and move on.”
Omar explained it above somewhere, basically there are cases when you might want to see the scaled image at full and it would not be possible to see the full image without the current flow.
You can split the viewport area, open the image viewer in the new window, then select the Render Result from the dropdown for seeing the final composited image. You can also pick the viewer node from the menu if you do not want to use the background viewing option. This workflow is closer to how other compositing apps handle viewers.
(I wonder if this option would be more performant than using the viewer in the background)
I’ll agree there might be some case, but I don’t see how what sounds a bit like an edge case = and for all the other time, this is how this window will work.
There are other solutions to seeing something larger. You open it in another window viewer, or another application or whatever.
It’s like - I’m not even sure how to describe it. This is as if you’re working in a print layout program, which has a 4-ft pasteboard. The actual document area is 10 inches square. 98% of the time, what is the area you actually care about seeing with margins and the correct bordering - it’s the document, not the 4 ft pasteboard. This is why when you zoom to fit the window in a layout program, you get the document fitting the window, not everything else also.
You might be using a source photograph in this layout program that is 20 ft wide, but that doesn’t mean I need to see a 20 ft wide image, with the document represented at 2 inches in the middle.
