Often see someone ask: "Android version sent out of the picture how so slag!" It's far worse than the iphone! ”。 It's not just that many of the images used in Android are much less than the iphone version, so what's going on?
Our team initially struggled with this problem, a half-day effort, around a good big circle, until finally found that this is Google made a "small" error, and has been wrong to today.
Google's fault is: Libjpeg.
Libjpeg is a widely used open source JPEG image Library (see HTTP://EN.WIKIPEDIA.ORG/WIKI/LIBJPEG), and Android relies on libjpeg to compress images. By looking at the source code, we find that Android is not directly encapsulated Libjpeg, but is based on another image processing engine called Skia's Open Source project (Http://en.wikipedia.org/wiki/Skia_Graphics_Engine). Skia is Google's own maintenance of a chatty engine, a variety of image processing functions are implemented in it, and widely used in Google's own and other company's products (such as: Chrome, Firefox, Android, etc.). Skia has a good encapsulation of the libjpeg, which makes it easy to develop image processing functions for operating systems, browsers, and so on.
Libjpeg in compressing the image, there is a parameter called optimize_coding, about this parameter, Libjpeg.doc like the following explanation:
Boolean optimize_coding
TRUE causesthe compressor to compute optimal Huffman coding tables
For Theimage. This requires a extra pass over the Dataand
Thereforecosts a good deal of space and time. The Defaultis
FALSE, whichtells the compressor to use the supplied or default
Huffmantables. In most cases optimal tables save only afew percent
of file sizecompared to the default tables. Note that Whenthis is
TRUE, youneed not supply Huffman tables @ all, and any
Supply Willbe overwritten.
This paragraph probably means that if set optimize_coding to True, will make the compressed image process based on the image data calculation Havermann table (about the image compression Havermann table, please consult the relevant data), because this calculation will significantly consume space and time, The default value is set to False.
At first glance, this explanation doesn't seem to have any problems, and Libjpeg's code has withstood the more than 10-year test, robust and efficient. But a lot of people overlook this, that is, this explanation was written more than 10 years ago, for the time computing equipment, space and time consumption may be significant, but to this day, it seems to be no longer a problem, on the contrary, We should think more about the quality of the images (better display technology) and the size of the pictures (more and more dependent on cloud services).
Google's Skia project engineers eventually did not set this parameter, optimize_coding in Skia the default equals false, which means worse image quality and larger picture files, and the compressed picture process of time and space spent in fact can be negligible. So, how big will the effect of this parameter be?
After we measured, using the same original picture, set Optimize_coding=true and false respectively to compress, want to achieve close picture quality (with Photoshop Zoom to pixel level by block contrast), false when the picture size is about 5-10 times the true. In other words, if we want to compress a JPEG image of the same size at false and true, the quality of false will be significantly inferior to true (although the quality is hard to quantify, we might as well say 5-10 times worse).
We also compared Android and iOS (both using the standard JPEG compression method), both systems do not provide the interface to set optimize_coding (by reading the source, we already know that Android is False,ios unknown), When the same original picture is compressed, the result is the same, with iOS outright. Want to quality close, file size will be 5-10 times, and if you want to compress files of the same size, Android compression quality is simply appalling.
The results show that Apple is well aware of the significance of the optimize_coding parameter and the Havermann table, and it is important to note that the Havermann table algorithm used by Apple is different from the libjpeg (and the Libjpeg-turbo we use later), and the pixel level can see the difference, Apple seems to be further optimized based on libjpeg, and the compressed picture is softer and smoother in detail.
The above test, we have tried multiple original image, a variety of compression ratios, the test results are similar, if interested, you may wish to try it yourself.
Why is the image quality of Android worse than the iphone?
