Why is the image quality of Android not as high as that of iOS?
I often see people asking, "Why is the image sent from Android! Far worse than the iPhone !". More than just, the image quality of many Android apps is much inferior to that of the iPhone. Why?
Our team had been entangled in this problem for a long time and made great strides. It was not until finally discovered that Google had made a "small" mistake, and it was always wrong today.
Google's error is: libjpeg.
Libjpeg is widely used open source JPEG Image Library Reference http://en.wikipedia.org/wiki/Libjpeg), Android also relies on libjpeg to compress images. By looking at the source code, we will find that android is not directly encapsulated libjpeg, but based on another open source project http://en.wikipedia.org/wiki/Skia_Graphics_Engine called Skia) as an image processing engine. Skia is a big and comprehensive engine maintained by Google. It provides various image processing functions and is widely used in Google's products and other companies such: chrome, Firefox, and Android ). Skia encapsulates libjpeg. Based on this engine, image processing functions such as operating systems and browsers can be easily developed.
In the image compression process, ibmers call optimize_coding. in this case, lib).doc provides the following explanations:
Boolean optimize_coding
TRUE causes the compressor to compute optimal Huffman coding tables
For the image. This requires an extra pass over the data and
Therefore costs a good deal of space and time. The default is
FALSE, which tells the compressor to use the supplied or default
Huffman tables. In most cases optimal tables save only a few percent
Of file size compared to the default tables. Note that when this is
TRUE, you need not supply Huffman tables at all, and any you do
Supply will be overwritten.
In this section, if optimize_coding is set to TRUE, the image will be compressed Based on the image data during the image computation. For more information, see relevant materials ), because this computation significantly consumes space and time, the default value is set to FALSE.
At first glance, this explanation has no problem. libjpeg code has been tested for more than a decade and is robust and efficient. However, many people ignore this, that is, this explanation was written more than a decade ago. For computing devices at that time, the consumption of space and time may be significant, however, today, this does not seem to be a problem. On the contrary, we should consider more and more image quality display technologies) and image size are increasingly dependent on cloud services ).
Google's Skia project engineers did not set this parameter. optimize_coding equals FALSE by default in Skia, which means worse image quality and larger image files, however, the time and space consumed during image compression are negligible. So what is the impact of this parameter?
After our test, we use the same original image and set optimize_coding = TRUE and FALSE respectively to compress the image. To achieve a similar quality, we can use Photoshop to zoom in to pixel-level comparison ), when FALSE, the image size is about 5-10 times that of TRUE. In other words, if we want to compress a JPEG image of the same size when FALSE and TRUE, the quality of FALSE will be much inferior to that of TRUE, although the quality is difficult to quantify, but we may say it is 5-10 times worse ).
We also compared Android and iOS using the standard JPEG compression method). Both systems do not provide the optimize_coding setting interface. by reading the source code, we know that Android is FALSE, iOS is unknown). When the same original image is compressed, the results are the same, and iOS wins. If the quality is similar, the file size will be 5-10 times different. If you want to compress files of the same size, the compression quality of Android is terrible.
The results show that Apple is very clear about the meaning of the optimize_coding parameter and the hafman table. here we need to note that the hafman table algorithm used by Apple is different from libjpeg and the libjpeg-turbo algorithm we used later, the difference can be seen from the pixel level. Apple seems to have further optimized the Image Based on libjpeg, and the details of the compressed image are softer and smoother.
In the above test, we tried multiple source images and various compression ratios, and the test results are similar. If you are interested, you may wish to try it on your own.
In the end, we decided not to use the native JPEG compression method of the Android system. Instead, we compiled an native Android Library Based on libjpeg-turbo and used it to compress images, in this way, only 1/5 of the image size is used in our products, so that users can get inferior or even better image quality. For our team, it is worth the effort of a long time. Libjpeg-turbo has performance advantages, so we will not go into details here)
Finally, we attached our team's open source project address on github for reference: https://github.com/bither