Compress PNG files better

[GoogleCodeExporter]

Currently, when saving the output as PNG, the output file is quite large, 
seemingly larger than necessary.  For instance, ImageMagick can compress it 6x 
better than OpenCV.

Example:
$ python straightener.py test5.png
$ ls -l test5-unrotated.png
-rw-r--r--. 1 daw daw 5767409 Feb 11 18:31 test5-unrotated.png
$ convert -quality 50 test5-unrotated.png test5-unrotated-IM.png
$ ls -l test5-unrotated-IM.png 
-rw-r--r--. 1 daw daw 948592 Feb 11 18:32 test5-unrotated-IM.png

A plausible enhancement would be to pass appropriate options to OpenCV to get 
it to save the file more efficiently.  This may improve performance, because 
not as much data has to be written to disk.

However, this may not be so easy to implement, and it seems low priority.  I'm 
reporting this here only for future reference, in case we ever want to re-visit 
it in the future.

It looks like the main source of difference in file size between OpenCV and 
ImageMagick (at least in this case) is that OpenCV writes the file as color, 
whereas ImageMagick automatically detects that the image can be written as 
grayscale without loss of fidelity.  This seems to significantly shrink the 
output file.  It's plausible that one could write extra code to check for this 
case and then instruct OpenCV to write as grayscale if that wouldn't coss any 
loss of fidelity, but this would take additional work and may not be worth the 
effort.

I also checked whether differing compression levels might be responsible for 
this, but I don't think it is relevant.  (ImageMagick "-quality 50" seems a 
reasonable tradeoff; this corresponds to compression level 5 and no filtering.  
But setting aside the grayscale optimization, compression level doesn't make 
much difference for this example image.)  More recent versions of OpenCV may 
provide a way to control the compression level, e.g., along the following lines:

-     cv.SaveImage(outName, img)
+     cv.SaveImage(outName, img, [cv.CV_IMWRITE_PNG_COMPRESSION, 5, 0])

But this isn't supported in current OpenCV.  And in any case, the compression 
level doesn't seem to be the cause of the large output files, so this is moot 
anyway.

Original issue reported on code.google.com by [email protected] on 12 Feb 2012 at 2:50

Attachments:

• test5.png

[GoogleCodeExporter]

This is actually somewhat important when we use this with OpenCount: the 
bottleneck in several stages is disk IO time, and a 2x increase in image file 
size results in a 2x decrease in performance.

Original comment by [email protected] on 26 Mar 2013 at 7:17

• Added labels: ****
• Removed labels: ****