Also check out his other high-quality GIF encoder project https://gif.ski/
Older HN submission https://news.ycombinator.com/item?id=15730018
> 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.
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).
I think the reason for change not being accepted upstream is that the amount of complexity added exceeds amount of free time the upstream maintainer has.
Basically the essence of the GPL in one short paragraph.
I've heard one reason is that the App Store requires users to agree to additional usage restrictions, which the GPL forbids distributors (in this case Apple) from applying.
Apple's App Store is identical to the TiVoization problem that GPLv3 was written to combat: https://www.gnu.org/licenses/rms-why-gplv3
(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.
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. :-)
Whether or not there is a moral difference, there is a clear difference in terms of the license terms.
> 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.
No, the requirement that the GPLv3 added is that “Installation Instructions” must be provided when a licensee conveys software “in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized)” [emphasis added] ; that is, for anti-tivoization to apply, the software must be for a “User Product” (which App Store Apps are) and it must be conveyed in the same transaction as possession of the “User Product” is transferred (which clearly does not happen in the normal case with App Store Apps.)
You seem to be confusing a fuzzy picture of the goal of the GPLv3 with the actual requirements of the license terms.
 see the third to last paragraph of Section 5 of the license, https://www.gnu.org/licenses/gpl-3.0.en.html
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$)
> No. The only time you would be required to release signing keys is if you conveyed GPLed software inside a User Product, and its hardware checked the software for a valid cryptographic signature before it would function. In that specific case, you would be required to provide anyone who owned the device, on demand, with the key to sign and install modified software on the device so that it will run. If each instance of the device uses a different key, then you need only give each purchaser a key for that instance.
Apple doesn't comply with GPL and they don't want to. On a few occasions I have formally asked them to comply with GPL terms and they took GPLed apps down instead.
Plenty of other OSS licenses work fine on the app store.
> Permission is granted to copy, distribute, or alter Gifsicle, whole or in part, as long as source code copyright notices are kept intact, with the following restriction: Developers or distributors who plan to use Gifsicle code, whole or in part, in a product whose source code will not be made available to the end user -- more precisely, in a context which would violate the GPL -- MUST contact the author and obtain permission before doing so.
This comment section is filled with weird misconceptions about the software and about the compatibility between GPL and the Apple store terms of service. Somehow people think the software is GPLv3 even though a cursory glance will reveal that it isn't. People think that the author of the modification has a say in how it's licensed. It's based on GPLv2 software, he doesn't. Others are saying that while distributing GPLv2 licensed software on the Apple store is fine, GPLv3 isn't, when neither is OK. Sorry for soapboxing here, but it seems appropriate to address all these misconceptions in one place.
Then consider the facts: The work is based on GPLv2 licensed tool (gifsicle), thus subject to the same terms and conditions. Knowing that, one can read the note as a friendly reminder of how the ToS of the Apple store is incompatible with GPLv2. You may have read it as snark, but it's literally just stating a matter of fact regarding a matter the author of the fork can't legally do anything about.
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  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.
(Those options usually require a bit of tweaking though. I can’t compare these at work, might give it a go later.)
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.
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?
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.
Which dither and color reduction algorithms would be better suited for giflossy?
Perhaps you meant h.264 or MPEG-4 (which should not be confused with mp4 container format!).
You can decode GIFs with a few hundred lines of code. Decoding different mp4 cases requires several orders of magnitude more code.
One big advantage of GIFs is simplicity. So perhaps you could come up with something that could be decoded with at most one or two orders of magnitude more code?
Btw, mp4 is a container format.
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.
h264 might have an advantage since it does consume less cpu due to hardware support though.
APNG is (can be?) lossless. You have to lose a lot of quality in GIF to get reasonable filesizes. APNG gets you lossless quality with decent sizes.
Quality sticklers rejoice!
Lots of large GIFs used today were converted from H.264 (YouTube, etc.), so the crap quality of H.264 -> GIF -> H.264 is entirely the fault of GIF.
In terms of image quality, it's only slightly worse. But having the same palette for all frames helps to make inter-frame optimization much more efficient.
Yes, I assumed everyone here knows about mp4/h264/etc. Nokia also released a more formal container spec using HEIF, that supports transparency (most folks will complain about patent encumbered issues). However it will be a while before browsers support it.
Personally as soon as I find a mp4 instead of a gif I curse the uploader for not providing a reasonable gif backup I can use and share around.
As it is not yet generally available as something the public will install, and given how long it can take for a wide userbase to upgrade, this support wouldn't mean being able to set gif's EoL to any date soon.
Unless you refuse to let Safari hold you back as IE6 did for so long (and to an extent newer IE versions still do depending on you target audience - in my day job I have no choice but to support IE 8 and 11 to this day). Though if that is the case then you've stopped actively supporting Safari already.