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.
Now, of course you can use a different layout, and drop the render up there. Then you only see the full comp result. But, now we’ve other things that come along.
I would expect at least one of those “frame all” commands to - like, fill/fit-to-fill the upper frame (viewer) on a live basis, if the window resizes. But, doesn’t happen. (And in fact, in practice I can barely tell that they have a different function. One just sort of results in “fit + a little extra margin” or something)
I agree that most of the time you want the composition output size… But that doesn’t mean that it should only default to that regardless of what you are feeding the viewer/composite. And it’s not at all an edge case, I’ve found it useful many many times.
Working in the matte/bg part of the compositing specially… Often I’d have to create/work with mattepaintings with multiple layers that are going to be reused multiple times, and you need to tweak things besides the final transforms. And in those situations is really nice to be able to see the whole thing, not just a little part. Maybe it’s not the most usual case, but I’d argue is far from edge case.
What could be nice it’s what @OmarEmaraDev comments. An enum in the composite/viewer node to let the user choose between input/render crop. So if it’s set to input, it shows and even renders out whatever is fed into it, regardless of render dimensions. That would allow the workflow of rendering out intermediate states of the comp (even simply as a kind of temporary bake while working) that may not be in the final format, without needing with your final output dimensions
I think it should default to that, but not be the ONLY option.
I poorly phrased it as an edge case. I meant that only compared to what one normally deals with in a sort of NLE editing approach, not … “edge case = hardly ever needed.” As with the pasteboard/layout example - pasteboards have a great use, but I don’t think at the expense of - the actual document size viewing.
Yes, I thought about that too, and it would technically work, but I’m not a fan at all, just because in a complex tree (which would be the type of tree that would benefit the most of that mapping behaviour) I think it would be very messy very fast, because the viewer nodes would scatter around and if would be really hard to scan. If they were much more obvious, maybe? But I’m skeptical even if that were the case.
When working in the geometry node editor, when there’s a kind of complex tree and I have to go looking for the viewer node… Oh man. It is a pain, because they don’t stand out at all. I would not want having to look for more than one of those. They would have to be neon colored for me to be kind of ok with it.
To be fair though, the Ctrl+Shift+Click workflow implied that you shouldn’t be really bothered to where the viewer node is… But still I think they could potentially create a lot of visual clutter, and you do want to see at a glance what nude is connected to the active viewer, and the current UI design colors makes it hard.
