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.

Looks like this is caused by adding a vanilla "Viewport" viewlayer and making it the first in the list here
(special case in do_version_layers_to_collections() if there are layer overrides...)

/* Make it first in the list. */
BLI_remlink(&scene->view_layers, view_layer);
BLI_addhead(&scene->view_layers, view_layer);

Nice tests @Malte S (pandrodor), i also had issues with Albedo pass being in the wrong range for some objects in my scenes and they turned white , I used the same fix as you did but isn't the Mix node unnecessary? I got same results with just the Greater Than node and the Color Subtract.

OIDN does work with Animations and it also works with high sample renders. The bug I showed earlier was rendered with just 4 samples just to make the point very clear.
This setup is a simple fix for the wrong “Denoising Albedo” pass:

In D4304#98312, @derek barker (lordodin) wrote:

Ive been testing with denoising the light passes instead of the images and it does a significantly better job keeping the texture data.

In D4304#98317, @Ludvik Koutny (rawalanche) wrote:

In D4304#98312, @derek barker (lordodin) wrote:

Ive been testing with denoising the light passes instead of the images and it does a significantly better job keeping the texture data.

Look two posts above. There's a bug that causes textures to get too blurry.

In D4304#98312, @derek barker (lordodin) wrote:

Ive been testing with denoising the light passes instead of the images and it does a significantly better job keeping the texture data.

In defense of the built-in Cycles denoiser, one needs to take into account the fact that it produces markedly better results on a noticeably noisy image when Branched Path Tracing is used instead of normal Path Tracing (especially in areas like highlights and reflections). There have also been improvements in recent 2.8 builds as indicated by the pass data.

Ive been testing with denoising the light passes instead of the images and it does a significantly better job keeping the texture data.

Yes I checked out in 2.8;. It is still an issue. Eyedropper cannot sample from second MONITOR. Returns always black.

Can you attach a simple .blend with that setup? Don't forget to pack the image.

I tired this on a Theory Studios build and it is amazing!

I think I found a Bug in the current Implementation.
The Denoising Albedo pass contains the Texture data in the value range from 1-2, resulting in blurry textures.
If I manually subtract 1 for every channel, the Image is much sharper.
However, it appears that metal colors are stored in the range of 0-1, just subtracting by one may not be the final solution.
Here is an example render with 4 Samples:

Is this still an issue with 2.8? https://builder.blender.org/download/

Luxcore team is experimenting the integration with Intel OIDN. Keep in mind their previous Bayesian denoiser was overblurring everything (and was much inferior compared to Cycles one), though the test shows the OIDN could do well with higher samplecounts too.

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

Here some comparisons at higher sample counts, with hair, SSS, depth of field and motion blur.
11_01_A.lighting.flamenco, 50% resolution, 1024 AA samples.

Could you please also post 256 sample results, or something like that? It will be much better at showing how inferior Cycles denoiser is to OIDN :)

Here some comparisons at higher sample counts, with hair, SSS, depth of field and motion blur.
11_01_A.lighting.flamenco, 50% resolution, 1024 AA samples.

One thing no one is bringing up is the built in cycles denoiser isn't worth turning on half the time because the amount of time and overhead it adds you can do twice as many samples. We had a 4k render recently take over a minute longer with the denoiser on vs 4x the samples.

You need to be careful when looking at test posted in various forums - naturally, OIDN shows a big quality difference between with and without normal/albedo passes. The HDR option also makes a significant difference, when it's turned off it is much more aggressive at blurring bright areas.

Regarding integrating the Cycles denoiser into the Compositor node: I'm not sure how we would implement that - the animation denoiser patch adds support for standalone denoising, but we'd still need to call that from Blender somehow, and adding a function to the Renderer API specifically for that seems far from ideal as well.

Right, the comparisons in that thread show that OpenImageDenoise is better at low sample counts and that makes it valuable.

Please check this thread with several tests, expand the post to show the comparisons. Other test and video are submitted across the topic.

• Fixed code style.
• Cleanup in denoiser compositing node.

It's the job of the developer submitting the new code or the users to demonstrate the new denoiser is better, not the other way around. So I would love to see some test renders with this patch.