Kornel Lesiński

http://www.lcdf.org/gifsicle/ https://kornel.ski/lossygif you can also just compress user uploaded gifs serverside. but the top commenter is right, gifs are great because of they're functionality and simplicity. the better thing would be for the w3c and browsers vendors can get their act together (spoiler: they won't) and do things like make gif20, finish svg2, implement svgfonts, implement complete css3 specs, if you want to preserve functionality and usabilty of graphic assets on the web while reducing their bandwidth.

The most common implementation of this appears to be from a company called Bytemobile which also injects some pretty buggy JavaScript into HTML content. The good news is that you can disable all of their degradation by adding "no-transform" to your Cache-Control headers: https://kornel.ski/en/proxies “The standard HTTP header Cache-Control: no-transform which tells proxies not to modify responses was respected by all proxies I've encountered. This is amazing! It wins an award in the "Best Supported Obscure Header" category.”

Hard to find any. It's a primitive format ignoring 20 years of video compression research. It tries to be replacement for GIF by repeating its mistakes: it has very basic inter-frame compression, lacks motion vectors, doesn't guarantee keyframes, RGB-only, and frame decoding isn't parallelizable. In 8-bit mode it supports even fewer colors than GIF (GIF can combine frames to achieve thousands of colors), and in 24-bit mode it's larger than GIF. For full-motion video it requires 10x-15x more data than VP9 to be decompressed by the CPU, and there's no hardware acceleration. https://kornel.ski/efficient-gifs There's false dichotomy between "animations" and "videos", mostly due to historical reasons and that older codecs (and AWebP) used 4:2:0 subsampling which made them blurry. VP9 supports alpha, 4:4:4 mode, and it's cheaper to decode (it's more complex, but using 10x less data offsets that), so it'd be best to forget that GIF and APNG ever existed.

Your benchmark is not a legitimate comparison because it does not compare files of equal size. See https://kornel.ski/en/faircomparison for an explanation of the problems with your methodology. The files your closed source tool generates in this benchmark are 56% larger than those created by ImageOptim! Have your program generate smaller files and then post the results.

If you decide to implement optimizations beyond imagemagick's ones, you might want to consider other tools than Gifsicle: - lossygif for small size, based on gifsicle, https://kornel.ski/lossygif - Gifski for high quality, based on pngquant, (https://gif.ski/) Both are made by Kornel Lesiński. Lossygif is actually result of a pull request being ignored by gifsicle maintainer(s) for years – more details in a recent HN thread: https://news.ycombinator.com/item?id=16573627.

I agree that the parent claim ("Rust will quickly replace C in the Linux kernel") was utterly risible, but your comments just seem like the mirror image of theirs. What on earth is an 'impostor language'? Imposture of what or whom? I'm tired of having to deal with this culture war crap in our profession. These languages are tools. C, C++, and Rust all compile down to the same LLVM IR (or GCC if you stray from rustc). There are certainly semantic and grammatical peculiarities that affect how each of them do so[0], but by and large running a simple Rust program and a simple C program through Godbolt will do a lot to disabuse you of the idea that the two are irreconcilably different. To anyone else who wants to write performant Rust, my advice: (1) no_std, if only to focus the mind, (2) .try_foo(), not .foo(), b/c allocation is fallible, (3) always set `opt-level` to at least 1 (1 is far further from 0 than 3 is from 1, ime), (4) use stack-allocated alternatives to heap-allocated types ('smallvec' or equiv vs Vec, 'smolstr' vs String, &c) even at the expense of overallocating buffer space, (5) exploit vectorisation where possible (e.g. SIMD), in general practising mechanical sympathy, and (5) parallelism is not a panacea, whereas cache locality usually is. Measure everything, but also: memorise every instruction and how many cycles it takes, and think in those terms - in terms of your assembled, perhaps-handmodified code - rather than unscientific laptop benchmarks. (Jeff…

Also, unfamiliar with PHP, but a few years ago I somehow ended up maintaining/managing one or two reasonably trafficked Wordpress sites that some (untechnical) friends put together, so every now again I get to learn how weird some shit in PHP is. And it’s that time again, because the comment about name conflicts was confusing as I could’ve sworn that during couple times I’ve had to actually poke around PHP code I saw it had namespaces. After some quick googling though, I was able to confirm a) PHP has “namespaces” and b) they seem to work like most other “features” (i.e. not like you’d expect if you’ve programmed in anything but PHP) [1]. However, C has the a similar convention [2] (though the convention is — as far as I’m aware — for the sake of maintainability/readability as the compiler has no problem telling the difference between to things named the same, the person reading it probably will. While, as I understand it, PHP will just overwrite anything with the same name in the file/lib you include). It seems like PHP is heading in the right direction, but I have no idea why anyone would pick it up or start anything new with it these days, I don’t care how well done and the nice and new stuff is, it’s the decade of utter mess it’s built on top of that has uninterested me. Don’t get me wrong, since “acquiring” the Wordpress sites I’ve gone from a blind PHP hater, to at least understanding/appreciating it (but still won’t actually touch it with a 10ft pole). PHP is brain…

(author here), It wasn't available when I started this project. butteraugli was (which guetzli uses internally), but in my opinion they're relatively new and need a bit more rigorous review than I can provide. I ultimately chose SSIM not because it was the most accurate metric in all cases, there have been plenty of advancements since it was published. But I linked a paper comparing several alternatives and saw that SSIM works fine for this use case (all things equal except number of JPEG artifacts), while being much faster, and that was enough proof for me to keep it simple. In a batch scenario today, one of these could make sense instead of SSIM and/or mozjpeg, but definitely do your own comparisons at equivalent file sizes, required reading: https://kornel.ski/en/faircomparison We do set a pretty high lower bound to avoid the edge cases inherent in the algorithm and as a result, out of the 30% savings, dynamic quality was only a small portion of that. I wouldn't be surprised that with an offline workload, a more CPU-intensive algorithm can do much better with a lower lower bound. I found that SSIM scores for images were relatively stable across resolution (same general graph shape, just translated down on the Y-axis). This is mentioned at line 36 of the example dynamic quality code. So we actually generate, compute and compare the SSIMs on much lower resolution candidate images than the final image for speed as well. I'm not sure if this would hold true for something…