vladdanilov
Joined 13 years ago
Karma
699
Submissions
120
Member since
Oct 8
Recent submissions
Comment · 6 years ago
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.
Comment · 7 years ago
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].
Comment · 7 years ago
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.
Comment · 7 years ago
> 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...
Comment · 7 years ago
> 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?
Comment · 7 years ago
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
Comment · 7 years ago
> 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
Comment · 8 years ago
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.
Comment · 8 years ago
> 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.
Comment · 8 years ago
It's alright. There's a 77 KB spinner.gif that can be reduced by half.
Comment · 8 years ago
> 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.
Comment · 8 years ago
Well, the problem is the uncanny valley between native and its imitation.
Comment · 8 years ago
Qt does not use native widgets only simulates them.
Comment · 8 years ago
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.
Comment · 8 years ago
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.
Projects: https://optimage.app https://designplugins.com