Author here: yes, please use 21st century codecs whenever you can.
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!)
For me, due to GitHub/BitBucket restrictions. When spitting a piece of frontend code, I like to help my fellow reviewing collea^H^H^H^H^Hvictims with a little screencast of what my code ends up looking like, typically ten seconds of me clicking around the new feature.
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.
Sadly the UX that ends up being afforded by video-decoders is never quite as seamless and nice as plain-ol-gif -- the video expands to its own window, rather than playing immediately; sometimes you get playback controls; very often the looping is not seemless; you can't just copy-and-paste the video to share it with a friend...
At least videos have these options of pausing and looping.
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
options of pausing and looping are not good things when it comes to small animated clips ("gifs").
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.
The quality is much higher than ffmpeg. Encoding is slower.
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.
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.
Be careful, Gif browser performance can often be way worse than webm's, webp's or even mp4s. Sites like for example imgur switched to other formats by default...
Uhh, GIF only supports 256 colors per frame. I'm not sure what you mean. "Accuracy" of color is more affected by monitor calibration than the actual format (ignoring embedded color profiles used by photographers).
I don't know about WebM VP9 but with H264 colors are often in the 16 - 235 range. I can spot in a webpage when it's a video and not a GIF because colors are washed out and can't be as saturated as with GIF
"Washed out" is not a fault of H.264 per se, but video decoders being awful at color management. Most common errors are lack of gamma correction for Rec 709 and assuming that less-than-HD videos are in ill-defined BT 601 color space.
There's also a lesser problem of chroma subsampling destroying fine saturated details. WebM/VP9 supports full-res chroma.
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.
Yeah I made some more tests with a full RGB color image and a youtube uploading and everything is fine now.
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.)
Hmm, I guess our experiences are just different then. Personally I've never noticed much amiss in online videos, aside from low bitrate. Meanwhile, I can tell gifs apart right away because of banding, overt dithering, and generally diminished quality. I also do photography as a hobby so I'd like to think I'd be sensitive to color issues, but it's possible I'm just not looking for it.
Author here: yes, please use 21st century codecs whenever you can.
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!)
Very cool projects indeed!
gifski is awesome and, be careful, produces big GIFs.
Linux users, it's available in peek, a very usable GNOME-ish screencasting tool. https://github.com/phw/peek/issues/212
What would be the use case of this versus WebM ?
For me, due to GitHub/BitBucket restrictions. When spitting a piece of frontend code, I like to help my fellow reviewing collea^H^H^H^H^Hvictims with a little screencast of what my code ends up looking like, typically ten seconds of me clicking around the new feature.
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.
With WebM I see no reason to use actual GIF anymore. It is such a waste of bandwidth and processing power.
You should absolutely use WebM as an enhancement, but the support for it isn't good enough to drop GIF entirely yet. https://caniuse.com/#feat=webm
mp4 has universal support though (Except for Opera Mini, which doesn't support animated GIFs either) https://caniuse.com/#search=mp4
Sadly the UX that ends up being afforded by video-decoders is never quite as seamless and nice as plain-ol-gif -- the video expands to its own window, rather than playing immediately; sometimes you get playback controls; very often the looping is not seemless; you can't just copy-and-paste the video to share it with a friend...
At least videos have these options of pausing and looping.
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
options of pausing and looping are not good things when it comes to small animated clips ("gifs").
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.
> fancy features for efficient cross-frame palettes and temporal dithering
(shameless plug) RgbQuant [1] does the former, too :)
[1] https://github.com/leeoniya/RgbQuant.js
How does it compare to ffmpeg gif encoder ? Can it be used to compress well gif too ?
How can it support thousands of colors, I thought GIF was limited to a 256 colors palette ?
The quality is much higher than ffmpeg. Encoding is slower.
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.
Maybe we could turn this into a product together. Videographers like making GIFs.
>How can it support thousands of colors
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.
How cool ! That's why the GIF are so heavy it must be something like 100 FPS
Great image quality!
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.
Be careful, Gif browser performance can often be way worse than webm's, webp's or even mp4s. Sites like for example imgur switched to other formats by default...
And color accuracy seems better with GIF also
Uhh, GIF only supports 256 colors per frame. I'm not sure what you mean. "Accuracy" of color is more affected by monitor calibration than the actual format (ignoring embedded color profiles used by photographers).
I don't know about WebM VP9 but with H264 colors are often in the 16 - 235 range. I can spot in a webpage when it's a video and not a GIF because colors are washed out and can't be as saturated as with GIF
"Washed out" is not a fault of H.264 per se, but video decoders being awful at color management. Most common errors are lack of gamma correction for Rec 709 and assuming that less-than-HD videos are in ill-defined BT 601 color space.
There's also a lesser problem of chroma subsampling destroying fine saturated details. WebM/VP9 supports full-res chroma.
I agree but the fact stay the same : you put a H264 video and a GIF in a webpage, most of the time you get better colors with the GIF.
(H264 also has 444 by the way)
What browser are you using? I just tried this with a 0x00 to 0xff linear gradient ( https://www.imagemagick.org/image/gradients/linear_gradient...., duplicated so I have two frames) encoded to MPEG levels (16 to 235) 8-bit h264.
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.Yeah I made some more tests with a full RGB color image and a youtube uploading and everything is fine now.
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
Hmm, I guess our experiences are just different then. Personally I've never noticed much amiss in online videos, aside from low bitrate. Meanwhile, I can tell gifs apart right away because of banding, overt dithering, and generally diminished quality. I also do photography as a hobby so I'd like to think I'd be sensitive to color issues, but it's possible I'm just not looking for it.