I found out that the default PNG(ZIP) encoding options do not offer
the best performance and output sizes. At least for "vector" images
like street maps.
I changed the options of deflateInit2 in ZipEncode.c and tested the
performance of Z_FILTERED, Z_DEFAULT_STRATEGY, Z_HUFFMAN_ONLY and
Z_RLE and I tested different compression levels for some of the
I found out that Z_RLE offers the best performance while offering good
compression, at least for my test image.
I tested with timeit.
t = timeit.Timer("img.save('/dev/null', 'png')",
"import Image; img = Image.open('test.png')")
print name, min(t.repeat(3, 10)),
Here are my raw results, together with the resulting file size.
default0 is the Z_DEFAULT_STRATEGY with compression level 0, etc.
I really would like to have more options in Image.save to choose
different compression levels/strategies. I would like to add that to
PIL and have some questions on how to add that.
At the moment save for PNG accepts only the `optimize` option which
enables the best/slowest compression level (9). I think it would be
bad for backwards compatibility to use this option to set the actual
compression level. What about compress_level and compress_type for the
options? I would add constants for the types in Image.py.
Any opinions or suggestions on that? I would do a fork on bitbucket
then and start hacking.
On Fri, Mar 5, 2010 at 11:23 AM, Oliver Tonnhofer <[hidden email]> wrote:
> On 04.03.2010, at 14:31, Oliver Tonnhofer wrote:
>> Any opinions or suggestions on that? I would do a fork on bitbucket then
>> and start hacking.
> Ok, I just started :)
> I added compress_level and compress_type as save options for png files. The
> default behaviour is identical to 1.1.7.
> Anyone care to review?
Thanks. I'll take a look when I find the time (and borrow the code if
that's fine with you).
> I load the ZLIB constants (Z_RLE, etc) into the _imaging module and then
> into Image. I'm not sure if that's OK, or if I should create some new
> constant values.
> I did not prefix the constants, but maybe it is time to start with it.
> BILINEAR, RLE, FLOYDSTEINBERG, ADAPTIVE, ... it's getting a bit confusing.
Well, they all have the "Image." prefix :)
Not sure somewhat specialized encoder-specific settings should live in
that namespace, though; might be better to put them in the codec
module itself. I'll think of something.