Seems a regression so raising the priority.

This sounds like the same problem as in T100061

Tried to bisect between 52a5f6856268 - e5a738af6d51 and pointed me to rB8399375098fa: Cleanup: Reword comment, rename variables (I don't think this commit is responsible)

Naa, that's because it's a transmissive surface so is getting less diffuse samples. Check the black pip on the lemon, and also the black parts of the wood texture. Not even the slightest introduction of texture colour/value or noise on the light passes.

You can see the same effect in Redshift (but more subtle), the darker areas of the texture are more noisy. That's the result of importance sampling and Russian roulette allocating fewer samples to such dark areas.

even when the darkest brick texture component is set to a dark gray, it's still introducing the contamination:

just checked and non blacks are also causing contamination:

Oh, are you saying that only completely black pixels in the colour pass lead to contamination of the direct and indirect lighting passes?

Ok, maybe the example from that documentation was not ideal since it seemingly has no black pixels in the diffuse filter AOV (besides the background), only near black. Or perhaps the hack is to add a tiny bit off diffuse to everything even when the texture is black.

The image shows that the black areas of the textures aren't affecting the diffuse lighting passes. I have verified it's true, I wrote a multipass denoiser for redshift in houdini a few years ago.

Either way, this behavior is very unlikely to change in Cycles, so not really worth discussing.

That sentence doesn't say anything about black elements in the texture, I guess you are assuming they can be replaced in other renderers without having actually verified if that's true.

Thanks. This image explains better: https://docs.redshift3d.com/display/RSDOCS/Integrated+AOVs#IntegratedAOVs-DiffuseLighting:~:text=set%20to%200-,Raw,-Shading%20Elements

I don't think it's practical, it probably requires deep compositing and conflicts with OSL design of optimizing out zero weight closures.

Even Alex Honnold uses ropes when he thinks it might get windy.

Thanks. Might it be possible to make this optimisation optional? For large animations rendering a bit slower is a good trade-off if it means you can potentially avoid rendering twice.

Supporting texture replacement is not a goal of the render passes implementation. The design choice was to optimize render times as much as possible, which means not computing lighting for cases where the texture is black.

Could you provide a simple .blend file showing the problem?

ignore, I realise even if the background was set to white, the white pixels would be baked into the edge of the object if the edge of the object was dark.

Thanks for the report, but the reason for the crash wasn't clear, so I edited the report for the developers to more easily identify the cause.

Since it was caused by rB5baa3ecda663: Color Management: various improvements and fixes for image saving, @Brecht Van Lommel (brecht), does this ring a bell?

This causes Eevee background renders to crash, I'll quickly commit a fix since the studio here is relying on Eevee for the Project Heist.

Yes, the headless builds don't have an OpenGL context. This could be supported but it's currently not the case.

Does this means headless builds are now unable to create a GL context? IIRC some implementation of EGL allows this. But if headless builds mean no GPU backend, so be it.

Trying to render out images for a website, where the image needs to be separate from the background and can't use an Add blend mode.

After sharing this link to our conversation

I am just saying that this memory is not only allocated for rendering, but also for other things that Blender does, so it is not entirely unreasonable that the visibility of objects in the view layer might have an effect this. I would just wait for a more informed answer on devtalk.