Converting transparent GIF to PNG can lead to further processing errors

[xaralis]

When converting transparent GIF (https://dl.dropboxusercontent.com/u/35354297/test2.gif) to PNG using following statement:

from PIL import Image
Image.open(self.image).save('somefile.png', 'PNG')

It then fails when you try to do some thumbnailing etc. with following traceback:

Traceback (most recent call last):
  File "/Users/xaralis/Workspace/adventura/adv/app/models/photos.py", line 54, in get_thumbnail_in_format
    return get_thumbnail(img, **f['opts'])
  File "/Users/xaralis/.virtualenvs/adventura/src/sorl-thumbnail/sorl/thumbnail/shortcuts.py", line 8, in get_thumbnail
    return default.backend.get_thumbnail(file_, geometry_string, **options)
  File "/Users/xaralis/.virtualenvs/adventura/src/sorl-thumbnail/sorl/thumbnail/base.py", line 118, in get_thumbnail
    thumbnail)
  File "/Users/xaralis/.virtualenvs/adventura/src/sorl-thumbnail/sorl/thumbnail/base.py", line 151, in _create_thumbnail
    default.engine.write(image, options, thumbnail)
  File "/Users/xaralis/.virtualenvs/adventura/src/sorl-thumbnail/sorl/thumbnail/engines/base.py", line 142, in write
    progressive=progressive
  File "/Users/xaralis/.virtualenvs/adventura/src/sorl-thumbnail/sorl/thumbnail/engines/pil_engine.py", line 227, in _get_raw_data
    image.save(bf, **params)
  File "/Users/xaralis/.virtualenvs/adventura/lib/python2.7/site-packages/PIL/Image.py", line 1468, in save
    save_handler(self, fp, filename)
  File "/Users/xaralis/.virtualenvs/adventura/lib/python2.7/site-packages/PIL/PngImagePlugin.py", line 584, in _save
    raise IOError("cannot use transparency for this mode")
IOError: cannot use transparency for this mode

The reason for this is that transparency information is kept in im.encoderinfo even though it's already in RGBA mode.

I was able to successfully avoid the problem by converting the mode manually like this:

Image.open(self.image)
im = orig_im.convert('RGBA')
im.save('somefile.png', 'PNG')

But I believe something like this should be handled internally by Pillow itself because the image is OK otherwise and conversion looks it was done properly (new image is transparent and fine, perfectly usable with Photoshop and other applications, only PIL has problems with it).

[hugovk]

What OS and what version of Python and Pillow are you using?

With:

• Windows 7
• Python 2.7.5
• Pillow 2.4.0

This works for me:

from PIL import Image
Image.open('test2.gif').save('somefile.png', 'PNG')

[xaralis]

It's on Mac OS X 10.9.2 and Pillow 2.3.1, but the same has been seen on our staging Debian Squeeze server.

The statement you wrote itself works and produces transparent PNG which is OK in most apps, problem occurs when you try to do some operations on the generated image file with PIL!

[hugovk]

This also works for me:

from PIL import Image
im = Image.open('test2.gif')
im.save('somefile.png', 'PNG')
im.thumbnail((10, 10))

im2 = Image.open('somefile.png')
im2.thumbnail((10, 10))
im2.save('somefile2.png', 'PNG')

And also no exceptions on Travis CI with Pillow 2.4.0 on 64-bit Ubuntu Linux 12.04 and Python 2.6, 2.7, 3.2, 3.3, 3.4 and PyPy: https://travis-ci.org/hugovk/test/builds/25227409

And also with Pillow 2.3.1: https://travis-ci.org/hugovk/test/builds/25231040

[wiredfool]

There were some changes to the transparency that landed for 2.4.0 that should fix this.

[hugovk]

@xaralis Please can you retest with Pillow 2.4.0?

[xaralis]

I tested it and the issue still remains. What is strange is that this has to be something caused by my two libraries together (one being Pillow and second being sorl-thumbnail).

When I try your example, it works fine with Pillow. But when it's used with sorl (which in turn provides arguments to the PIL previously got from Image.info), it breaks up.

The problem seems to be this:

>>> from PIL import Image
>>> im = Image.open('/Users/xaralis/Desktop/test2.gif')
>>> im.save('testfile.png', 'PNG')
>>> im2 = Image.open('testfile.png')
>>> im2.info
{'transparency': 255}
>>> im3 = im2.convert('RGBA')
>>> im3
<PIL.Image.Image image mode=RGBA size=10x9 at 0x10C014B00>
>>> im3.info
{'transparency': 255}

As far as I understand, there should be no transparency listings for im3 left since the image is now already in RGBA mode. This is what then confuses sorl-thumbnail, because it supplies data from im3.info to the the thumbnailing methods in PIL. And because the image is already RGBA, it fails here:

            if "transparency" in im.encoderinfo:
                # don't bother with transparency if it's an RGBA
                # and it's in the info dict. It's probably just stale.
                raise IOError("cannot use transparency for this mode")

I'm really not sure now (once again) whose fault is it :(

[wiredfool]

Right, I think that's a bug. This is unaffected by the previous patch, as P->RGBA previously handled transparency, but it didn't clear the info field.

[hugovk]

See PR #665.

Is this the right thing to test?

Is this the right kind of fix?

The test fails before the fix and passes afterwards.

[xaralis]

This really fixed the scenario I described above, but unfortunately didn't fix my original issue. There must be some bad conversion going on under the scenes. But since I don't know what the problem is, we can leave this closed...

[caioariede]

This didn't fix my issue as well

[hugovk]

@caioariede Do you have a minimal code example that can reproduce the problem? And any particular images that cause the problem?

@xaralis Is it so that this [https://github.com//issues/664#issuecomment-43305130] is fixed but this [https://github.com//issues/664#issue-33564823] is not? Do you have some example code (and files) to reproduce?

[caioariede]

I'm currently working on this. I'll leave my notes as soon as I find the problem.

[caioariede]

Back to the sorl-thumbnail side: jazzband/sorl-thumbnail#268 (comment)

Guys, I think you can leave this closed for now. Thank you!

[xaralis]

@hugovk Yes, exactly as you say. But the first issue really seems to be on sorl-thumbnail side. I agree we can close this PIL one.