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

Open
opened 5 years ago by AmirS · 60 comments
AmirS commented 5 years ago

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.
AmirS commented 5 years ago
Poster

Added subscriber: @AmirS

Added subscriber: @AmirS
AmirS changed title from Unable to update the contents of "Viewer Node" image block to Contents of "Viewer Node" image block do not get updated 5 years ago
AmirS changed title from Contents of "Viewer Node" image block do not get updated to Contents of "Viewer Node" image block do not get updated even with backdrop on 5 years ago
AmirS changed title from Contents of "Viewer Node" image block do not get updated even with backdrop on to Contents of "Viewer Node" image block do not get updated 5 years ago

Added subscriber: @sambler

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.

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 = bpy.context.scene.node_tree.nodes['Viewer'] 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.
Collaborator

Added subscribers: @Jeroen-Bakker, @lichtwerk

Added subscribers: @Jeroen-Bakker, @lichtwerk
lichtwerk self-assigned this 5 years ago
Collaborator

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)

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 ](https://blender.stackexchange.com/questions/102790/how-to-trigger-lmb-click-events-to-activate-a-specific-view-node-and-update-cont) 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)
AmirS commented 5 years ago
Poster

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

@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.
AmirS commented 3 years ago
Poster

@Jeroen-Bakker Does this fix have anything to do with this issue?

@Jeroen-Bakker Does [this fix ](https://developer.blender.org/D5784) 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.

@AmirS No. Just tried with 741d7d60ed90 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.
AmirS commented 3 years ago
Poster

@sambler I haven't tried this in 2.8x. Did you try it with both 2.79x and 2.8x?

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

@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.
AmirS commented 3 years ago
Poster
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
lichtwerk removed their assignment 3 years ago
Collaborator

Since I do not intend to work on this soonish, will step down to not block others from working on this, sorry.

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

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?

@lichtwerk any news regarding this issue?

Added subscriber: @AnSstuff

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

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?
3di commented 2 years ago

Added subscriber: @3di

Added subscriber: @3di
3di commented 2 years ago

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?

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.

If this bug got fixed it would greatly benefit my VisionBlender add-on: https://github.com/Cartucho/vision_blender.

Added subscriber: @kkostovas

Added subscriber: @kkostovas

Added subscriber: @9and3

Added subscriber: @9and3

Are there any updates from this feature request?

Are there any updates from this feature request?

How could we help fix this bug/issue?

How could we help fix this bug/issue?
Collaborator

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?

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?
Owner

This issue was referenced by 16d329da28

This issue was referenced by 16d329da284c20e9dcfc0a60dcfc9b6e213ad3e0
Collaborator

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

Actually, with just the callback and using the method to use Switch nodes, this is already working:
#54314.blend

Actually, with just the callback and using the method to use `Switch` nodes, this is already working: [#54314.blend](https://archive.blender.org/developer/F13124438/T54314.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?

@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?
Collaborator

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?

Regarding setting different viewers active: this will update correctly when setting different viewers active via python: [P2990: Handle NODE_DO_OUTPUT](https://archive.blender.org/developer/P2990.txt) ``` 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](https://archive.blender.org/developer/D15078) applied?
Collaborator

I have committed 16d329da28 to 3.3 now, let me know if you can get it working (with the switch workflow).

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:

image.png

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:
image.png

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.

@lichtwerk I have downloaded 3.3 and tried the following: ![image.png](https://archive.blender.org/developer/F13163720/image.png) 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: ![image.png](https://archive.blender.org/developer/F13163731/image.png) 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.
3di commented 8 months ago

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.

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:
image.png

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.

@lichtwerk [T54314_test.blend](https://archive.blender.org/developer/F13163816/T54314_test.blend) Regarding these other questions: [question1](https:*blender.stackexchange.com/questions/32640/two-viewer-nodes-switch-between-output-images), [question2](https:*blender.stackexchange.com/questions/164386/get-image-pixels-from-multiple-viewer-nodes) This other test does not seem to work, having two viewer nodes and trying to activate one from Python: ![image.png](https://archive.blender.org/developer/F13163822/image.png) 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.
3di commented 8 months ago

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.

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.

@3di yeah, triggering a set/get to activate a viewer by name would be fantastic.
Collaborator

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

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_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](https://archive.blender.org/developer/P2990.txt) 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).
3di commented 8 months ago

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]

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]
Collaborator

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?

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](https://archive.blender.org/developer/D15203) should already bring us across the goalline of this report, no?
3di commented 8 months ago

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

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.

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

This issue was referenced by 0bc95b7b40

This issue was referenced by 0bc95b7b400963eabb261b006f8c4cbb60a0e1fa
Collaborator

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?

Soo, we now have: - - [x] compositor updating correctly when setting the active viewer from python (no need to manually click or use the workarounds using switch nodes anymore) - - [x] 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

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.

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

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)

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

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.

> In #54314#1407769, @lichtwerk wrote: > Soo, we now have: > - - [x] 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.
3di commented 4 months ago

@AnSstuff you could open a compositor from python temporarily before the code and close it again afterwards. Awfully messy, but should work I guess.

@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()

@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()`
3di commented 4 months ago

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.

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#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.
Collaborator

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

> In #54314#1374603, @cartucho wrote: > [T54314_test.blend](https://archive.blender.org/developer/F13163816/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](https://archive.blender.org/developer/F13617784/T54314_test_corrected.blend)
Collaborator

Thx following up btw, checking on launching the compo background job even if the compositor is closed.... (no promises here)

Thx following up btw, checking on launching the compo background job even if the compositor is closed.... (no promises here)
3di commented 4 months ago

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


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
Collaborator

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
Collaborator

regarding the compo operator above: is this something worth pursuing @Jeroen-Bakker ?

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.

> 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

Added subscriber: @cdsousa
Sign in to join this conversation.
No Label
good first issue
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/2.81
legacy project/2.82
legacy project/2.83
legacy project/2.90
legacy project/2.91
legacy project/2.92
legacy project/3.0
legacy project/3.1
legacy project/3.2
legacy project/3.3
legacy project/Alembic
legacy project/Animation & Rigging
legacy project/Asset Browser
legacy project/Asset Browser (Archived)
legacy project/Asset Browser Project Overview
legacy project/Audio
legacy project/Automated Testing
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Blender Asset Bundle
legacy project/Code Quest
legacy project/Collada
legacy project/Compositing
legacy project/Core
legacy project/Cycles
legacy project/Datablocks and Libraries
legacy project/Dependency Graph
legacy project/Development Management
legacy project/Eevee
legacy project/EEVEE & Viewport
legacy project/Freestyle
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/Geometry Nodes
legacy project/Good First Issue
legacy project/GPU / Viewport
legacy project/Grease Pencil
legacy project/GSoC
legacy project/Images & Movies
legacy project/Import/Export
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Line Art
legacy project/Masking
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Modeling
legacy project/Modifiers
legacy project/Motion Tracking
legacy project/Nodes
legacy project/Nodes & Physics
legacy project/OpenGL Error
legacy project/Overrides
legacy project/Papercut
legacy project/Performance
legacy project/Physics
legacy project/Pipeline, Assets & I/O
legacy project/Platform: FreeBSD
legacy project/Platform: Linux
legacy project/Platform: macOS
legacy project/Platforms, Builds, Tests & Devices
legacy project/Platform: Windows
legacy project/Pose Library Basics
legacy project/Python API
legacy project/Render & Cycles
legacy project/Render Pipeline
legacy project/Retrospective
legacy project/Sculpt, Paint & Texture
legacy project/Text Editor
legacy project/Tracker Curfew
legacy project/Translations
legacy project/Triaging
legacy project/Undo
legacy project/USD
legacy project/User Interface
legacy project/UV Editing
legacy project/VFX & Video
legacy project/Video Sequencer
legacy project/Virtual Reality
legacy project/Wintab High Frequency
migration/requires-manual-verification
Module › Animation & Rigging
Module › Core
Module › Development Management
Module › Eevee & Viewport
Module › EEVEE & Viewport
Module › Grease Pencil
Module › Modeling
Module › Nodes & Physics
Module › Pipeline, Assets & IO
Module › Platforms, Builds Tests & Devices
Module › Platforms, Builds, Tests & Devices
Module › Python API
Module › Render & Cycles
Module › Sculpt, Paint & Texture
Module › Triaging
Module › User Interface
Module › VFX & Video
papercut
performance
Priority › High
Priority › Low
Priority › Normal
Priority › Unbreak Now!
Status › Archived
Status › Confirmed
Status › Duplicate
Status › Needs Information 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…
There is no content yet.