We haven't agreed on an exact UI design for this yet, it's not really ready to be picked up by someone.

Is this open to be worked on? If so, a few questions since I'm somewhat new to the code base:

1. Should I disable the output panel output path, and how do I do this?
2. Where is the code that writes image output?
3. Where would I actually place the code that implements this issue?

I'm attaching .blend as requested. One thing to note is output node setup is as follows when exr's were rendered.

If I render with a multilayer EXR file Output Node from blender I get those "bad" results if I add an Input to the node called Alpha, but leave this unconnected

Rings some bell but not sure.

Hm, I'm getting this trying to import the file in Krita:

Ignore my previous comment. I'm not sure what's going on here either Affinity Photo and LuminanceHDR both have broken OpenEXR implementation or Blender creates file that don't follow the spec. Affinity Photo can open the files and reads both RGB layer and alpha, but fails to save the data on export resulting in a blank alpha. LuminanceHDR complains that it can't find RGB data and refuses to load the file altogether. This happens for both your supposedly broken file and .exr files that can be properly read in Blender.

It remains true for some renders done using 2.8.
It's not same in all cases but it's random
Let me know if you need more data to debug.

I've got the same result in 2.79 and the current master build. Both show the broken result. Since loading your .exr file in an external image editing application and saving it as .hdr or .exr doesn't fix it, seems like the alpha hasn't been properly tagged in the file.

Glad that it is now working for you.

Yes, it seems to be fixed now. I tried the frames in this build:

The issue is that the pictures that doesn't render contains pixels that have a glitched pixels (pixels that have a very high value).

Actually, i think it is now fixed by rBfaf48c0f6473.

@Sergey Sharybin (sergey), this bug is still happening after rBb432209f63f8: Render: Use dependency graph for compositor/sequencer.

Sebastian, no, they aren't. They are EXR multi-layer files, and they have source image in 'Render layer', and a pitch-black result in 'Composite' layer. In the image node there is a switch, where you can choose the 'Render layer' to see the image. By default, when you open a new file in the node it selects 'Composite' layer, which is wrong, so just select 'Render layer' in the combobox below.
Thank you for your attention.

This will be for 2.81.

Will this branch make it into stable 2.80? Is there anything else that needs to be done - maybe I could help?

Since I wouldnt know how to proceed with this, stepping down...

The bad files you have attached are pitch black, so I'm unsure what there is to reproduce here.

• Merge 'master' into 'openimagedenoise'
• Merge 'master' into 'openimagedenoise'
• Merge 'master' into 'openimagedenoise'

I can't get this branch to compile properly. At the end of compilation, I get the following errors (there are more, but these are the first):

• Added support for debug versions of OpenImageDenoise Windows DLLs.

• Compositor: More fixes for OIDN build on Windows.

• Merge remote-tracking branch 'origin' into openimagedenoise
• Merge branch 'master' of git.blender.org:blender into openimagedenoise
• Fixed padding for OIDN node.
• build_environemnt: Updated OpenImageDenoise to static 0.8.2
• build_environment: OpenImageDenoise fixes for Linux and Windows.
• build_environment: Fixed FindOpenImageDenoise.cmake.
• build_environment: Fixed Windows build with static OpenImageDenoise.

@Stefan Werner (swerner) Intel said that they just uploaded 0.8.2 with that you said fixed!

Archiving this issue as it is not a bug. Questions and possible future improvements etc should go to the proper channels.

That is quite interesting results, and clearly there is a niche where OIDN clearly shines. (probably, i was testing it on too complex or too simple file).
SO me being skeptical in the beginning is more like feeling that is something useful to have. Probably, also as an option for Cycles itself.

There are artifacts with the default settings as corner pinning uses EWA filtering. At this moment we don't have the capability to configure what filtering to use. EWA filtering is selected as it gives better result in normal use cases.

Hi Troy, sorry for the late reply.

FYI, I'm waiting for Intel to release the next version of OIDN that can build as a static library.

In D4304#100572, @Marco G (marcog) wrote:

In D4304#99513, @Stefan Werner (swerner) wrote:

What are you doing to get Albedo > 1? I didn't see that happen in my test scenes. Adding clamping to the albedo input will be easy though.

Hi @Stefan Werner (swerner)
I figured out in my tests, the Albedo > 1 appears when a material (Pricipled BSDF), has Specular > 1.
If you look here, first image shows the brown material with Specular = 0.0, second image has same settings but a slight Specular value was added (about 0.1 or so)
When adding Specular, Albedo denoise pass goes above 1.0, thus resulting in pure white and then not preserving details in case a textured material is used.

Seems like it is going over all RenderLayer nodes and renders the corresponding scene no matter if has been rendered already...

In D4304#99513, @Stefan Werner (swerner) wrote:

What are you doing to get Albedo > 1? I didn't see that happen in my test scenes. Adding clamping to the albedo input will be easy though.

What are you doing to get Albedo > 1? I didn't see that happen in my test scenes. Adding clamping to the albedo input will be easy though.

Backtrace:

Thread 1 "blender" received signal SIGSEGV, Segmentation fault.
0x0000555556bbeba8 in DEG::Depsgraph::check_nodes_connected (this=0x7fffe4fbcb08, from=0x0, to=0x7fffcd67df08, description=0x555557d1e438 "Animation -> Prop")
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/depsgraph.cc:211
211		for (Relation *rel : from->outlinks) {
(gdb) bt
#0  0x0000555556bbeba8 in DEG::Depsgraph::check_nodes_connected (this=0x7fffe4fbcb08, from=0x0, to=0x7fffcd67df08,
    description=0x555557d1e438 "Animation -> Prop") at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/depsgraph.cc:211
#1  0x0000555556bbef5d in DEG::Depsgraph::add_new_relation (this=<optimized out>, from=from@entry=0x0, to=to@entry=0x7fffcd67df08,
    description=description@entry=0x555557d1e438 "Animation -> Prop", flags=flags@entry=32)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/depsgraph.cc:183
#2  0x0000555556bcc094 in DEG::DepsgraphRelationBuilder::build_animdata_curves_targets (this=this@entry=0x7fffffffd9d0, id=id@entry=0x7fffcf14c408,
    adt_key=..., operation_from=operation_from@entry=0x0, curves=<optimized out>)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/builder/deg_builder_relations.cc:1287
#3  0x0000555556bcd323 in DEG::DepsgraphRelationBuilder::build_animdata_curves (this=this@entry=0x7fffffffd9d0, id=id@entry=0x7fffcf14c408)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/builder/deg_builder_relations.cc:1240
#4  0x0000555556bcdd0c in DEG::DepsgraphRelationBuilder::build_animdata (this=this@entry=0x7fffffffd9d0, id=id@entry=0x7fffcf14c408)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/builder/deg_builder_relations.cc:1206
#5  0x0000555556bce528 in DEG::DepsgraphRelationBuilder::build_nodetree (this=this@entry=0x7fffffffd9d0, ntree=0x7fffcf14c408)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/builder/deg_builder_relations.cc:2323
#6  0x0000555556bd05bc in DEG::DepsgraphRelationBuilder::build_compositor (this=this@entry=0x7fffffffd9d0, scene=scene@entry=0x7fffcf323008)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/builder/deg_builder_relations.cc:2427
#7  0x0000555556bd3a12 in DEG::DepsgraphRelationBuilder::build_view_layer (this=this@entry=0x7fffffffd9d0, scene=scene@entry=0x7fffcf323008,
    view_layer=view_layer@entry=0x7fffccf88908)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/builder/deg_builder_relations_view_layer.cc:114
#8  0x0000555556bbf360 in DEG_graph_build_from_view_layer (graph=0x7fffe4fbcb08, bmain=0x7fffcf6eaa08, scene=0x7fffcf323008, view_layer=0x7fffccf88908)
    at /home/zed/programmering/blender_master/blender/source/blender/depsgraph/intern/depsgraph_build.cc:264
#9  0x000055555696b9d1 in BKE_scene_graph_update_tagged (depsgraph=depsgraph@entry=0x7fffe4fbcb08, bmain=bmain@entry=0x7fffcf6eaa08)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/scene.c:1487
#10 0x000055555610e478 in wm_event_do_depsgraph (C=C@entry=0x7fffea058108)
    at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_event_system.c:341
#11 0x000055555610e515 in wm_event_do_refresh_wm_and_depsgraph (C=C@entry=0x7fffea058108)
    at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_event_system.c:366
#12 0x0000555556114d5a in wm_event_do_notifiers (C=C@entry=0x7fffea058108)
    at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_event_system.c:524
#13 0x000055555610ad88 in WM_main (C=0x7fffea058108) at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm.c:421
#14 0x00005555560f58e3 in main (argc=1, argv=0x7fffffffdd28) at /home/zed/programmering/blender_master/blender/source/creator/creator.c:505

Sure. It would appear as though it occurs with Image Sequences, in particular. I've included a packed .blend file with a simple node set-up to demo the crash. Just change one or all of the Image nodes to Image Sequence and add a keyframe to Fac on the third Alpha Over node. It'll crash.

I can't reproduce this on my end.