Contents of "Viewer Node" image block do not get updated #54314

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:

apt-get -y update && apt-get -y install locales \
                                            make \
					    dpkg \
                                            wget \
                                            bzip2 \
                                            libglib2.0-0 \
                                            libxext6 \
                                            libsm6 \
                                            libxrender1 \
                                            g++ \
                                            gcc \
                                            xvfb \
                                            libyaml-cpp-dev \
					    git \
                                            cmake \
					    vim \
					    curl \
					    ca-certificates \
                                            software-properties-common \
					    python3 \
                                            python3-pip

git clone https://git.blender.org/blender.git
cd blender
git checkout 8ef39d5c882896bd75e0d4d17fb3e3d4710fc768 # Blender 2.79
git submodule update --init --recursive
git submodule foreach git checkout master
git submodule foreach git pull --rebase origin master

blender/build_files/build_environment/install_deps.sh --source=/blender-git/

PPATH="$(which python3)"
cmake blender \
    -DCMAKE_INSTALL_PREFIX=/usr/lib/python3/dist-packages \
    -DWITH_INSTALL_PORTABLE=OFF \
    -DWITH_PYTHON_INSTALL=OFF \
    -DWITH_PYTHON_MODULE=ON \
    -DPYTHON_SITE_PACKAGES=/usr/lib/python3/dist-packages \
    -DPYTHON_VERSION=3.5 \
    -DWITH_OPENAL=ON \
    -DWITH_CODEC_AVI=ON \
    -DWITH_MOD_OCEANSIM=ON \
    -DWITH_CODEC_FFMPEG=ON \
    -DWITH_SYSTEM_GLEW=ON \
    -DWITH_FFTW3=ON \
    -DWITH_OPENCOLORIO=ON \
    -DWITH_GAMEENGINE=OFF \
    -DWITH_PLAYER=OFF
make -j 7
make install

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.

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: ``` apt-get -y update && apt-get -y install locales \ make \ dpkg \ wget \ bzip2 \ libglib2.0-0 \ libxext6 \ libsm6 \ libxrender1 \ g++ \ gcc \ xvfb \ libyaml-cpp-dev \ git \ cmake \ vim \ curl \ ca-certificates \ software-properties-common \ python3 \ python3-pip ``` ``` git clone https://git.blender.org/blender.git cd blender git checkout 8ef39d5c882896bd75e0d4d17fb3e3d4710fc768 # Blender 2.79 git submodule update --init --recursive git submodule foreach git checkout master git submodule foreach git pull --rebase origin master blender/build_files/build_environment/install_deps.sh --source=/blender-git/ PPATH="$(which python3)" cmake blender \ -DCMAKE_INSTALL_PREFIX=/usr/lib/python3/dist-packages \ -DWITH_INSTALL_PORTABLE=OFF \ -DWITH_PYTHON_INSTALL=OFF \ -DWITH_PYTHON_MODULE=ON \ -DPYTHON_SITE_PACKAGES=/usr/lib/python3/dist-packages \ -DPYTHON_VERSION=3.5 \ -DWITH_OPENAL=ON \ -DWITH_CODEC_AVI=ON \ -DWITH_MOD_OCEANSIM=ON \ -DWITH_CODEC_FFMPEG=ON \ -DWITH_SYSTEM_GLEW=ON \ -DWITH_FFTW3=ON \ -DWITH_OPENCOLORIO=ON \ -DWITH_GAMEENGINE=OFF \ -DWITH_PLAYER=OFF make -j 7 make install ``` 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 ](https:*blender.stackexchange.com/questions/102790/how-to-trigger-lmb-click-events-to-activate-a-specific-view-node-and-update-cont) 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 ](https:*youtu.be/YCv5qdKLkZo)) 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

Added 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.


v1.select = True
bpy.context.scene.node_tree.nodes.active = v1
bpy.context.scene.node_tree.update_tag()
bpy.context.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

lack of pixel access for Render Result [including Passes]. This is a known limitation (see also #53768)
lack of really updating the Viewer Node (without rerendering) from python

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 and NODE_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() to nodeSetActive(), 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...

But The answer at this moment is you can’t. The python interpreter needs to be finished in order to start the compositor recalculation. This is a background job and after it is finished you know for certain that the new image has been updated.
If we would have a possibility in the API to find out if the background job of the compositor is running we would be able to start a python thread or modal window to wait for this to happen and then continue the task you want to do.

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 like keepInMemory=True. Then people can access the rendering results through something like renderings = 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 a 5 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 the images['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:

@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:

# 1 - collect data into Lists[numFrames]
for frame in range(0, numFrames):
   bpy.context.scene.frame_set(frame)
   # render Image
   bpy.context.scene.node_tree.nodes["Switch1"].check = False
   bpy.context.scene.node_tree.nodes["Switch2"].check = False
   bpy.context.scene.node_tree.nodes["Switch3"].check = False
   bpy.context.scene.node_tree.nodes["Switch4"].check = False
   bpy.ops.render.render(write_still=False)
   bpy.data.images['Viewer Node'].pixels.foreach_get(images[frame])
   # get depth
   bpy.context.scene.node_tree.nodes["Switch1"].check = True
   bpy.ops.render.render(write_still=False)
   bpy.data.images['Viewer Node'].pixels.foreach_get(depths[frame])
   # get normal
   bpy.context.scene.node_tree.nodes["Switch2"].check = True
   bpy.ops.render.render(write_still=False)
   bpy.data.images['Viewer Node'].pixels.foreach_get(normals[frame])
   # get vector
   bpy.context.scene.node_tree.nodes["Switch3"].check = True
   bpy.ops.render.render(write_still=False)
   bpy.data.images['Viewer Node'].pixels.foreach_get(vectors[frame])
   # get Freestyle overlay
   bpy.context.scene.node_tree.nodes["Switch4"].check = True
   bpy.ops.render.render(write_still=False)
   bpy.data.images['Viewer Node'].pixels.foreach_get(freestyles[frame])
# 2 - process the data
result = processAllFramesAndLayers(images, depths, normals, vectors, freestyles, numFrames, imageWidth, imageHeight)
myOutputEXRImage.pixels.foreach_set(result)
myOutputEXRImage.save_render(filename + ".exr"))

If it was possible to just call something like compositor.refresh() instead of bpy.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?

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: ![multilayer_compositing.png](https://archive.blender.org/developer/F8952082/multilayer_compositing.png) 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: ``` # 1 - collect data into Lists[numFrames] for frame in range(0, numFrames): bpy.context.scene.frame_set(frame) # render Image bpy.context.scene.node_tree.nodes["Switch1"].check = False bpy.context.scene.node_tree.nodes["Switch2"].check = False bpy.context.scene.node_tree.nodes["Switch3"].check = False bpy.context.scene.node_tree.nodes["Switch4"].check = False bpy.ops.render.render(write_still=False) bpy.data.images['Viewer Node'].pixels.foreach_get(images[frame]) # get depth bpy.context.scene.node_tree.nodes["Switch1"].check = True bpy.ops.render.render(write_still=False) bpy.data.images['Viewer Node'].pixels.foreach_get(depths[frame]) # get normal bpy.context.scene.node_tree.nodes["Switch2"].check = True bpy.ops.render.render(write_still=False) bpy.data.images['Viewer Node'].pixels.foreach_get(normals[frame]) # get vector bpy.context.scene.node_tree.nodes["Switch3"].check = True bpy.ops.render.render(write_still=False) bpy.data.images['Viewer Node'].pixels.foreach_get(vectors[frame]) # get Freestyle overlay bpy.context.scene.node_tree.nodes["Switch4"].check = True bpy.ops.render.render(write_still=False) bpy.data.images['Viewer Node'].pixels.foreach_get(freestyles[frame]) # 2 - process the data result = processAllFramesAndLayers(images, depths, normals, vectors, freestyles, numFrames, imageWidth, imageHeight) myOutputEXRImage.pixels.foreach_set(result) myOutputEXRImage.save_render(filename + ".exr")) ``` If it was possible to just call something like `compositor.refresh()` instead of `bpy.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:

import bpy

def my_handler(scene):
    print(scene.node_tree.nodes.active)
    print(bpy.data.images['Viewer Node'].pixels[:3])

bpy.app.handlers.compositing_post.append(my_handler)

P2987: Add COMPOSITING_POST handler



diff --git a/source/blender/blenkernel/BKE_callbacks.h b/source/blender/blenkernel/BKE_callbacks.h
index 8b2af96a063..d2e3f61f6cb 100644
--- a/source/blender/blenkernel/BKE_callbacks.h
+++ b/source/blender/blenkernel/BKE_callbacks.h
@@ -97,6 +97,7 @@ typedef enum {
   BKE_CB_EVT_XR_SESSION_START_PRE,
   BKE_CB_EVT_ANNOTATION_PRE,
   BKE_CB_EVT_ANNOTATION_POST,
+  BKE_CB_EVT_COMPOSITING_POST,
   BKE_CB_EVT_TOT,
 } eCbEvent;
 
diff --git a/source/blender/editors/space_node/node_edit.cc b/source/blender/editors/space_node/node_edit.cc
index ab80a44d636..031de50cadf 100644
--- a/source/blender/editors/space_node/node_edit.cc
+++ b/source/blender/editors/space_node/node_edit.cc
@@ -15,6 +15,7 @@
 #include "DNA_text_types.h"
 #include "DNA_world_types.h"
 
+#include "BKE_callbacks.h"
 #include "BKE_context.h"
 #include "BKE_global.h"
 #include "BKE_image.h"
@@ -293,6 +294,15 @@ static void compo_startjob(void *cjv,
   ntree->progress = nullptr;
 }
 
+static void compo_endjob(void *cjv)
+{
+  CompoJob *cj = (CompoJob *)cjv;
+  Main *bmain = cj->bmain;
+  Scene *scene = cj->scene;
+
+  BKE_callback_exec_id(bmain, &scene->id, BKE_CB_EVT_COMPOSITING_POST);
+}
+
 /** \} */
 
 }  // namespace blender::ed::space_node
@@ -339,7 +349,7 @@ void ED_node_composite_job(const bContext *C, struct bNodeTree *nodetree, Scene
   /* setup job */
   WM_jobs_customdata_set(wm_job, cj, compo_freejob);
   WM_jobs_timer(wm_job, 0.1, NC_SCENE | ND_COMPO_RESULT, NC_SCENE | ND_COMPO_RESULT);
-  WM_jobs_callbacks(wm_job, compo_startjob, compo_initjob, compo_updatejob, nullptr);
+  WM_jobs_callbacks(wm_job, compo_startjob, compo_initjob, compo_updatejob, compo_endjob);
 
   WM_jobs_start(CTX_wm_manager(C), wm_job);
 }
diff --git a/source/blender/python/intern/bpy_app_handlers.c b/source/blender/python/intern/bpy_app_handlers.c
index bf427d9639a..9b0b6cbf39e 100644
--- a/source/blender/python/intern/bpy_app_handlers.c
+++ b/source/blender/python/intern/bpy_app_handlers.c
@@ -66,6 +66,7 @@ static PyStructSequence_Field app_cb_info_fields[] = {
     {"xr_session_start_pre", "on starting an xr session (before)"},
     {"annotation_pre", "on drawing an annotation (before)"},
     {"annotation_post", "on drawing an annotation (after)"},
+    {"compositing_post", "on compositing background job (after)"},
 
 /* sets the permanent tag */
 #define APP_CB_OTHER_FIELDS 1

But the original issue of ED_node_set_active (Editor) vs nodeSetActive (RNA / py API) remains to be tackled, will check on this again.

So the callback was straightforward and now getting pixels after clicking already works nicely: ``` import bpy def my_handler(scene): print(scene.node_tree.nodes.active) print(bpy.data.images['Viewer Node'].pixels[:3]) bpy.app.handlers.compositing_post.append(my_handler) ``` [P2987: Add COMPOSITING_POST handler](https://archive.blender.org/developer/P2987.txt) ``` diff --git a/source/blender/blenkernel/BKE_callbacks.h b/source/blender/blenkernel/BKE_callbacks.h index 8b2af96a063..d2e3f61f6cb 100644 --- a/source/blender/blenkernel/BKE_callbacks.h +++ b/source/blender/blenkernel/BKE_callbacks.h @@ -97,6 +97,7 @@ typedef enum { BKE_CB_EVT_XR_SESSION_START_PRE, BKE_CB_EVT_ANNOTATION_PRE, BKE_CB_EVT_ANNOTATION_POST, + BKE_CB_EVT_COMPOSITING_POST, BKE_CB_EVT_TOT, } eCbEvent; diff --git a/source/blender/editors/space_node/node_edit.cc b/source/blender/editors/space_node/node_edit.cc index ab80a44d636..031de50cadf 100644 --- a/source/blender/editors/space_node/node_edit.cc +++ b/source/blender/editors/space_node/node_edit.cc @@ -15,6 +15,7 @@ #include "DNA_text_types.h" #include "DNA_world_types.h" +#include "BKE_callbacks.h" #include "BKE_context.h" #include "BKE_global.h" #include "BKE_image.h" @@ -293,6 +294,15 @@ static void compo_startjob(void *cjv, ntree->progress = nullptr; } +static void compo_endjob(void *cjv) +{ + CompoJob *cj = (CompoJob *)cjv; + Main *bmain = cj->bmain; + Scene *scene = cj->scene; + + BKE_callback_exec_id(bmain, &scene->id, BKE_CB_EVT_COMPOSITING_POST); +} + /** \} */ } // namespace blender::ed::space_node @@ -339,7 +349,7 @@ void ED_node_composite_job(const bContext *C, struct bNodeTree *nodetree, Scene /* setup job */ WM_jobs_customdata_set(wm_job, cj, compo_freejob); WM_jobs_timer(wm_job, 0.1, NC_SCENE | ND_COMPO_RESULT, NC_SCENE | ND_COMPO_RESULT); - WM_jobs_callbacks(wm_job, compo_startjob, compo_initjob, compo_updatejob, nullptr); + WM_jobs_callbacks(wm_job, compo_startjob, compo_initjob, compo_updatejob, compo_endjob); WM_jobs_start(CTX_wm_manager(C), wm_job); } diff --git a/source/blender/python/intern/bpy_app_handlers.c b/source/blender/python/intern/bpy_app_handlers.c index bf427d9639a..9b0b6cbf39e 100644 --- a/source/blender/python/intern/bpy_app_handlers.c +++ b/source/blender/python/intern/bpy_app_handlers.c @@ -66,6 +66,7 @@ static PyStructSequence_Field app_cb_info_fields[] = { {"xr_session_start_pre", "on starting an xr session (before)"}, {"annotation_pre", "on drawing an annotation (before)"}, {"annotation_post", "on drawing an annotation (after)"}, + {"compositing_post", "on compositing background job (after)"}, /* sets the permanent tag */ #define APP_CB_OTHER_FIELDS 1 ``` But the original issue of `ED_node_set_active` (Editor) vs `nodeSetActive` (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 trigger bpy.context.scene.node_tree.nodes["Switch"].check = True and then bpy.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



diff --git a/source/blender/makesrna/intern/rna_nodetree.c b/source/blender/makesrna/intern/rna_nodetree.c
index 841c250df4c..e754444352c 100644
--- a/source/blender/makesrna/intern/rna_nodetree.c
+++ b/source/blender/makesrna/intern/rna_nodetree.c
@@ -1267,6 +1267,13 @@ static void rna_NodeTree_active_node_set(PointerRNA *ptr,
 
   if (node && BLI_findindex(&ntree->nodes, node) != -1) {
     nodeSetActive(ntree, node);
+
+    /* Handle NODE_DO_OUTPUT as well. */
+    if (node->typeinfo->nclass == NODE_CLASS_OUTPUT && node->type != CMP_NODE_OUTPUT_FILE) {
+      node->flag |= NODE_DO_OUTPUT;
+      ntreeSetOutput(ntree);
+      BKE_ntree_update_tag_active_output_changed(ntree);
+    }
   }
   else {
     nodeClearActive(ntree);
@@ -12317,7 +12324,7 @@ static void rna_def_nodetree_nodes_api(BlenderRNA *brna, PropertyRNA *cprop)
       prop, "rna_NodeTree_active_node_get", "rna_NodeTree_active_node_set", NULL, NULL);
   RNA_def_property_flag(prop, PROP_EDITABLE | PROP_NEVER_UNLINK);
   RNA_def_property_ui_text(prop, "Active Node", "Active node in this tree");
-  RNA_def_property_update(prop, NC_SCENE | ND_OB_ACTIVE, NULL);
+  RNA_def_property_update(prop, NC_SCENE | ND_OB_ACTIVE, "rna_NodeTree_update");
 }
 
 static void rna_def_nodetree_link_api(BlenderRNA *brna, PropertyRNA *cprop)

@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:

node_rl = bpy.context.scene.node_tree.nodes["Render Layers"]
node_v = bpy.context.scene.node_tree.nodes["Viewer"]
links = bpy.context.scene.node_tree.links
links.new(node_rl.outputs["Depth"], node_v.inputs["Image"])

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 or active_composite: this might make sense (but is more of a refactor, since internally, there is no such distinction, there is only the NODE_DO_OUTPUTtag (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 tagged NODE_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:

- compositor updating correctly when setting the active viewer from python (no need to manually click or use the workarounds using switch nodes anymore)
- a way to read pixels after compositing finishes using compo handlers

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.

In #54314#1425971, @derekbarker wrote:
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?

import bpy

viewer = bpy.context.scene.node_tree.nodes['Viewer']
switch = bpy.context.scene.node_tree.nodes["Switch"]
switch.check = not switch.check

def my_handler(scene):
    print("composite_post")
bpy.app.handlers.composite_post.append(my_handler)

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.

In #54314#1407769, @lichtwerk wrote:
Soo, we now have:

compositor updating correctly when setting the active viewer from python (no need to manually click or use the workarounds using switch nodes anymore)

Unfortunately, no.
For example, I'm setting active viewer from python like this

#bpy.context.scene.node_tree.nodes.active = v1
bpy.context.scene.node_tree.nodes.active = v2

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.

In #54314#1425971, @derekbarker wrote:
The actual solution is to let users access rendered pixels. Not viewer pixels, clearly there is a lot of us trying to do this.

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.

In #54314#1374603, @cartucho wrote:
T54314_test.blend
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

Yeah, selecting is not enough, you need to set the node active to benefit from 0bc95b7b40

bpy.context.scene.node_tree.nodes.active = node_v2

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.

rl_nodes = [n for n in bpy.data.scenes[scene_name].node_tree.nodes if n.type = 'R_LAYERS' and not n.mute]
for rl in rl_nodes:
    rl.mute = True
render.render()
for rl in rl_nodes:
    rl.mute = False

In #54314#1427891, @3di wrote:
isn't render.render() with the render layer nodes muted the same as a recompose?

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



diff --git a/source/blender/editors/space_node/node_edit.cc b/source/blender/editors/space_node/node_edit.cc
index 3a80733f06c..81d21603fa7 100644
--- a/source/blender/editors/space_node/node_edit.cc
+++ b/source/blender/editors/space_node/node_edit.cc
@@ -1581,6 +1581,27 @@ void NODE_OT_render_changed(wmOperatorType *ot)
   ot->flag = 0;
 }
 
+static int node_composite_exec(bContext *C, wmOperator * /*op*/)
+{
+  Scene *scene = CTX_data_scene(C);
+
+  ED_node_composite_job(C, scene->nodetree, scene);
+
+  return OPERATOR_FINISHED;
+}
+
+void NODE_OT_composite(wmOperatorType *ot)
+{
+  ot->name = "Run Compositor";
+  ot->idname = "NODE_OT_composite";
+  ot->description = "Run current scenes compositor background job";
+
+  ot->exec = node_composite_exec;
+
+  /* flags */
+  ot->flag = 0;
+}
+
 /** \} */
 
 /* -------------------------------------------------------------------- */
diff --git a/source/blender/editors/space_node/node_intern.hh b/source/blender/editors/space_node/node_intern.hh
index 50c03489027..7955a89bb70 100644
--- a/source/blender/editors/space_node/node_intern.hh
+++ b/source/blender/editors/space_node/node_intern.hh
@@ -326,6 +326,7 @@ void NODE_OT_deactivate_viewer(wmOperatorType *ot);
 
 void NODE_OT_read_viewlayers(wmOperatorType *ot);
 void NODE_OT_render_changed(wmOperatorType *ot);
+void NODE_OT_composite(wmOperatorType *ot);
 
 void NODE_OT_output_file_add_socket(wmOperatorType *ot);
 void NODE_OT_output_file_remove_active_socket(wmOperatorType *ot);
diff --git a/source/blender/editors/space_node/node_ops.cc b/source/blender/editors/space_node/node_ops.cc
index 6c52dae5b86..dd14718d3d0 100644
--- a/source/blender/editors/space_node/node_ops.cc
+++ b/source/blender/editors/space_node/node_ops.cc
@@ -70,6 +70,7 @@ void node_operatortypes()
 
   WM_operatortype_append(NODE_OT_read_viewlayers);
   WM_operatortype_append(NODE_OT_render_changed);
+  WM_operatortype_append(NODE_OT_composite);
 
   WM_operatortype_append(NODE_OT_backimage_move);
   WM_operatortype_append(NODE_OT_backimage_zoom);

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

> In #54314#1427891, @3di wrote: > isn't render.render() with the render layer nodes muted the same as a recompose? 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](https://archive.blender.org/developer/P3235.txt) ``` diff --git a/source/blender/editors/space_node/node_edit.cc b/source/blender/editors/space_node/node_edit.cc index 3a80733f06c..81d21603fa7 100644 --- a/source/blender/editors/space_node/node_edit.cc +++ b/source/blender/editors/space_node/node_edit.cc @@ -1581,6 +1581,27 @@ void NODE_OT_render_changed(wmOperatorType *ot) ot->flag = 0; } +static int node_composite_exec(bContext *C, wmOperator * /*op*/) +{ + Scene *scene = CTX_data_scene(C); + + ED_node_composite_job(C, scene->nodetree, scene); + + return OPERATOR_FINISHED; +} + +void NODE_OT_composite(wmOperatorType *ot) +{ + ot->name = "Run Compositor"; + ot->idname = "NODE_OT_composite"; + ot->description = "Run current scenes compositor background job"; + + ot->exec = node_composite_exec; + + /* flags */ + ot->flag = 0; +} + /** \} */ /* -------------------------------------------------------------------- */ diff --git a/source/blender/editors/space_node/node_intern.hh b/source/blender/editors/space_node/node_intern.hh index 50c03489027..7955a89bb70 100644 --- a/source/blender/editors/space_node/node_intern.hh +++ b/source/blender/editors/space_node/node_intern.hh @@ -326,6 +326,7 @@ void NODE_OT_deactivate_viewer(wmOperatorType *ot); void NODE_OT_read_viewlayers(wmOperatorType *ot); void NODE_OT_render_changed(wmOperatorType *ot); +void NODE_OT_composite(wmOperatorType *ot); void NODE_OT_output_file_add_socket(wmOperatorType *ot); void NODE_OT_output_file_remove_active_socket(wmOperatorType *ot); diff --git a/source/blender/editors/space_node/node_ops.cc b/source/blender/editors/space_node/node_ops.cc index 6c52dae5b86..dd14718d3d0 100644 --- a/source/blender/editors/space_node/node_ops.cc +++ b/source/blender/editors/space_node/node_ops.cc @@ -70,6 +70,7 @@ void node_operatortypes() WM_operatortype_append(NODE_OT_read_viewlayers); WM_operatortype_append(NODE_OT_render_changed); + WM_operatortype_append(NODE_OT_composite); WM_operatortype_append(NODE_OT_backimage_move); WM_operatortype_append(NODE_OT_backimage_zoom); ``` With that patch applied, you can do this (no compositor open): [T54314_compo_operator.blend](https://archive.blender.org/developer/F13617908/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 calling render.render('INVOKE_DEFAULT') which returns immediately), so you have to setup events handling,

import bpy
import time

compositeFinished = True
def WaitForCompositeFinished():
    while (not compositeFinished):
        time.sleep(0.1)
def CompositePostHandler(scene):
    print("- CompositePostHandler")
    compositeFinished = True
def CompositeCancelHandler(scene):
    print("- CompositeCancelHandler")
    compositeFinished = True
def RenderPostHandler(scene):
    print("- RenderPostHandler")
    compositeFinished = True
def RenderCompleteHandler(scene):
    print("- RenderCompleteHandler")
    compositeFinished = True
def RenderCancelHandler(scene):
    print("- RenderCancelHandler")
    compositeFinished = True

def ChangeCompositorNodes(outputName):
    socket1 = bpy.context.scene.node_tree.nodes["Render Layers"].outputs[outputName]
    socket2 = bpy.context.scene.node_tree.nodes["Denoise"].inputs["Image"]
    bpy.context.scene.node_tree.links.new(socket1, socket2)

def SaveViewerImageToDisk(filename):
    viewerImage = bpy.data.images["Viewer Node"]
    viewerImage.filepath_raw = filename
    viewerImage.save()

- TESTING
- Expected result: render1.png stores Image data, render2.png stores Normals data
print("Start")
bpy.app.handlers.composite_post.append(CompositePostHandler)
bpy.app.handlers.composite_cancel.append(CompositeCancelHandler)
bpy.app.handlers.render_post.append(RenderPostHandler)
bpy.app.handlers.render_complete.append(RenderCompleteHandler)
bpy.app.handlers.render_cancel.append(RenderCancelHandler)
print("ChangeCompositorNodes to Image rendering")
ChangeCompositorNodes("Image")
print("Rendering")
bpy.ops.render.render(write_still=False)
print("Saving Image1")
SaveViewerImageToDisk("D:*test*render1.png")
print("ChangeCompositorNodes to Normals rendering")
ChangeCompositorNodes("Normal")
- everything works well with rerendering, but it's inefficient
    - print("Rerendering")
    - compositeFinished = False
    - bpy.ops.render.render('INVOKE_DEFAULT', write_still=False)
    - WaitForCompositeFinished()
    - SaveViewerImageToDisk("D:*test*render2.png") # Result: good, render2.png stores Normals
# instead of the commented out way above, try just recomposing without rerendering
print("Recompositing")
compositeFinished = False
bpy.ops.node.composite() # BUG: composite_post() is never called; background job doesn't actually run?
#WaitForCompositeFinished() # waits forever
time.sleep(2.0)
print("Saving Image2")
SaveViewerImageToDisk("D:*test*render2.png") # Result: fail, render2.png is same as render1.png, even though compositor nodes have changed
print("End")
bpy.app.handlers.composite_post.remove(CompositePostHandler)
bpy.app.handlers.composite_cancel.remove(CompositeCancelHandler)
bpy.app.handlers.render_post.remove(RenderPostHandler)
bpy.app.handlers.render_complete.remove(RenderCompleteHandler)
bpy.app.handlers.render_cancel.remove(RenderCancelHandler)

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](https://archive.blender.org/developer/F13862008/TestSwitchingCompositor.blend) The code is long because `bpy.ops.node.composite()` exits immediately (similar to calling `render.render('INVOKE_DEFAULT')` which returns immediately), so you have to setup events handling, ``` import bpy import time compositeFinished = True def WaitForCompositeFinished(): while (not compositeFinished): time.sleep(0.1) def CompositePostHandler(scene): print("- CompositePostHandler") compositeFinished = True def CompositeCancelHandler(scene): print("- CompositeCancelHandler") compositeFinished = True def RenderPostHandler(scene): print("- RenderPostHandler") compositeFinished = True def RenderCompleteHandler(scene): print("- RenderCompleteHandler") compositeFinished = True def RenderCancelHandler(scene): print("- RenderCancelHandler") compositeFinished = True def ChangeCompositorNodes(outputName): socket1 = bpy.context.scene.node_tree.nodes["Render Layers"].outputs[outputName] socket2 = bpy.context.scene.node_tree.nodes["Denoise"].inputs["Image"] bpy.context.scene.node_tree.links.new(socket1, socket2) def SaveViewerImageToDisk(filename): viewerImage = bpy.data.images["Viewer Node"] viewerImage.filepath_raw = filename viewerImage.save() - TESTING - Expected result: render1.png stores Image data, render2.png stores Normals data print("Start") bpy.app.handlers.composite_post.append(CompositePostHandler) bpy.app.handlers.composite_cancel.append(CompositeCancelHandler) bpy.app.handlers.render_post.append(RenderPostHandler) bpy.app.handlers.render_complete.append(RenderCompleteHandler) bpy.app.handlers.render_cancel.append(RenderCancelHandler) print("ChangeCompositorNodes to Image rendering") ChangeCompositorNodes("Image") print("Rendering") bpy.ops.render.render(write_still=False) print("Saving Image1") SaveViewerImageToDisk("D:*test*render1.png") print("ChangeCompositorNodes to Normals rendering") ChangeCompositorNodes("Normal") - everything works well with rerendering, but it's inefficient - print("Rerendering") - compositeFinished = False - bpy.ops.render.render('INVOKE_DEFAULT', write_still=False) - WaitForCompositeFinished() - SaveViewerImageToDisk("D:*test*render2.png") # Result: good, render2.png stores Normals # instead of the commented out way above, try just recomposing without rerendering print("Recompositing") compositeFinished = False bpy.ops.node.composite() # BUG: composite_post() is never called; background job doesn't actually run? #WaitForCompositeFinished() # waits forever time.sleep(2.0) print("Saving Image2") SaveViewerImageToDisk("D:*test*render2.png") # Result: fail, render2.png is same as render1.png, even though compositor nodes have changed print("End") bpy.app.handlers.composite_post.remove(CompositePostHandler) bpy.app.handlers.composite_cancel.remove(CompositeCancelHandler) bpy.app.handlers.render_post.remove(RenderPostHandler) bpy.app.handlers.render_complete.remove(RenderCompleteHandler) bpy.app.handlers.render_cancel.remove(RenderCancelHandler) ```

In #54314#1427891, @3di wrote:
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.

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

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Contents of "Viewer Node" image block do not get updated #54314