Why is the image quality on Android not as high as on iOS?

I often see people asking: "Why are the pictures sent from the Android version of WeChat so bad! They are much worse than those from the iPhone!" It's not just WeChat. The picture quality of the Android version of many apps is much worse than that of the iPhone version. What's going on?

Our team also struggled with this problem at first, and spent a lot of time and effort going around in circles, until we finally discovered that this was a "small" mistake made by Google, and it has been wrong until today.

[[132494]]

That's Google's fault: libjpeg.

Libjpeg is a widely used open source JPEG image library (see http://en.wikipedia.org/wiki/Libjpeg ), and Android also relies on libjpeg to compress images. By looking at the source code, we can see that Android does not directly encapsulate libjpeg, but is based on another open source project called Skia (http://en.wikipedia.org/wiki/Skia_Graphics_Engine) as an image processing engine. Skia is a large and comprehensive engine maintained by Google itself, in which various image processing functions are implemented and widely used in Google's own and other companies' products (such as: Chrome, Firefox, Android, etc.). Skia has a good encapsulation of libjpeg, and based on this engine, it is very convenient to develop image processing functions for operating systems, browsers, etc.

When ibjpeg compresses images, there is a parameter called optimize_coding. Regarding this parameter, libjpeg.doc has the following explanation:

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.

This passage roughly means that if optimize_coding is set to TRUE, the Huffman table will be calculated based on the image data during the image compression process (for the Huffman table in image compression, please refer to the relevant information yourself). Since this calculation will significantly consume space and time, the default value is set to FALSE.

At first glance, this explanation seems to be fine, and the libjpeg code has been tested for more than ten years and is robust and efficient. But many people overlook the fact that this explanation was written more than ten years ago, and for the computing devices at that time, the consumption of space and time may be significant, but today, this does not seem to be a problem anymore. Instead, we should consider more about the quality of the picture (better and better display technology) and the size of the picture (increasingly dependent on cloud services).

Google's Skia project engineers did not set this parameter in the end. The default value of optimize_coding in Skia is FALSE, which means worse image quality and larger image files, while the time and space spent on compressing images is actually negligible. So, how big is the impact of this parameter?

According to our actual test, using the same original image, we set optimize_coding=TRUE and FALSE to compress, and if we want to achieve similar image quality (using Photoshop to enlarge to pixel level and compare block by block), the image size when FALSE is about 5-10 times that when TRUE is used. In other words, if we want to compress to the same size JPEG image when FALSE and TRUE are used, the quality of FALSE will be much inferior to that of TRUE (although the quality is difficult to quantify, we might as well say that it is 5-10 times worse).

We also compared Android and iOS (both use standard JPEG compression methods). Neither system provides an interface to set optimize_coding (from reading the source code, we already know that Android is FALSE, iOS is unknown). When compressing the same original image, the results are the same, iOS wins. If you want to have similar quality, 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 simply terrible.

The results show that Apple is very clear about the significance of optimize_coding parameters and Huffman table. It should be pointed out here that the Huffman table algorithm used by Apple is different from libjpeg (and libjpeg-turbo that we later adopted). The difference can be seen at the pixel level. Apple seems to have made further optimizations based on libjpeg, and the compressed images are softer and smoother in details.

In the above experiments, we tried multiple original images and various compression ratios, and the test results were similar. If you are interested, you may as well try it yourself.

Finally, we decided not to use the native JPEG compression method of the Android system, but to compile a native Android library based on libjpeg-turbo, which is specifically used to compress images. In this way, in our products, we can use only 1/5 of the image size to provide users with comparable or even better image quality. For our team, the long and arduous process is worth it. (Using libjpeg-turbo also has performance benefits, which I will not elaborate on here.)

***, here is the open source project address of our team on github for reference: https://github.com/bither