Hacker News: vladdanilov

New comment by vladdanilov in "Squoosh: Make images smaller using best-in-class codecs, right in the browser"

vladdanilov — Tue, 31 Dec 2019 08:50:58 +0000

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

New comment by vladdanilov in "Web Graphics Done Right"

vladdanilov — Mon, 07 Oct 2019 20:38:10 +0000

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

New comment by vladdanilov in "Android 10"

vladdanilov — Tue, 03 Sep 2019 18:10:42 +0000

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.

New comment by vladdanilov in "Essential Image Optimization"

vladdanilov — Sun, 24 Mar 2019 16:56:14 +0000

> 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...

New comment by vladdanilov in "Essential Image Optimization"

vladdanilov — Sun, 24 Mar 2019 14:59:07 +0000

> 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?

New comment by vladdanilov in "Essential Image Optimization"

vladdanilov — Sun, 24 Mar 2019 10:16:51 +0000

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

New comment by vladdanilov in "How Sketch Took on Adobe"

vladdanilov — Fri, 14 Dec 2018 13:39:38 +0000

> 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

New comment by vladdanilov in "Web Performance 101"

vladdanilov — Tue, 30 Oct 2018 16:02:49 +0000

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.

New comment by vladdanilov in "Web Performance 101"

vladdanilov — Tue, 30 Oct 2018 11:36:17 +0000

> 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

New comment by vladdanilov in "Show HN: Websites in 2018"

vladdanilov — Tue, 23 Oct 2018 19:27:01 +0000

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

New comment by vladdanilov in "Show HN: Optimage – Advanced image optimization tool"

vladdanilov — Sat, 20 Oct 2018 21:51:12 +0000

> 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/

New comment by vladdanilov in "Show HN: Optimage – Advanced image optimization tool"

vladdanilov — Sat, 20 Oct 2018 21:13:55 +0000

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

New comment by vladdanilov in "Show HN: Optimage – Advanced image optimization tool"

vladdanilov — Sat, 20 Oct 2018 08:28:17 +0000

Qt does not use native widgets only simulates them.

New comment by vladdanilov in "Show HN: Optimage – Advanced image optimization tool"

vladdanilov — Sat, 20 Oct 2018 07:24:55 +0000

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.

New comment by vladdanilov in "Show HN: Optimage – Advanced image optimization tool"

vladdanilov — Sat, 20 Oct 2018 06:41:53 +0000

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

New comment by vladdanilov in "Show HN: Optimage – Advanced image optimization tool"

vladdanilov — Fri, 19 Oct 2018 11:14:31 +0000

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.

New comment by vladdanilov in "Brave 0.55 released"

vladdanilov — Fri, 19 Oct 2018 08:13:39 +0000

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...

Show HN: Optimage – Advanced image optimization tool

vladdanilov — Fri, 19 Oct 2018 06:03:05 +0000

Article URL: https://getoptimage.com

Comments URL: https://news.ycombinator.com/item?id=18254507

Points: 39

# Comments: 26

New comment by vladdanilov in "A guide to rhythm in web typography"

vladdanilov — Wed, 17 Oct 2018 07:29:53 +0000

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...

New comment by vladdanilov in "Firefox to support Google's WebP image format for a faster web"

vladdanilov — Sat, 06 Oct 2018 11:30:29 +0000

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_...