28
$\begingroup$

I was most surprised to find that the compression setting in the render settings, made a huge difference in the file size of a png. Is there any image quality degradation with the compression on? compression setting in the render output settings
What does blender do to the png if the compression is at 100%, as apposed to 0%?

$\endgroup$
7
  • $\begingroup$ I know that PNG is lossless, so you don't have to worry about compression artifacts. ;D If you compressing JPEG yo, it will have almost like a color bleed and some freakish squariness. $\endgroup$
    – ruckus
    Dec 22, 2016 at 2:05
  • 1
    $\begingroup$ @Ward I know that, but what is going on then? $\endgroup$
    – David
    Dec 22, 2016 at 2:08
  • $\begingroup$ Heck if I know. I can see how this can be blender related, but it really isn't a blender question. Maybe another network had an answer. $\endgroup$
    – ruckus
    Dec 22, 2016 at 2:11
  • $\begingroup$ You can also run exported images through a tool like ImageOptim to likely get even more optimization. I use this for assets I'll be putting online or in the applications I work on (I'm a software dev) because a smaller file size means they'll load more quickly into the application. $\endgroup$ Dec 22, 2016 at 11:34
  • 1
    $\begingroup$ @TobiasKienzler The size of the file has a general tendency to dominate load time because of the speed of disc access. Also, decompression times are not that much worse for heavily optimized files. The compression/decompression process for PNGs is intentionally asymmetric. The highly compressed files aren't necessarily harder to decompress because the algorithm is the same, they are simply a more ideal file that took more time to find in the first place during compression. $\endgroup$
    – Cort Ammon
    Dec 22, 2016 at 20:03

1 Answer 1

39
$\begingroup$

No, the compression slider does not affect the image quality.
PNG uses a lossless compression algorithm called DEFLATE (among some other things), which is the same as is used to produce .zip files.

Long story short, the only difference between PNG files with 0% and 100% compression is the CPU time it takes to perform the compression (and of course the resulting file size).

Some tests:

Saving a 1920x1080 render of the default cube:

0% compression:
0.66 seconds, 8116 kilobytes (8 megabytes)
Zipping an uncompressed png produced a 48 kilobyte file.
100% compression:
0.86 seconds, 36 kilobytes

That's a compression ratio of 225 (!) and a time difference of .2 seconds.

Saving a pure high-frequency noise image (also 1920x1080):

0% compression:
.9 seconds, 8116 kilobytes (8 megabytes)
Zipping an uncompressed png produced a 5496 kilobyte file.
100% compression:
2.01 seconds, 5108 kilobytes (5 megabytes)

That's a compression ratio of 1.58 and a time difference of 1.11 seconds.

All tests were conducted with blender and compression times measured from the "saving" time printed to stdout and averaged over five samples.

As you can see, more uniform images (like the grey flatness of an empty blender scene) are much more compressible than highly variable images (such as pure RGB noise). The time it takes to perform the compression isn't very significant even in a worst-case scenario, however that 1 extra second could add up when rendering an animation.

$\endgroup$
6
  • 2
    $\begingroup$ so does that mean it would take a little longer to render out to a png with compression? (probably talking a very small difference.) $\endgroup$
    – David
    Dec 22, 2016 at 2:14
  • $\begingroup$ @David Doing some tests now; we'll see exactly how insignificant ;) $\endgroup$
    – gandalf3
    Dec 22, 2016 at 2:15
  • 1
    $\begingroup$ Awesome answer, I learned a few things :) $\endgroup$
    – J Sargent
    Dec 22, 2016 at 4:04
  • 1
    $\begingroup$ Also while a second does not sound like much it can be a killer in a rendering where you get the data out form a very fast render like a opengl dump. Now your results are allmost entirely dependent on how fast you can dump the data to disk. $\endgroup$
    – joojaa
    Dec 22, 2016 at 9:53
  • $\begingroup$ @gandalf3 Does Blender use threads for writing the image when rendering an animation? I.e., assuming you're using the cpu for rendering if you have 8 cores one of them could be writing the file while the others are rendering, and as soon as it's done saving the image then that core would start rendering. $\endgroup$
    – lumpynose
    Dec 27, 2016 at 18:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .