Resize images in the browser. Things could get worse

Meet this Manya. Manyu was struck by a terrible disease and now she needs your help. Manya grew up an ordinary girl, a cheerful happy child. But a little more than a year ago, doctors put a terrible diagnosis on her - aliasing. And she began to look like this.

As it turned out, the reason for this was the greed and greed of browser manufacturers who decided to save on image resize algorithms and apply the lowest quality filters. Then Mania was saved - she completed a course of consecutive non-multiple two decreases, which reduced aliasing and restored its former sharpness. But now she is in danger again.

What has changed this year? The good news is that a standard has emerged designed to control the quality of rasterization of images on canvas. News is even better: this standard is implemented in the browser: mobile Safari from version 9.3 and desktop from version 9.1. And judging by the results, the high value corresponds to the method of convolutions with a bicubic or very similar filter. Those. the result is really very good. It would seem that it is possible to wrap the code crammed in the previous article in if ('imageSmoothingQuality' in context) and wait for the same property to appear in other browsers. But something went wrong.

Something went wrong and Manu was attacked by another attack - Manya became soapy. It turned out that Google is also preparing a surprise for Masha, having implemented the desired property and so far, hiding it behind the chrome://flags/#enable-experimental-canvas-features flag chrome://flags/#enable-experimental-canvas-features . Here it is only implemented not in good faith, but with anything. Instead of correct, clear, Orthodox convolutions, the technique used in games is used for the high value: using supersampling, mip levels are created for the image, and then the closest size is resized using the same cheap method with a fixed number of source points.

Why does this method work in games? For two reasons. First: in a dynamic game, you do not have time to consider each texture separately, whether it is soapy or not. Much more on the perception affects the overall picture and special effects than such trifles. Second: very tight time constraints, for which, by the way, the constant complexity of this method is relatively to the size of the final image (screen resolution in the case of games).

Why this method is not suitable for resizing in applications for working with graphics? Yes, because it is not a resize method at all, hello. This is an application of two solutions, none of which is able to meet the quality requirements - and so it is together. It has neither a mathematical justification, nor a stability of the result with respect to the input parameters. For example, a picture that is optimized to 244 pixels wide may turn out nothing like this, and a graphic to 243 will be all in soap. Moreover, this is not acceptable for the imageSmoothingQuality property specially created for this occasion. Well, if I put high , then I guess I mean that I need exactly good quality. Why bother to implement a new property at all if it gives a worse result than can be achieved by fiddling with an existing solution? Here, for example, on the right, Manya is presented by successive non-multiple two decreases. Absolutely healthy and happy baby.

If you suddenly do not feel sympathy and sympathy for small children, then here is a friend of you, Manechkin, mandrill Poupus. He suffered the same trouble. From left to right:

• blurred picture after resize in Chrome with imageSmoothingQuality = 'high'
• high-quality pictures from Safari
• more or less high-quality picture after resizing in Chrome by the method of successive decreases without imageSmoothingQuality

How can you help? Well, for example, go put an asterisk in the bug report created for this. I'm not sure how effective it is, but I can't think of anything else.

What will happen if this feature is moved to a stable version of Chrome? Instead of simply checking for the presence of features, you will either have to fence the check by user agent, or disable this functionality for all users, even in Safari. The right idea came to mind: you need to go and put an additional check right now on the fact that the user agent does not have the word Chrome. If Chrome corrects and in a stable version does not have this disgrace, you can turn it on. But if one of the clients downloads the code now, it will not be harmed upon leaving the main Chrome Manya.

For obtaining images once and twice , a test stand , as well as a widget for successive reductions were used.