Contents of "Viewer Node" image block do not get updated #54314
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
11 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#54314
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This might not necessarily be a bug, but may be a feature request. I apologize in advance for being very unprofessional here. I don't think my problem is necessarily relevant to the way I build Blender of the system hardware I use. I've seen the same problem over and over on different systems. Anyways, I compile Blender from source as follow on a freshly-installed Ubuntu:
Here's how I set up Ubuntu after installing it:
I want to do a very simple thing but it seems that it's becoming very complicated to do it. I have described what my problem is [here ]]. I do not necessarily want to simulate clicking but it turns out that I cannot update the contents of 'Viewer Node' image block. Finally, I thought the best way would be to automatically have backdrop enabled. So I followed the instructions given [ https:*blender.stackexchange.com/questions/72742/depth-data-works-but-not-in-background-mode | here by Sebastian Koch thinking that I should be able to dynamically add/remove view nodes and update the contents of the image block automatically. Although I could access to the pixels, but But this does not happen!
I wrote the right code to do exactly what I show in [this video ]] but the pixels in "Viewer Node" image block do not get updated, as they do in the video. Not only that, I tried activating newly-added Viewer nodes manually (as described [ https:*blender.stackexchange.com/questions/102790/how-to-trigger-lmb-click-events-to-activate-a-specific-view-node-and-update-cont | here ) but I am still unsuccessful in updating the pixels in the image block. I also tried removing the image block in Python and then continue adding new Viewer nodes. But from the time I remove the image block its contents will always be zero even if I redo the rendering.
The only way I could successfully update the contents of the image block was after, first, I followed Sebastian Koch's solution and then wrote some code to remove/add all nodes and their links to get either depth map or surface Normals and did the rendering again. But the whole point of me trying to store pixels into Numpy arrays was to avoid doing re-rendering to get around the IO overhead. I could have instead stored two files (for both depth map and Normal maps) throught two Output nodes with rendering only once.
First, if this behavior does not look like a bug, I would appreciate the community provide me an easy solution to do what I want. Second, It would be great if you can improve Blender's Python API and add ways of easily accessing rendering results in memory so that people like me who want to do millions of rendering do not need to deal with the delays cause by IO to transfer rendering results from memory to hard drive and can easily store the results into Numpy arrays and store them on disk in chunks.
Added subscriber: @AmirS
Unable to update the contents of "Viewer Node" image blockto Contents of "Viewer Node" image block do not get updatedContents of "Viewer Node" image block do not get updatedto Contents of "Viewer Node" image block do not get updated even with backdrop onContents of "Viewer Node" image block do not get updated even with backdrop onto Contents of "Viewer Node" image block do not get updatedAdded subscriber: @sambler
When a composite node tree has two viewer nodes, clicking one of them will update the Viewer Node image shown in the image editor which is also used for the node editor backdrop. I don't see a way to do this update from python (with or without a UI).
I would expect that setting a node as selected and active and then tagging the node tree for an update and doing a scene.update, that the viewer node output would get updated. This is not the case and I don't see a way to make the viewer image update.
So the following lines will select and make a viewer node active but even using the GUI, you still need to manually click the node to get the viewer output to update. So there is an extra update step performed when selecting a node in the GUI that doesn't get run in a scene update.
If this is a bug, it would be that
scene.update()
doesn't refresh composite node tree data or specifically viewer node data. Otherwise it is a lack of access to update the viewer image data.Added subscribers: @Jeroen-Bakker, @lichtwerk
Interesting problem.
Taking a step back, issues seem to be
regarding the second issue:
I've had a quick look and there seem to be two node flags involved to get this going (
NODE_ACTIVE
andNODE_DO_OUTPUT
)The second one is only set from
ED_node_set_active()
, so only in the Editor (by selecting the node), not by python / RNA.I've also tweaked the code here (copied over stuff from
ED_node_set_active()
tonodeSetActive()
, so it gets done from python / RNA -- but thats probably a bad idea as well with consequences that I need to investigate further).If you do this and update properly, then the compositor will actually really start recalculating and the "Viewer Node" image will update eventually.
That doesnt get you too far though, because as @Jeroen-Bakker answered here the compositor is a background job, so reading pixels will only help when that is really finished...
Long story short: this is not a bug but a known limitation (but an interesting one that would be nice to get out of the way)
@lichtwerk @Jeroen-Bakker Thanks for investigating this more. I also remember at some point I was accessing the pixels directly through "Viewer Node" image block and stored them on disk. What I realized however was the pixels were sort of rotated. I remember the depth map rendering that I got was shown 90 degrees rotated. If possible, please take a look at this too.
I also have a request from you: I would appreciate if you can provide a nice Python API that allows people to easily access the rendering results without having to store the renderings on disk. Maybe
bpy.ops.render.render()
could take an argument likekeepInMemory=True
. Then people can access the rendering results through something likerenderings = np.array(bpy.ops.render.results)
. The should also account for having a couple of output nodes. For instance, if in the node editor I have 5 Viewer nodes,renderings
should be a5 x 4 x resolution x resolution
tensor.@Jeroen-Bakker Does this fix have anything to do with this issue?
@AmirS No. Just tried with
741d7d60ed
Using python we can change the active compositer viewer node, with
nt.nodes.active = v2
and in python the active value will say that the desired node is active, but this is not visually reflected in the node editor. The viewer node has to be manually clicked to make it visually active which then updates theimages['Viewer Node']
data that we want to access.@sambler I haven't tried this in 2.8x. Did you try it with both 2.79x and 2.8x?
@AmirS I checked with a master build before my previous comment. I hadn't tried in 2.79 for a while but just checked and it hasn't changed, not that any fixes will be done to 2.79.
I posted a devtalk thread regarding this as well --> https://devtalk.blender.org/t/is-it-possible-to-store-keep-the-rendering-result-in-memory-only-and-avoid-doing-i-o/11852
Since I do not intend to work on this soonish, will step down to not block others from working on this, sorry.
Added subscriber: @cartucho
Online questions regarding this issue:
https://blender.stackexchange.com/questions/32640/two-viewer-nodes-switch-between-output-images
https://blender.stackexchange.com/questions/164386/get-image-pixels-from-multiple-viewer-nodes
@lichtwerk any news regarding this issue?
Added subscriber: @AnSstuff
Hopefully the issue can be resolved someday, as it slows down batch processing for no reason.
Here's my usual workflow when I need to custom-process Diffuse/Normals/Vector/Freestyle data for many frames of animation at once:
Instead of having several Viewer nodes in Compositor it's enough to have a single Viewer node plus several Switch nodes, and then in Python script:
If it was possible to just call something like
compositor.refresh()
instead ofbpy.ops.render.render()
, this loop would finish 5 times faster.Since python thread is already able to wait for bpy.ops.render.render() completion event, why cannot it similarly wait for compositor.refresh() completion?
Added subscriber: @3di
oh man, what a show stopping problem. Can anyone recommend a good python package for controlling the mouse that works on windows, mac and linux without the user having to grant any permissions at OS level?
If this bug got fixed it would greatly benefit my VisionBlender add-on: https://github.com/Cartucho/vision_blender.
Added subscriber: @kkostovas
Added subscriber: @9and3
Are there any updates from this feature request?
How could we help fix this bug/issue?
Hm, I am wondering if a solution might be to add something like a "COMPO_POST" handler here?
https://docs.blender.org/api/3.3/bpy.app.handlers.html
This might be pretty straight forward to implement and should make reacting to the change of the viewer node possible?
This issue was referenced by
16d329da28
So the callback was straightforward and now getting pixels after clicking already works nicely:
P2987: Add COMPOSITING_POST handler
But the original issue of
ED_node_set_active
(Editor) vsnodeSetActive
(RNA / py API) remains to be tackled, will check on this again.Actually, with just the callback and using the method to use
Switch
nodes, this is already working:#54314.blend
@lichtwerk thanks for having a look into it!
I tried that file and it works if we trigger the switch via click, but if in the
Scripting
tab I triggerbpy.context.scene.node_tree.nodes["Switch"].check = True
and thenbpy.context.scene.node_tree.nodes["Switch"].check = False
it won't change the pixels. So the python API issue remains, right?Regarding setting different viewers active: this will update correctly when setting different viewers active via python:
P2990: Handle NODE_DO_OUTPUT
@cartucho : using the switches should work already, do you have D15078 applied?
I have committed
16d329da28
to 3.3 now, let me know if you can get it working (with the switch workflow).@lichtwerk I have downloaded 3.3 and tried the following:
and changing with code the connection:
I got this:
The pixels obtained using
bpy.data.images['Viewer Node'].pixels
indeed seem to be changing now!Let me do a quick test to see if I can have multiple viewers and switch the active one through code.
I don't think there's a way to get the active viewer or composite node for a scene is there? Oh wait, active just means seleted doesn't it. For a moment I thought we could now find out which are being used for the backdrop and output.
@lichtwerk
T54314_test.blend
Regarding these other questions: question1, question2
This other test does not seem to work, having two viewer nodes and trying to activate one from Python:
It could be that I am not activating the node in the right way? Maybe I should not use
node_v2.select = True
Anyway, we can always change the connections as I did above, right? Changing the connections or using a switcher seem to be the solution.
would it not make more sense to be able to get/set with
bpy.data.scenes['scene'].node_tree.active_viewer
and
bpy.data.scenes['scene'].node_tree.active_composite
and each of these triggers the update when set instead? Having to select a node via code to get it to trigger an update seems a strange way of doing things. It would also be extremely handy to be able to find out this information under numerous circumstances when they're not selected.
@3di yeah, triggering a set/get to activate a viewer by name would be fantastic.
reg.
active_viewer
oractive_composite
: this might make sense (but is more of a refactor, since internally, there is no such distinction, there is only theNODE_DO_OUTPUT
tag (used for viewers as well as composite) and from this, the active gets determined on the fly). Will discuss this, but shortterm, will just post P2990 as a proper Diff (this will make it so once you set the viewer active via python, it will also properly be taggedNODE_DO_OUTPUT
-- same as done via a mouse).Having access to the NODE_DO_OUTPUT tag in python would solve the issue because it would enable python to also find the viewer node that's in use and the composite node that will be outputting at render time by doing:
composite_node_that_will_output = [n for n in bpy.data.scenes['scene'].node_tree.nodes if n.node_do_output and n.type == 'COMPOSITE'][0]
or for viewer
viewer_node_supplynig_the_backdrop = [n for n in bpy.data.scenes['scene'].node_tree.nodes if n.node_do_output and n.type == 'VIEWER'][0]
Like I said: makes sense probably, but a bit more work since managing setting
NODE_DO_OUTPUT
would mean carefully checking any sideeffects this could have (could be painless... but havent checked on this yet).My patch is just mimicing existing behavior, what you propose is more or less a feature request (one that makes sense, no doubt).
Could look into this next, but as immediate step, D15203 should already bring us across the goalline of this report, no?
awesome. Yeah read only would be sufficient. At the moment it's not actually possible to find out which node will supply the render. I'm having to ask users to select the composite node manually before rendering to let my addon know which branch it should work on :)
Great, thank you, Philipp Oeser!
Now the only remaining issue is that Viewer Image doesn't exist in Headless mode (when Blender runs with "-b" in commandline), which is often used for batch rendering in background.
This issue was referenced by
0bc95b7b40
Soo, we now have:
I know there have been suggestions here, but I think we have crossed the finish line for this report.
For the others, it would probably be good to report these separately (here or on RCS), this report can always be referenced.
Would everyone agree this can be closed?
Added subscriber: @derekbarker
I wouldn't even consider your solution as a solution to the actual problem. This was a workaround in the first place to get pixel data from renders. Now the workaround kind of works if you don't render headless which seems a bit pointless. The actual solution is to let users access rendered pixels. Not viewer pixels, clearly there is a lot of us trying to do this.
Viewer node not being available headless is a problem for this workflow, agree.
(I assume this will stay a Known Limitation)
Also agree that direct access to
Render Result
pixels should be tackled.There is even a solution outlined in #53768#776542 (unsure if this still works nowadays -- but might check next week)
But really, if we stick to this task (specific to the Viewer node), I consider it done.
Feel free to join the discussion in #53768 (Pixels and resolution not for multilayer EXR and Render Result)
Wait. I've just started porting my workflow to finally use the new feature of Blender 3.3.0, and apparently it does NOT work from Python scripts! Changing the switches or activating different Viewers still does not trigger Compositor refresh.
Back in June I've quickly tested #54314.blend without changing Blender windows layout, and was happy to see that Viewer image updates both when I manually click on Switch node checkbox and when I toggle the checkbox using small Python script in Text editor window below the Compositor. I didn't even check whether it updates when I toggle the checkbox from Python when there's no Compositor onscreen...
@lichtwerk can you re-test your #54314.blend with this script?
Sure, when there's Compositor open, any change in nodes will trigger refresh (due to window redrawing, I guess), but once you hide Compositor (change it to 3D Viewport, for example) - scripts won't update Viewer image anymore. Nothing updates until you return back to Compositor and manually click on a node, thus triggering a redraw.
Same problem with switching active Viewer. It only works when there's something else that triggers Compositor update (either window redraw or bpy.ops.render.render()), so we're back at square one. It's not enough to add compo handlers, there's need to add a way to trigger Compositing from Python.
Unfortunately, no.
For example, I'm setting active viewer from python like this
but Viewer Image only changes when there's Compositor open while switching the viewers. Thus unusable for writing operators or batch processors in Python.
@AnSstuff you could open a compositor from python temporarily before the code and close it again afterwards. Awfully messy, but should work I guess.
@3di This does not work. Even when Compositor is open, its window won't redraw until Python script finishes, thus it won't trigger compositing while doing batch processing, unless I call
bpy.ops.render.render()
every time.I wrongly assumed the Compositor would start compositing immediately after I change a node or switch viewers, but it only marks update_tag and doesn't refresh anything until something triggers full compositing update. Currently there's only 2 ways to trigger the update (1 - from GUI, 2 - from script by rendering), we need to add a third way, an operator
bpy.ops.render.compose()
Yes that's what I do, render.render() after muting all render layer nodes and nodes downstream of the branch I need to avoid rendering the 3d scene.
There's no difference between reading pixels from "Render Result" image and from "Viewer Node" image, once viewer node gets fixed in headless mode.
You'd still need a
bpy.ops.render.compose()
operator to recompose "Render Result" after switching from one pass to another.Yeah, selecting is not enough, you need to set the node active to benefit from
0bc95b7b40
T54314_test_corrected.blend
Thx following up btw, checking on launching the compo background job even if the compositor is closed.... (no promises here)
isn't render.render() with the render layer nodes muted the same as a recompose? This can already be done with the compositor not visible and during command line rendering.
Probably (havent checked yet)
Here is a real quicky for a
bpy.ops.node.composite()
operator (which just launches the context scene's compositor background job -- no questions asked):P3235: T54314_compsitor_operator
With that patch applied, you can do this (no compositor open):
T54314_compo_operator.blend
Would have to check with others for potential problems, just putting it out for someone to test
regarding the compo operator above: is this something worth pursuing @Jeroen-Bakker ?
Sorry I couldn't test it earlier.
So I've applied the patch to recent source (3.5.0 alpha, had to do it manually due to recent changes since the patch was made for 3.4.0).
This implementation doesn't seem to work. Just launching the compositor job doesn't result in Viewer Image change (while "Render Result" does change).
Here's my test that simulates real workflow: TestSwitchingCompositor.blend
The code is long because
bpy.ops.node.composite()
exits immediately (similar to callingrender.render('INVOKE_DEFAULT')
which returns immediately), so you have to setup events handling,I've tested this. Muting the Render Layers node produces blank image in both Render Result and Viewer Image, so while render.render() does finish as quickly as a recompose, it cannot be used for a meaningful result.
Added subscriber: @cdsousa
This new test T54314_test_corrected.blend works great. Will this feature be updated in one of the newer versions?