Skip to content

GIF writing should use LZW encoding #5278

@raygard

Description

@raygard

What did you do?

Create a GIF

What did you expect to happen?

It should use LZW encoding, as most GIF applications do.

What actually happened?

It used Fredrik Lundh's cleverly compatible but suboptimal encoding from 1999.

What are your OS, Python and Pillow versions?

  • OS: Windows, Linux
  • Python: 3.7, 3.8, 3.9, any other
  • Pillow: Doesn't matter; does this on everything since 1999.

This isn't a bug report, it's an enhancement request. I'm pretty sure Fredrik did it this way to avoid the then-current LZW patent problems with Unisys. Those ended in 2004 after all Unisys patents on LZW expired. I'm puzzled why, 17 years later, LZW has been barely mentioned anywhere regarding GIFs from PIL. I see a mention in #617 and #4644. Both of these say GIFs are currently "uncompressed"; that's not quite right. Fredrik had a clever sort-of-run-length-encoding technique. I think using LZW still won't fix all the concerns in #617, I think PIL could use more work for animated GIFs but would need to look into that more.

I see in #617 "Filesize concerns" an invite from @wiredfool "If you’d like to contribute a gif compressor under the PIL license, go for it."

I have one ready to go, well tested at my end in Windows and Linux (WSL2 and Raspios). It's a mod to Gif.h and a major overhaul of GifEncode.c. A drop-in replacement that does not require any other changes.

PIL currently writes all GIFs as 256-color, with full 8 bits in the uncompressed pixels (as in tobytes()). My GifEncode.c writes them this way, but it is ready to go for shorter codes (smaller color tables) when the rest of PIL is (probably GifImagePlugin.py and others).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions