Compress PNG files better #4
Description
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 goo...@web.dwdw.me on 12 Feb 2012 at 2:50
Attachments:
