
Lossy GIF compressor - tambourine_man
https://kornel.ski/lossygif
======
maturz
It's weird that this pull request was never accepted by gifsicle.

[https://github.com/kohler/gifsicle/pull/16](https://github.com/kohler/gifsicle/pull/16)

Also check out his other high-quality GIF encoder project
[https://gif.ski/](https://gif.ski/)

Older HN submission
[https://news.ycombinator.com/item?id=15730018](https://news.ycombinator.com/item?id=15730018)

~~~
citilife
It's probably (in part) due to the last line of the article / post:

> App Store terms and conditions forbid distribution of Free Software that
> grants users freedom to use the program any way they want. You're not
> allowed to distribute this software with DRM applied to it.

~~~
abritinthebay
Which is, of course, false.

Specific free software licenses have DRM distribution restrictions regardless
of if source/non-DRM editions are available. Which of course goes against user
freedom too (to have their applications the way they want).

That to me says that it's the licence that is the issue (or needs to be
improved).

------
Arbalest
I like this part on the end

> App Store terms and conditions forbid distribution of Free Software that
> grants users freedom to use the program any way they want. You're not
> allowed to distribute this software with DRM applied to it.

Basically the essence of the GPL in one short paragraph.

~~~
nemothekid
Is this actually correct? If I distribute my app on the App Store, and provide
a GitHub link in the description of the the full source code of the app, then
it should comply with the GPL.

~~~
chungy
Short answers: GPLv2, no; GPLv3, yes.

Apple's App Store is identical to the TiVoization problem that GPLv3 was
written to combat: [https://www.gnu.org/licenses/rms-why-
gplv3](https://www.gnu.org/licenses/rms-why-gplv3)

~~~
dragonwriter
Tivoization provision of GPLv3 only applies to software distributed as with a
hardware “ussr product” (in the same transaction in which possessory interest
in the hardware is transferred), so while it would apply to core components of
iOS (of they used GPLv3 upstream, which they won't), it wouldn't seem to apply
to any third party software distributed through the App Store.

(The same _concerns_ that motivated anti-tivoization may apply, but the actual
license terms don't appear to.)

This is not to say that there aren't other incompatibilities, but anti-
tivoization doesn't seem to be a problem.

~~~
chungy
There is no difference. Apple provides binaries (via the App Store), and the
user is not allowed to install/run their own binaries, which is a requirement
the GPLv3 added to prevent TiVoization.

It matters not whether the software is preinstalled or offered on the side,
the effect is the same. If the user can't install their own versions of
software, the environment is incompatible with the GPLv3.

Now, running GPLv3 software via Cydia/jailbroken-iPhones is probably OK, since
the user has gone through the effort in order to run their own versions of
software. I'm pretty sure the FSF would prefer running a free software version
of Android instead, however. :-)

~~~
jcelerier
> There is no difference. Apple provides binaries (via the App Store), and the
> user is not allowed to install/run their own binaries, which is a
> requirement the GPLv3 added to prevent TiVoization.

This has not been true for a few years. Nowadays anyone can freely upload apps
from Xcode to iDevices (before it used to cost 99$)

~~~
opencl
You can freely upload apps from Xcode to iDevices if you own a Mac, and have
an Apple developer account (not paid but you still need one), and compile the
code yourself, and _most crucially_ the code signing on apps deployed this way
expires after a week. This is in no way a serious deployment method.

------
andrewla
The core idea here is really interesting; adapting a lossless compression
system in a heuristic approximate mode. Instead of looking backwards for
identical subsequences, look for approximate subsequences.

Unlike tools like pngquant, which use quantization to create palletized
images, this directly hooks into the compression stage. I haven't looked at
the source yet, but this is an idea that I've been thinking about recently,
especially as regarding the somewhat obscure farbfeld [1] image format, which
relies entirely on external compression.

Zlib in particular is "easy" to do this for, or at least an approach is clear,
in which you can build up a big prefix tree and then "massage" it by combining
subtrees. There are a number of different ways that you could approach this
heuristically as well.

Bzip is a different beast -- the Burrows–Wheeler transform is sensitive to
changes in the byte stream, so it's not easy to poke a byte to make it similar
to another byte and then get the delta on the transform itself.

[1]
[https://tools.suckless.org/farbfeld/](https://tools.suckless.org/farbfeld/)

------
donatj
Huh, I will have to play with this and see how it compares with the naive
interframe optimizer I’ve been hacking on for years.

------
guitarbill
You can do something similar with ffmpeg’s palettegen/paletteuse or
imagemagick’s fuzz option. Generally speaking, fuzz/IM does well for
recompressing GIFs, especially high-noise or static background. If you still
have the source video, nothing can beat ffmpeg though.

(Those options usually require a bit of tweaking though. I can’t compare these
at work, might give it a go later.)

~~~
pornel
This is absolutely not similar to any ffmpeg/IM's options. This doesn't change
the palette, and doesn't rely on static backgrounds.

Instead, it integrates very deeply into LZW compression to make dictionary
matching visually approximate in a way that maximizes compression. The only
other implementation of this that I'm aware of is in Photoshop.

~~~
tambourine_man
Hi Pornel, thanks a lot for the amazing tool.

If you are doing the animation from scratch, which would be the preferred
workflow for smallest size with as few artifacts as possible?

Photoshop Save for Web 256? Which dithering algorithm works best with
giflossy?

Would exporting every frame as an individual GIF with its own pallet help?

Generating an MP4 first then run it through some other quantizer?

Thanks

~~~
pornel
Lowering pixel resolution and frame rate will reduce file size the most.

Make the gif straight from the original lossless source if possible, since any
JPEG-like video compression artifacts will inflate file size in gif.

If the input is a video already, use gif.ski

And then giflossy.

Of course ideally avoid the gif format entirely, since even the best possible
compression in it is still horribly awful compared to H.26x and VP9.

~~~
tambourine_man
Thanks, maybe a more specific question: how does it compare to Photoshop’s
lossy option in Save for Web?

Which dither and color reduction algorithms would be better suited for
giflossy?

------
innagadadavida
Gif needs to be EOLd - there is no need to use it as most browsers support
modern alternatives like mp4 with real video codecs. Even safari tech preview
can now play these inlined.

~~~
emerged
Do you suggest that the untold billions of both animated and static GIFs
should be lossily transcoded to mp4 (which presumably also has a limited shelf
life?) so that we can finally remove GIF support from web browsers because
[reason here]?

Btw, mp4 is a container format.

~~~
yoz-y
There is also APNG, which might be better suited for this and supports
transparency.

~~~
opencl
APNG is a strictly superior drop in replacement for GIF, has been around for
ages, but never got adopted by anyone but firefox. I don't get it. Animated
WebP also fills the same role but lacks support outside of Chrome.

The trend of converting gifs to h264 videos is kind of awful in terms of image
quality but I'm sure it saves a lot of bandwidth for sites like imgur and
twitter.

~~~
yoz-y
APNG works in both Chrome and Safari, haven't tested in IE/Edge.

h264 might have an advantage since it does consume less cpu due to hardware
support though.

~~~
xd1936
aPNG was never accepted by the PNG standards body, and tends to be as large or
larger than GIF[1]. If we're going to go through the effort of converting,
then WebP makes way more sense.

1\. [https://www.androidpolice.com/2017/05/01/animated-png-
format...](https://www.androidpolice.com/2017/05/01/animated-png-format-
compare-animated-webp-gif/)

~~~
maxst
If you convert static GIF to static PNG, 99% of the time you'll get a smaller
file. That was the original goal of PNG project, and it succeeded: static GIFs
disappeared completely. Converting animated GIF to animated PNG leads to
similar filesize savings.

~~~
innagadadavida
Video formats like webp exploit temporal and spatial similarities to get
efficiency. Gif/apng do not. This reduces bandwidth costs and file sizes very
much.

~~~
maxst
Download a dozen random GIF cinemagraphs, and try gif2webp and gif2apng on
them.

~~~
innagadadavida
Try ffmpeg or vlc instead, you will get much better results. Ffmpeg has
support for almost all video/audio formats ever invented.

