vladdanilov

Squoosh does not use best-in-class codecs [1]. Lossless PNG compression is 5-15% worse on average and lossy PNG compression (color quantization) is limited to PNG-8, which is not enough to maintain image quality. Lossy JPEG compression is only tuned for 4:2:0 chroma subsampling and causes blurring of fine details because trellis quantization is guided simply by the variance in DCT domain.

[1] https://optimage.app/benchmark

This describes the problem more or less but it does not give a single working solution. Image optimization now includes videos, scaling, format and color conversion, and simply compressing images at Quality 80 does not provide consistent visual quality [1].

[1] https://optimage.app/benchmark

The website assets are optimized in a rather strange way. The total page weight of ~20MB is huge for mobile. The images are heavily compressed using WebP lossy with quite noticeable blockiness and washed out textures and fine details, but squeezed into 1MB, yet the videos are only lightly compressed, and make up most of the page weight. Had they been compressed with libx264 at good quality, the page weight would be more than 70% smaller, and there would not be any need to ruin the image quality that much.

> For high quality photography purposes jpeg is bordering on useless

> Use WebP! For everything!

Jyrki Alakuijala, one of the creators of WebP, on WebP vs JPEG [1]:

>> For high quality photography, I (and butteraugli) believe that JPEG is actually better than WebP.

>> Below JPEG quality 77 WebP lossy wins, above JPEG quality 77 JPEG wins (for photography).

>> This was based on the maximum compression artefact in an image -- averaging from 1000 images.

Better meaning here [2]:

>> Faster decode (up to around 6x faster) and less bytes needed at high quality (in comparison to butteraugli scores).

[1] https://encode.ru/threads/2905-Diverse-third-party-ecosystem...

[2] https://encode.ru/threads/2905-Diverse-third-party-ecosystem...

> 56% larger than those created by ImageOptim!

And noticeably degraded if you compare those images with the originals. Optimage does apply chroma subsampling, the major winner here, when it makes sense.

My goal is automatic image optimization with predictable visual quality, i.e. images have to remain authentic to originals.

> your closed source tool

FYI, ImageOptim API is closed source and way more expensive if that was your point.

> Your benchmark is not a legitimate comparison

If you have a better one,

> then post the results

I did post mine. Just why are you taking them out of context and missing others, e.g. lossless compression results?

I have been making Optimage which is currently the only tool that can automatically optimize images without ruining visual quality [1]. It is also the new state of the art in lossless PNG compression.

I have raised a number of issues [2] with this guide. It’s been over a year and they still have not been addressed [3].

[1] https://getoptimage.com/benchmark

[2] https://github.com/GoogleChrome/essential-image-optimization...

[3] https://twitter.com/addyosmani/status/914207017589288960

> Omvlee decided to design his application to run natively on OS X. This was very smart. Although Omvlee could have reached a considerably wider audience by designing Sketch for Windows (or OS X and Windows), focusing on the Mac market was highly strategic

Sketch exists thanks to the genius of Quartz / Core Graphics. It does not have a rendering engine per se and struggles even with path ops [1].

This technical debt may soon be the end of Sketch. Because apart from Adobe, there is now Figma with smart people like Evan Wallace who can really "decide" [2][3].

With C++ core, Figma can go fully native [4], and it's puzzling why they have done this already.

[1] https://twitter.com/vmdanilov/status/892358827378696194

[2] https://www.figma.com/blog/building-a-professional-design-to...

[3] https://medium.com/@evanwallace/easy-scalable-text-rendering...

[4] https://twitter.com/evanwallace/status/673959396104273921

I specifically meant automatic lossy compression with predictable visual quality. If ImageOptim could actually achieve it (automatically), that would save me and others an awful lot of time. But as it turns out it is not that easy.

Some very smart people at Google go to the trouble of creating projects like Guetzli. I personally have spent months on this, and it gets me every time someone claims "just use that one tool" without any evidence. I presented mine and it's reproducible.

ImageOptim is a great tool otherwise.

> Compress your JPG images with the compression level of 70‑80.

In practice some images can get noticeable artifacts even at around 90. Most of JPEG compressors always apply chroma subsampling which is often destructive on its own [1]. On the contrary, many hidpi images can be compressed at around 50.

> Use Progressive JPEG… Thanks to this, a visitor can roughly see what’s in the image way earlier.

That's not the point of using progressive JPEGs nowadays. The 10-200% decompression slowdown is for the 5-15% size reduction.

> Use Interlaced PNG.

Don't. Interlaced PNGs can easily be 1/3 bigger. There are better ways to show loading images, and it's already used on the website.

> webpack has image-webpack-loader which runs on every build and does pretty much every optimization from above. Its default settings are OK

> For you need to optimize an image once and forever, there’re apps like ImageOptim and sites like TinyPNG.

These tools are no good for automatic lossy image compression [1]. The default is mostly JPEG 4:2:0 at quality 75, PNG quantized with pngquant at settings as low as conscience allows, missing out many PNG reductions and optimal deflate, no separation between lossy and lossless WebP if at all, etc.

As a result, the images on the website have about 13-24% more to optimize losslessly.

[1] https://getoptimage.com/benchmark

It's alright. There's a 77 KB spinner.gif that can be reduced by half.

> imageoptim clocking in at around half the total filesize of optimage

Only that ImageOptim ruined most of JPEG images while PNG images are ~7.5% bigger.

> imageoptim is dramatically smaller on all of them

There are myriad ways to make them much smaller at the cost of visual quality: blurring, posterization, rescaling, etc. The question is where to stop. With visually lossless, you can apply these techniques in advance and have predictable results. For example, Optimage does choose chroma sampling when it is not destructive to original.

> the 'broken gradient' (I can't see it)

It can be seen on a calibrated display, sorry.

> the orange sneakers (imageoptim's looks better and not overblown colors)

Original colors are "overblown" [1].

> or the rotated beach scene

It is rotated.

[1] https://webkit.org/blog-files/color-gamut/

Well, the problem is the uncanny valley between native and its imitation.

Qt does not use native widgets only simulates them.

Yes, some of the source images are tagged with ICC color profiles.

It looks like Firefox still does not treat untagged images as sRGB and the difference on wide-gamut monitors may be noticeable.

That was a matter of an option switch. It should be fixed now. Thanks.

Why? There's an extensive benchmark [1], also seen on the homepage, that proves it is the first tool that does not break images like other state-of-the-art tools, i.e. fits the submitted tagline.

On a side note, HN voting system is horribly broken. I submitted the link in the morning and when I hit the bed it somehow got attention.

[1] https://getoptimage.com/benchmark

I plan to release a cross-platform CLI tool first. The core tool already works under *nix. But there's still a good portion of business logic in the app.

The work on a cross-platform GUI is happening too, but it is way slower than I anticipated. It's going to be native or nothing. I don't consider Electron or QT as an option.

I find the irony in more prosaic details like a 2.1MB image [1] to show the new UI of "Secure, Fast & Private Web Browser" (for comparison optimized PNG8 is 351KB [2] and JPEG is 398KB [3]).

[1] https://brave.com/new-brave-browser-release-available-for-ge...

[2] https://user-images.githubusercontent.com/3129436/47203976-b...

[3] https://user-images.githubusercontent.com/3129436/47203978-b...

JPEG is not a good choice for UI/typography screenshots. There are ~1MB of JPEGs at quality 50 on the page. By using PNG8 not only you can halve that size but also preserve original quality. Example:

  [1] PNG24 199 144 bytes
  [2] JPEG 94 699 bytes
  [3] PNG8 47 155 bytes

[1] https://user-images.githubusercontent.com/3129436/47068394-d...

[2] https://user-images.githubusercontent.com/3129436/47068393-d...

[3] https://user-images.githubusercontent.com/3129436/47068392-d...

WebP lossy and WebP lossless often get mixed up. They are substantially different. While the former is mostly just outdated VP8 4:2:0, it is fast and more pleasing to the eye than JPEG at low quality and more practical there, given it has transparency. The latter is a pretty good option for ARGB images offering 25% improvement over PNG [1], and 20-40% on top of that with near-lossless compression.

[1] https://developers.google.com/speed/webp/docs/webp_lossless_...

You will get better results by swapping the two. Pngquant stops at color quantization.

Also, most of those savings came from near-optimal Deflate compression.

Nice to see you're using the same animation technique [1]. MP4 could not possibly provide this level of quality/size (~150KB per animation).

Pngcrush is rather limiting though. I could compress the PNG textures by ~8% more with optimage [2] (I'm the author).

And for newer browsers, serving the textures as brotli-compressed BMPs would actually make them >30% smaller (probably more with filtered but uncompressed PNGs).

[1] http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...

[2] https://getoptimage.com

Why is it not a browser feature? Transferred 175MB just to measure the speed. Good it does not do it at 3G speeds.

There are also 156KB of images waiting to be compressed to one third of that [1].

[1] https://i.imgur.com/34SWfzo.png

This article like many others is full of fallacies.

Image formats are not used wisely: [1] is PNG not JPEG and [2] is JPEG not PNG.

> I found that setting quality (mozjpeg) to 70 produces good enough images for the most part, but your mileage may vary.

You can get away with this setting for hidpi sizes but 1x will look horrible [1]. If you care about quality, the mileage is actually 75-95.

> (Pngquant) quality level of 65-80 to provide a good compromise between file size and image quality

Again, it may only be applied to hidpi sizes, and it will easily ruin any gradients or previously quantized images.

Pngquant is a great color quantization tool but it does not actually perform any lossless PNG optimizations, which can save you at least 5% more, and up to 90% in some cases.

All of these tools will also blindly strip metadata (but it's not guaranteed!) along with color profiles and Exif Orientation resulting in color shifts and image transformations respectively.

Most importantly, none of them are good enough for automatic lossy compression. Guetzli is the closest but it still has some severe issues [3]. I'm also trying to build a real thing, and it is hard.

> there’s value in using WebP formats where possible

WebP lossless and WebP lossy are quite different formats. WebP lossy being always 4:2:0 is not a good replacement for JPEG [4] especially at higher quality. On the contrary WebP lossless has evolved into a decent alternative for PNG including lossy [5].

Proper responsive images would give you considerably smaller page weight and improve performance on mobile devices. BTW Google treats oversized images as unoptimized [6].

[1] https://freshman.tech/assets/dist/images/http-status-codes/e...

[2] https://freshman.tech/assets/dist/images/articles/freshman-1...

[3] https://github.com/google/guetzli/issues

[4] https://research.mozilla.org/2014/07/15/mozilla-advances-jpe...

[5] https://twitter.com/jyzg/status/958629795692150790

[6] https://developers.google.com/speed/pagespeed/insights/?url=...

It's not automatic then, which is critical for batch processing, and does not solve all the problems, and create new usability problems for most users.

The only solution I found is to build a new tool, and that required a complete rewrite of existing optimizers and significant changes to underlying libraries.

It's pretty good. The problem with automatic lossy compression is consistent quality.

There is a number of issues with each and every tool you mentioned, e.g. color information stripped with metadata causing color shifts in wide-gamut and non-sRGB images, camera images changing orientation when Exif stripped, color banding on PNGs and JPEGs even when using Guetzli (JPEGmini is not nearly as good in other cases, but Guetzli is extremely slow), unexpected dithering noise on flat PNGs, tracing artefacts on screen recorded GIFs, JPEGs being overcompressed, poor lossless compression (virtually any online service), progressive JPEGs incompatible with Photoshop, etc.

These are just some of the problems I've been solving, and yes, there are better tools.

> So, on a post which discusses problematic behaviour on Github where entitled people try to bully us into working on what they want without writing any code themselves -- you (someone who has tried to bully us before on Github) -- decide that being in the spotlight is a perfect time for you to draw everyone's attention to your feature request once more. Because you think bullying us with HN social pressure will help your cause.

This whole sentence is false. I did not "bully" you anywhere (!), requested a feature from you, or pressured you to do anything. Quite the opposite, I showed an easy way to improve. Again, I could have been wrong on the effect. That's why the question. The "spotlight" reference was just a small joke. Sorry.

> And then, to back up your argument, you link to a page which is not running on Ghost - and actually does have optimised+responsive images.

I meant only the Ghost homepage in the link, and better optimization (proves [1]).

> All so you can spam your own image compression app.

I gave you the facts. Yet, you smeared me with false accusations. Is this even fair?

[1] https://github.com/vmdanilov/optimage/files/2011804/ghost.zi...

Since you're in the spotlight now, I want to bring back the discussion on image optimization [1]. Looking at your Features page [2], there are 953KB of images that can be compressed down to 453KB (-47.3%). I genuinely wonder what you can save with better image optimization.

[1] https://twitter.com/JohnONolan/status/941572225890533376 [2] https://ghost.org/features/ [3] https://i.imgur.com/b5OO3Q6.png

I'm making something in between [1].

That image is a good example for any perceptual encoder. At 50% size it's 600KB (487KB with current master), and there's still a lot to be unhappy about, e.g. a hidpi image like that can be compressed a lot harder.

[1] https://getoptimage.com

There are glaring optimization issues.

Over 6MB of those 10MB is just one bloated photo [1]. It can be compressed down to 1-2MB. Moreover, if it was a proper responsive image, it would not be larger than 100-200 KB for most readers because a good JPEG compressor can pull 2 bits per pixel [2].

Ironically, image optimization apps don't get that much coverage.

[1] https://techcrunch.com/wp-content/uploads/2018/05/vikbajaj20...

[2] https://arxiv.org/pdf/1703.04416.pdf