Feature #11695

Make PNG compression level configurable

Added by Simon Raffeiner almost 2 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:


Affected Version:
git master branch
hardware architecture:


When exporting to PNG format, the PNG compression step can take several times longer than the processing of the image itself, depending on the hardware setup. This is caused by darktable instructing libpng to use the Z_BEST_COMPRESSION level, which is equal to compression level 9. Level 9 doesn't result in much smaller output files than level 5, but needs much more CPU cycles. libpng uses libz to do the actual compression, which only runs in a single-threaded fashion, making the issue even worse.

My PC has a six-core AMD Ryzen CPU and a NVIDIA GTX 950 GPU, and I have enabled both OpenMP and OpenCL. If I activate darktable's internal profiling, I can see that a typical Nikon D750 RAW image with my usual settings is processed in less than a second, but then the CPU spends another ten seconds compressing the output on a single core. If I set the compression level to 5 instead, the same system easily processes and exports a single picture in two seconds.

The attached patch adds a "Compression" slider to the PNG imageio module user interface, making the compression level configurable, and sets the default compression level to 5.

darktable-png-compression-level.patch Magnifier (6.13 KB) Simon Raffeiner, 08/15/2017 03:00 PM

Associated revisions

Revision 860def4e
Added by Simon Raffeiner almost 2 years ago

Make PNG compression level configurable

Fixes #11695.


#1 Updated by Tobias Ellinghaus almost 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

I think that's a good idea to have. I'll clean up the patch (you forgot to bump module version and didn't deal with legacy params) and push then.

#2 Updated by Tobias Ellinghaus almost 2 years ago

Oh, how shall I attribute you in the commit log? As "Simon Raffeiner" and the email address used here in the bug tracker?

#3 Updated by Simon Raffeiner almost 2 years ago

Thanks! I didn't know how to handle the module versioning stuff, but I thought a working patch for the feature itself would speed things up, so I attached it. Next time I hopefully know what additional stuff to look for.

Please credit me as Simon Raffeiner <>, yes.

#4 Updated by Tobias Ellinghaus almost 2 years ago

  • Status changed from In Progress to Fixed
  • % Done changed from 50 to 100

Thanks, pushed to master. And don't worry about me fixing your stuff, that allowed me to find and fix some unrelated bug at the same time. :-)

#5 Updated by Roman Lebedev almost 2 years ago

  • Target version set to 2.4.0

Also available in: Atom PDF