Skip to content

Releases: ImageOptim/gifski

1.34.0

13 Jul 17:19
1060eab
Compare
Choose a tag to compare
  • Palette quality improvements from newer libimagequant
  • Warnings for incorrect frame numbers and timestamps in the API
  • --in-color-space override for ambiguous YUV4MPEG files

1.33.0

17 Mar 04:09
d87e2e1
Compare
Choose a tag to compare
  • Improved y4m format support
  • Tuned dithering levels

No temp PNGs needed

24 Apr 13:52
bb9676e
Compare
Choose a tag to compare
  • Added support for YUV4MPEG2 (Y4M), which is a primitive uncompressed video format that can be streamed from a command-line ffmpeg, without creating any temporary files on disk:

      ffmpeg -i "video.mp4" -f yuv4mpegpipe - | gifski -o "crushed.gif" -
  • Added support for reading video from stdin. Specify - as the path.

  • Added warnings about reading or writing files from/to an interactive terminal.

There are no changes to the Windows GUI. Use previous MSI Windows installer.

The jump in version number is because I've previously accidentally tagged 1.13 as 1.31.

Fixed trimming for real this time.final.FINAL2

09 Feb 23:21
Compare
Choose a tag to compare

The last bit of C has fallen

24 Oct 03:03
Compare
Choose a tag to compare

gif.ski was originally meant to be just the highest-quality GIF maker, but over time I also made it generate smaller files. Now it's probably the most technically advanced GIF compressor, if I say so myself.

The key to good GIF compression is making LZW algorithm lossy. In 2014, I wrote a patch that added lossy compression to gifsicle. Gifsicle is a GIF optimization tool created in 1998, so I can't blame them for not using Rust. Of course, I wanted to use that lossy compression in gif.ski too, so I've made gifsicle usable as a Rust crate.

Rust already had a gif encoder, so bringing all of the gifsicle's code seemed unnecessary. I only wanted the lossy LZW bit, so I've made the Rust gif library accept data from other compressors, and used only a couple of gifsicle's C functions for compression.

The lossy LZW compressor was still my 2014 hacked-together C — until yesterday. I've rewritten it in Rust.

The rewritten code gives exactly the same, bit-identical output. Usually, when people rewrite projects it's hard to compare results to the original, because the rewrites change and reinvent things along the way. This time it's apples to apples. I made sure it works exactly the same. I even reimplemented an integer overflow bug and quirks caused by use linked lists. The result is… the same performance, and the same binary size, within margin of error. You don't need to rush to upgrade! On one hand this isn't surprising — it's the same algorithm, and Rust has C-like performance as advertised. OTOH I used mostly idiomatic Rust, and did not try to make it super optimized. The original C code did clever things with memory pools and linked lists, and I've swapped it all for Vecs in enums.

Aside from ffmpeg, which I'm not rewriting, gif.ski is now 100% pure Rust. It makes it a bit easier to build it. The x86-64 MUSL/Linux binary has been built on my ARM Mac. Since the code is now in a form I find easier to refactor, later I'll work on improving quality of its lossy dithering, because for some reason I'm determined to squeeze every last possible bit out of this prehistoric video format.

ffmpeg is back

01 May 02:56
Compare
Choose a tag to compare
  • Support for ffmpeg v5 and v6
  • Fixed an issue that caused too much dithering in frames with little motion and few colors
  • The command-line progress bar displays estimated file size

Transparency bugfix

16 Mar 19:28
Compare
Choose a tag to compare
  • Fixed an edge case in animations with low amount of movement and pixels becoming transparent.
  • Fixed GIF conformance when using lossy encoding and frames with only 2 colors

You can resize GIFs too

18 Jan 05:12
Compare
Choose a tag to compare
  • gifski can now read other GIF animations as an input. It's a very bad idea to try to use it as an optimizer, since it will inherit a bad quality and can only make it worse. However, combined with the --width option it can be useful for generating thumbnails of GIF animations.

  • it now uses multiple threads for resizing and preprocessing when reading videos, so might be faster on multi-core machines, especially when using --fast

25% faster

04 Dec 00:44
Compare
Choose a tag to compare

If you have enough CPU cores.

Add or remove noise at will

13 Nov 22:38
Compare
Choose a tag to compare

The command-line version breaks down the --quality option into two sub-options (which default to the same value as --quality):

  • --motion-quality=80 controls how aggressive temporal and spatial denoising is. Lower values make files smaller by reducing differences between frames, but too-low values will make animations look wobbly, jerky, or posterized.

  • --lossy-quality=80 controls lossy LZW compression. Lower values make files smaller by skipping inconvenient-to-compress pixels, but too-low values will make animations look dithered and grainy.