Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider / propose as option / default to new lossy GIF encoder lossygif #291

Open
ronjouch opened this issue Mar 13, 2018 · 6 comments
Open

Comments

@ronjouch
Copy link

It's that time again! (see #212 🙂). @pornel of ImageOptim/PNGQuant/gifsky fame just released a first version of lossygif (website, github). Quoting the website,

This is an encoder (based on gifsicle) which implements lossy LZW compression. It can reduce animgif file sizes by 30%—50% at a cost of some dithering/noise.

Example: 3.3MB original vs 1.2MB lossy recompression

3.3MB original 1.2MB lossy recompression

Would be awesome for Peek to be able to directly use it. As an option and maybe even by default, as it seems to output good-quality but very compact GIFs.

@phw
Copy link
Owner

phw commented Mar 13, 2018

Lol :) But yes, definitely. My main concern right now is how to structure the settings. I want to make it easy for the user to choose between different options without requiring extensive research.

@ronjouch
Copy link
Author

@phw cool; good point, UX/discoverability matters! Thanks for the continued work on Peek 🙂.

@kornelski
Copy link

The settings can be reduced to:

[x] Fast conversion
[x] High quality
[x] Small file

Choose two.

@aoloe
Copy link

aoloe commented Mar 15, 2018

have you tested if lossygif also brings big advantages for "common" screen captures? as i understood the article i've read, it was mainly for compressing movie snippets (as in the example above)...

@kornelski
Copy link

It does help with screenshots a bit too, since anti-aliasing, icons and gradients can be lossily-compressed.
It will have an annoying tendency of making completely flat and white areas look dirty, because when it has a choice of few white pixels vs few white pixels & one light gray one, the latter seems like better compression.

@phw
Copy link
Owner

phw commented Mar 20, 2018

@kornelski Thanks for the input.

I did some initial testing with a quick 15 seconds screen recording, converting a intermediary video file as generated by Peek with the options used by Peek. The video itself is a screen recording of this github issue tracker, so plain color areas, not too many colors (not the area where e.g. gifski shows its strength). The video frames are extracted to single files using ffmpeg and converted to gif using ffmpeg, gifski, gifsicle and giflossy. The file sizes:

  • Ffmpeg: 7.2 MB
  • gifski (quality 60): 10.0 MB (with a bit better colors at some points)

Now I can use gifsicle / giflossy as a postprocessor on those outputs to further optimize them:

For ffmpeg:

  • gifsicle (optimize 3): 6.7 MB, -7%
  • giflossy (optimize 3, lossy 50): 4.5 MB, -38%

For gifski:

  • gifsicle (optimize 3): 9.6 MB, -4%
  • giflossy (optimize 3, lossy 50): 9.6 MB, -4%

So using giflossy would really bring the file size down significantly when using ffmpeg. It ads some extra post processing time, but I haven't done any measurements on this. If only gifsicle is available it doesn't help that much. Also adding giflossy as a post processor to gifski does not help much, but that was kind of expected.

I tend to just use giflossy if available as a postprocessor by default, and maybe add an option to disable it.

Here is the smallest of the files I could generate:

ffmpeg-gifsicle-lossy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants