Am Montag, den 27.07.2009, 17:52 +0400 schrieb Alexey Borzenkov: > Hi again, > > I found what was the real problem with Z_NO_FLUSH. The code was only > checking that it ran out of output buffer, but when it does it can > usually mean that not all input was deflated. However, when it enters > ZipEncode next time, the data that was not deflated in the previous > round is forgotten and discarded (by overwriting next_in), thus it was > making holes in dicompressed data, which turned into corrupt png > images. The following patch (I hope) fixes it properly: > I never got corrupt images, but I applied the attached patch anyway.
It seems to work and I hope this will go upstream. Thanks Flynn P.S.: There is another size bloating feature in PIL: all palettes are stored full size (usually 256 entries) instead only storing the real used colors. This especially is a problem with pictures with only a few colors, where then the palette is much bigger than the compressed data. Do you see any chance to fix this? I took alook, but it seems not so easy. _______________________________________________ Image-SIG maillist - Image-SIG@python.org http://mail.python.org/mailman/listinfo/image-sig
