Highest-quality GIF encoder based on pngquant
gif.ski
gif.ski
This is intended only for interoperability. There are sites/apps that take "GIF" too literally and don't allow uploads of efficient formats. If you need to share a GIF now you can waste bandwidth at least without ruining the quality.
I wrote this only because most encoders make GIFs look awful, as if nobody upgraded the encoders since '90s. This one uses pngquant, which takes quantization very seriously. Plus it guides pngquant to put more weight on pixels seen longer on screen, avoids creating redundant colors which can be reused from previous frames, and does dithering across frames, which "patches" previous frames as neatly as possible. Overall it gives anims with 1000-3000 colors per frame.
It's written in Rust and does decode/convert/encode in parallel, because it was fun to do.
If you want smaller GIFs, I also wrote another compressor with opposite quality/size trade-off: https://kornel.ski/lossygif (or use WebM!)
Linux users, it's available in peek, a very usable GNOME-ish screencasting tool. https://github.com/phw/peek/issues/212
GitHub/BitBucket (as of today) won't let me embed a webm/mp4 to a comment field in a Pull Request, but supports drag&dropping a GIF and displaying it inline, so GIF it is for now ¯\_(ツ)_/¯. Maybe our GitHub & Atlassian overlords will see the light at some point in the future, hopefully before the end of our year 1998. I see one intrinsic valuable feature in GIF today: the guarantee that there will be no sound (and even this is kinda moot, an mp4/webm video can be embedded muted by default). Other than that, I agree, it's a shame not to use a better format.
Gifs generally don't pause unless you have some hacks, let alone looping in gifs is a hard coded value within the image, meaning it's entirely optional, but within the export process.
This is almost nothing compared to the savings you make in download times though. Video is a much more modern solution, that's why imgur transcode all their large gifs to webm+mp4
basically real video wins on download size and loses at everything else for this use-case.
but sites keep transcoding to mp4 because it keeps their bandwidth costs down. users don't care -- most internet is plenty fast enough to download even large gifs super fast.
(shameless plug) RgbQuant [1] does the former, too :)
How can it support thousands of colors, I thought GIF was limited to a 256 colors palette ?
GIF works like a canvas that can be painted on with 256 colors at a time. This encoder takes care to reuse existing colors on the canvas as efficiently as possible.
Also most encoders generate ugly palettes (e.g. for a start throwing out 3 of 8 bits of precision) and use naive dithering.
This one spends so much effort on getting optimial palettes, that if I were to get VC funding for it, I'd say it does machine learning.
This one spends so much effort on getting optimial palettes, that if I were to get VC funding for it, I'd say it does machine learning.
LolMaybe we could turn this into a product together. Videographers like making GIFs.
Temporal dithering. Also called FRC - frame rate control.
You might not notice it, but if you are on a TN monitor right now (almost all non-professional monitors) this technique is being used to emulate 24 bit color. Most TN panels can only display 6 bits per channel.
Definitely better a lot than ffmpeg with palette option. (are there other gif tools, how do they compare?)
GIF format may be really dated, but it's really light on resources.
I learned the hard way that playing dozens of small short MP4 video clips on a web page will chock your (mobile) browser, but displaying the same clips as GIF is no problem at all.
Edit: I wrote "dozens of clips", if you don't believe me, try it out yourself, and no video codecs like MP4 are more hardware intensive if your smartphone/tablet graphic card has to render more than a few.
There's also a lesser problem of chroma subsampling destroying fine saturated details. WebM/VP9 supports full-res chroma.
(H264 also has 444 by the way)
ffmpeg -r 30 -f image2 -i linear_gradient%02d.png -vcodec libx264 -preset slow -crf 22 -pix_fmt yuv420p -start_number 1 -vframes 2 linear_gradient.mp4
Firefox stretches it to 0x01 to 0xfe, and introduces obvious banding in the process. MPV does the same thing, although it has an optional debanding filter. The black and white levels are only a single unit off from the original, so I doubt I'd notice in real video. The banding is a much bigger problem (solved by 10-bit color spaces), but GIF has more banding in general use.I'm pretty sure there was trouble some time ago though.... (It was with another computer. There's a lot of things that can introduce color shifts : video platform encoding, browser decoding, graphic card drivers / configuration etc.)
Thanks for the comment