From the default scene, I deleted everything but the camera and set the World color to pure black (#000000). When I render the image to PNG, I see about 60% of the pixels are a notch lighter than they should be: #010101.
What’s going on, and how I can tell Blender that when I ask for a background color of pure black, that’s exactly the color I want for every pixel?
I can not reproduce this problem.
Upload your .blend-file so we can check it.
This is likely a color management issue. Blender is producing a 32 bit image. If you set black to black then you are seeing black, but you are likely on filmic mode which is shifting the color space to prevent max black and max white giving you more stops of light in a 8 bit or 16 bit image, like an ari log or red raw file converted to rec709. If you want black to be black then simply change your color space to raw or standard under color management in the render properties. Doing this will cause other problems in your render but will fix your black issue. My suggestion is, render in filmic or filmic log and then in photoshop or gimp match your black point later. Then you keep absolute black but also the additional light stops.
My background is still 0,0,0 black with filmic and default cube and default light.
Thanks to everyone for your suggestions so far, but I’m still getting #010101. I’ve attached a .blend file for you to look at. In this version I changed Render Properties → Color Management → View Transform from Filmic to Raw, but that didn’t help. (Is that the change you meant, @ThorntonStrolia?). Here’s the output file after color equalization:
Up to this point, I have indeed been correcting the black in post-processing, but it’s an annoying extra step to have to take. It would be nice to produce #000000 directly from Blender if possible.
not-black.blend (546.8 KB)
What are you using to measure the #010101? Are you saving 8-bit? With or without alpha?
Save it as 16 bit if it has to be a .png.
Save as .exr would be better.
What are you using to measure the #010101?
Clicking around randomly with GIMP’s eyedropper shows both #000000 and #010101 pixels, but I’ve also used the Netpbm utilities as follows:
$ pngtopnm not-black.png | ppmhist
Summary: 2 colors: 1 black, 0 white, 1 gray, 0 color
r g b lum count
----- ----- ----- ----- -------
1 1 1 1 186805
0 0 0 0 120395
Are you saving 8-bit? With or without alpha?
8 bit. I tried all of BW, RGB, and RGBA.
Save it as 16 bit if it has to be a .png.
That actually works! Thanks, @organic!
But why should 16 bit make a difference? It’s not like #000000 can’t be represented exactly with 8-bit channels.
I have this problem on linux too, does not happen on windows for me.
Version: 2.82a
I have this problem on linux too, does not happen on windows for me.
Version: 2.82a
Interesting. I’m also running 2.82a on Linux (Ubuntu 20.04). I wonder if this is an issue with the underlying PNG library on Linux versus Windows?
You can also right click on the render window. Blender will serve up pixel values with and without colour management, as well as hue saturation luminance and a little swatch.
Couldn’t confirm exactly how it happens, but I would guess either in the conversion from 32-bit float to 8-bit integer, or during compression, there is some rounding. Saving as 16-bit allows more digits after the decimal, so it can use all the zeros to compress and approximate zero. 
It weird, but i guess it has something to do with color profiles, gimp show this issue with the 8bit png.
Krita shows the 8bit png as clear black 0,0,0 but the 16bit png is all one bit off true black.
Tested on linux.
I would look at some of these comments about the issue being on Linux because I can’t replicate the issue in blender on windows but I also haven’t pulled open your specific file yet. I’ll try it when I can get to my computer again
You can also right click on the render window. Blender will serve up pixel values with and without colour management, as well as hue saturation luminance and a little swatch.
I didn’t know that. Nice.
Blender is showing (0.00000, 0.00000, 0.00000) values wherever I click. This is further evidence that the problem is occurring later, most likely during conversion to PNG.
Couldn’t confirm exactly how it happens, but I would guess either in the conversion from 32-bit float to 8-bit integer, or during compression, there is some rounding. Saving as 16-bit allows more digits after the decimal, so it can use all the zeros to compress and approximate zero.
I would hope that Blender is not rounding (0.00000, 0.00000, 0.00000) to (1, 1, 1), even with 8-bit integers!
Krita shows the 8bit png as clear black 0,0,0 but the 16bit png is all one bit off true black.
I haven’t tried Krita myself, but this is indeed weird. I can’t imagine why different programs would report differently the colors in a single PNG file.
I would look at some of these comments about the issue being on Linux because I can’t replicate the issue in blender on windows but I also haven’t pulled open your specific file yet. I’ll try it when I can get to my computer again
Thanks. So far, it does appear to be a Linux vs. Windows issue, probably in the PNG-writing library or Blender’s use of it. I just tried EXR, and both Float (half) and Float (full) produce pure black, as expected.
Approximating zero as one would be a pretty big assumption 
Loading the 8-bit .png back into Blender’s compositor, in places it reads 0.0032, or 0.0039, (and there will be slight differences with Filmic on or off) while the render and 16-bit .png show all zeros.
I tested with Ubuntu 18.04, so that’s further evidence it might be the linux .png libs. Might be worth asking about it on Blender stack exchange. There’s lots of smart folks there -
Or maybe ask on one of the irc channels; #blender-coders, or #blenderchat. There might well be a bug somewhere if the result is different between linux and Windows . . .
Here’s a .blend with an 8-bit png packed in -
PixelValue.blend (1.1 MB)
I wonder what would happen if it was a really small render, say four or nine pixels.
I think I’ll post this as a bug report on developer.blender.org. That ought to get the attention of the right set of people.
The cause is the dither parameter. I checked it on my windows, and it is was at 0.
With 1 i have the same issue on windows.
Confirming that I have the same results on Win10 as reported on Linux.
The factory default for dithering is 1.0. Setting dithering to 0 will result in a single color (0,0,0) when examining the (now much smaller 2.03 KiB) saved PNG 8-bit file.
Confirming that I have the same results on Win10 as reported on Linux.
Thanks for testing that. It makes sense that Win10 and Linux would produce the same results. I don’t know why others have seen different results across the two platforms; I’ll blame gremlins. 
right-click on the “Rendered” icon
select “Reset to Default Value”
this should solve the issue
