Attached PNG loads as solid-black square

[ssokolow]

With this PNG file...

...this code displays a black square:

from PIL import Image
im = Image.open('logo.png')
im.show()

...as a result, this code which depends on Pillow also produces a black square:

from escpos import printer
usblp = printer.Usb(0x0416, 0x5011)
usblp.image("logo.png")
usblp.cut()

I almost filed a bug with python-escpos because Pillow failed silently rather than either working or raising an exception.

[wiredfool]

It's not picking up the transparency or alpha channel, with debugging on:

>>> im = Image.open('../Pillow/Tests/images/p_trns_single.png') # test transparent image
STREAM IHDR 16 13
STREAM PLTE 41 768
STREAM tRNS 821 165
STREAM IDAT 998 928
>>> im = Image.open('b1178e42-dfce-11e3-94f3-fc1395ecb7a8.png')
STREAM IHDR 16 13
STREAM sRGB 41 1
sRGB 41 1 (unknown)
STREAM IDAT 54 682
>>> 

Imagemagick is picking up the correct values, but I'm seeing conflicting info for the alpha channel. Going to have to dig a bit further into the image to see what the unknown chunk is.

[d-schmidt]

Looks like we don't properly convert the color type: http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.IHDR
The color type is 4 for this image and that means we have a grayscale byte followed by an alpha byte for every pixel. We don't have a test for this color type yet.

For the unknown chunk, there are 8 bytes of data following the SRGB chunk which are not supposed to be there: http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.sRGB

[CounterPillow]

Is there a specific reason for Pillow not using libpng?

Note that this is not the only PNG related problem. More than 1 bit of transparency in indexed PNG images also fail to read and write (PIL/low is actually the only imaging library I've ever encountered that even fails reading them!), sRGB and UTF-8 text chunks (iTXt) are not supported, etc. etc.

Code quality is also questionable, with gems such as

if transparency or transparency == 0:

instead of

if transparency != None:

and variable naming conventions that use len as a variable name, among general FIXME-sprinkles and half-arsed implementations that fail to follow the specification at times.

[d-schmidt]

Pillow is still full of old junk but steadily improving. We just revived it.

if transparency or transparency == 0:

Is there for a reason, it does prevent empty lists and bytes.

if transparency != None:

Would cause bugs, you would have to check

if ((isinstance(transparency, bytes) or isinstance(transparency, list)) and len(transparency) > 0) or transparency == 0 :

I don't know why Pillow just uses zlib and not libpng to reduce some hassle. @CounterPillow do you have time to implement it?

[d-schmidt]

@CounterPillow please provide an example for

More than 1 bit of transparency in indexed PNG images also fail to read and write

[CounterPillow]

Apologies, I have just noticed that the palette problems seem to have recently been fixed (#544 I think).

However, the point I was trying to make with my comment is that using libpng is probably the less painful option in the long run.

[d-schmidt]

I think most of us can agree with that, but it is still going to be a lot of work somebody would have to do to implement it initially.

[hugovk]

Closing this as there's been no updates in 5 years. PRs are welcome to improve library support.