4 ms·
> The best way to counter negative effects of loading image assets is image compression: using tools such as Kornel Lesiński‘s ImageOptim, which utilizes great
by vladdanilov 10y ago
> The best way to counter negative effects of loading image assets is image compression: using tools such as Kornel Lesiński‘s ImageOptim, which utilizes great libraries like mozjpeg and pngquant, we can reduce image byte size without sacrificing visual quality.
The standard metrics these tools provide (JPEG quality or PSNR) are not enough to preserve the visual quality for the variety of images. I'm working on the project to actually do it [1].
My favorite example is the actual Google logo [2]. It's 13 504 bytes and can be reduced almost 2 times to 7 296 bytes saving probably gigabytes of bandwidth each day.
[1] http://getoptimage.com http://getoptimage.com
[2] https://www.google.ru/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png https://www.google.ru/images/branding/googlelogo/2x/googlelo...
- Klathmon 10y agoImage compression is a great first step. Imagemin is a great javascript-based tool that lets you incorperate a bunch of optimization tools (mozjpeg, pngquant, jpegtran, optipng, gifsicle, etc...) all in one (if your project can easily use javascript modules...). And there is a plugin [0] (that I wrote) for webpack to make it happen without any thought. Another potentially massive step is to use the srcset [1] attribute of the <img> tag. It lets you provide a bunch of different resolutions for the same image, and the browser will choose the best one to download and render based on the physical screen pixel density, zoom level, and possibly in the future even things like bandwidth preferences or battery level. Combine the imagemin plugin with a webpack-loader [2] that will auto-generate 5-ish different downscaled versions of an image as srcset, and you get a pretty perfect setup. My web apps now always use the highest resolution image I have available by default (within reason, I do cut it down to a realistic value), then provide 5 different downscaled versions alongside it in the srcsets automatically which are all run through a battery of optimization to compress them as good as possible. And the browsers will only download the biggest one it can realistically use. Everyone gets high quality images, nobody wastes bandwidth because of support for higher res screens. [0] https://github.com/Klathmon/imagemin-webpack-plugin https://github.com/Klathmon/imagemin-webpack-plugin [1] https://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/ https://css-tricks.com/responsive-images-youre-just-changing... [2] https://github.com/herrstucki/responsive-loader https://github.com/herrstucki/responsive-loader
- vladdanilov 10y agoAgree. Serving the right size is as important.
- iamaaditya 10y agoIf it would be sufficient to have high PSNR only in the 'regions of interest', then you could use something like this [1], which uses a CNN model to predict a map, and a multiple JPEG encoding to achieve variable quality compression. [1] https://github.com/iamaaditya/image-compression-cnn https://github.com/iamaaditya/image-compression-cnn
- vladdanilov 10y agoThe AI approach is interesting but there are just too many problems with it. MozJPEG is actually using something similar called trellis quantization or soft-thresholding. The idea is to further quantize DCT coefficients in noisy areas. There are some limitations [1] though. But it's not an issue with locally sensitive metrics and can be improved with edge detection. Another challenge here is to estimate the current image quality and the target error. [1] https://github.com/mozilla/mozjpeg/issues/129 https://github.com/mozilla/mozjpeg/issues/129