Image Formats for Mobile: Analysis and Optimization Guide

Images typically account for the largest portion of mobile data usage and occupy crucial visual space. Choosing appropriate image formats and optimizing them properly can help you save bandwidth and enhance visual performance. In this article, I will analyze the characteristics, performance, parameter tuning, and selection of relevant open-source libraries for several mainstream and emerging image formats.

Table of Contents

1. Overview of Several Image Formats
2. Image Format Support on Mobile Devices
3. Encoding and Decoding of Static Images
   • JPEG
   • PNG
   • WebP
   • BPG
4. Encoding and Decoding of Dynamic Images
   • GIF
   • APNG
   • WebP
   • BPG
5. Performance Comparison of Dynamic Image Formats

1. Overview of Several Image Formats

First, let’s discuss some well-known traditional image formats:

• JPEG: Currently the most common image format, developed in 1992 and thus quite old. It only supports lossy compression, and its compression algorithm allows precise control of the compression ratio—trading image quality for storage space. Due to its widespread use, the CPUs of many mobile devices support hardware encoding and decoding specifically for JPEG.
• PNG: Released in 1995, a few years after JPEG. It was originally designed to replace the GIF format, so it shares more similarities with GIF. PNG only supports lossless compression, meaning its compression ratio has an upper limit. Compared to JPEG and GIF, its biggest advantage is support for a complete alpha channel (transparency).
• GIF: Created in 1987 and popularized with the early Internet. It has many drawbacks: it usually supports only 256 indexed colors, its alpha channel is only 1-bit (a pixel is either fully transparent or fully opaque), and its file compression ratio is low. Its only advantage is support for multi-frame animation—a feature that has kept it popular from the Windows 1.0 era to the present day.

After the development of these traditional formats, many companies and teams have attempted to improve them or create better alternatives, such as JPEG 2000 (by the JPEG Group), JPEG-XR (by Microsoft), WebP (by Google), and BPG/FLIF (by individual developers). While these new formats represent significant progress over traditional ones, only a few have gained popularity due to various factors. Below are three emerging formats with strong potential:

• APNG: A image format released by Mozilla in 2008, intended to replace low-quality GIF animations. It is essentially an extension of the PNG format, so Mozilla has long sought to integrate it into the official PNG standard. However, the PNG development team rejected this extension and continued to promote its own MNG dynamic image format. MNG is too complex to be supported by most systems or browsers, while APNG has gradually become popular due to its simplicity and ease of implementation. Mozilla’s Firefox was the first browser to support APNG, followed by Apple’s Safari; Google Chrome has also begun experimenting with support, indicating a promising future.
• WebP: A image format launched by Google in 2010, aiming to replace JPEG with a higher compression ratio. It uses VP8 intra-video encoding as its algorithmic foundation, achieving excellent compression results. WebP supports both lossy and lossless compression, a complete alpha channel, and multi-frame animation—with no copyright issues, making it an ideal image format. Leveraging Google’s influence in the online world, WebP has been widely adopted in just a few years. Look at the apps on your phone: Weibo, WeChat, QQ, Taobao, NetEase News, etc.—WebP is used in every one of them. Facebook has even gone further by using WebP to display sticker animations in its chat interface.
• BPG: A ultra-high-compression image format released in 2014 by the renowned programmer Fabrice Bellard. While some may not be familiar with Bellard himself, his works—FFmpeg and QEMU—are widely known. BPG uses HEVC (H.265) intra-frame encoding as its core algorithm, making it undoubtedly one of the most advanced image compression formats available today. Compared to JP2, JPEG-XR, and WebP, BPG delivers higher image quality at the same file size. Additionally, thanks to its video encoding-based design, it can store multi-frame animations in extremely small file sizes. Bellard’s ingenuity lies in recognizing that he could not secure support from major browser vendors alone—so he specifically developed a JavaScript decoder. Any browser can display BPG images directly by loading this 76KB JS file. Currently, the main barriers to BPG’s popularity are HEVC copyright issues and its long encoding/decoding time. Despite being released only a year ago, companies like Alibaba and Tencent have already begun trialing it.

2. Image Format Support on Mobile Devices

How well do current mainstream mobile platforms support image formats? Let’s examine the image encoding/decoding architectures of Android and iOS:

• Android: Image encoding and decoding are handled by the Skia graphics library, which supports common image formats by integrating third-party open-source libraries. Currently, Android natively supports only JPEG, PNG, GIF, BMP, and WebP (added in Android 4.0). At the upper application layer, only JPEG, PNG, and WebP encoding methods can be directly called. Android does not yet support direct encoding or decoding of dynamic images.
• iOS: Under the hood, image encoding and decoding are implemented via ImageIO.framework. Currently, iOS natively supports JPEG, JPEG2000, PNG, GIF, BMP, ICO, TIFF, and PICT. Since iOS 8.0, ImageIO has added support for APNG, SVG, and RAW formats. At the upper layer, developers can directly use ImageIO to encode and decode all the aforementioned formats. For dynamic images, developers can decode animated GIFs and APNGs, and encode animated GIFs.

Both platforms modify third-party encoding/decoding libraries to some extent when integrating them. For example, Android adjusts libraries like libjpeg to better control memory usage; iOS modifies libpng to support APNG and adds multi-threaded encoding/decoding capabilities. Additionally, iOS has developed AppleJPEG.framework specifically for JPEG encoding/decoding, enabling higher-performance hardware encoding/decoding. libjpeg is only used as a fallback when hardware encoding/decoding fails.

3. Encoding and Decoding of Static Images

As my work currently focuses on iOS development, the following performance tests are all based on iPhones. The main test code can be found here (link mentioned in the original text). Only two test materials were used:

1. The Dribbble Logo (with an alpha channel): Used to test simple, graphic-style images.
2. The classic Lena image: Used to test photo-style images with rich details.

Each image was tested at four resolutions: 64×64, 128×128, 256×256, and 512×512. While the small number of test materials may reduce the accuracy of some results, they are still sufficient for reference.

3.1 JPEG

Three well-known JPEG libraries are widely used today:

• libjpeg: The earliest-developed and most widely used JPEG library. Due to the complexity and ambiguity of the JPEG standard, no other team has reimplemented it—making libjpeg the de facto standard for JPEG.
• libjpeg-turbo: A JPEG library focused on improving encoding/decoding speed. Based on libjpeg, it rewrites parts of the code using SIMD instruction sets (MMX, SSE2, NEON). According to its official website, it delivers 2–4 times better performance than libjpeg.
• MozJPEG: A JPEG library developed by Mozilla in 2014 (based on libjpeg-turbo) that focuses on improving compression ratios. It achieves a 5%–15% higher compression ratio than libjpeg but is significantly slower in encoding.

In addition to these three open-source libraries, Apple has developed its own AppleJPEG library (not open-source), which uses the hardware DSP (Digital Signal Processor) of the chip for hardware encoding/decoding. While less feature-rich than the three libraries above, it offers extremely high performance—in my tests, its encoding/decoding speed was typically 1–2 times faster than libjpeg-turbo. Unfortunately, developers currently cannot access this library directly.

Below is the encoding/decoding performance of ImageIO (based on AppleJPEG/libpng) on the iPhone 6:

• Encoding: A lower JPEG "quality" value results in a smaller file size, poorer image quality, and shorter encoding time.
• Decoding: Decoding time shows little variation across different quality values, likely because most time is spent on function calls and hardware invocation.

Apple sets the default "quality" value to 0.9 in its official Photos app demo. Around this value, a good balance is achieved between image quality, file size, and encoding/decoding time.

3.2 PNG

Compared to JPEG, the PNG standard is clearer and simpler—so many companies and individuals have developed their own PNG encoding/decoding implementations. However, the most widely used one remains the official libpng library released by the PNG Group. Both iOS and Android use this library for PNG encoding/decoding at the .

Below is the encoding/decoding performance of PNG on the iPhone 6:

• For graphic-style images (few colors, little detail): PNG and JPEG show little difference in encoding/decoding speed and file size.
• For photo-style images (rich colors and details): PNG lags far behind JPEG in both file size and encoding/decoding speed.

Unlike JPEG, PNG uses lossless compression and does not offer a compression ratio adjustment option—its compression ratio has an upper limit. Many online tools and services optimize PNGs to further improve their compression ratio. Below is a performance comparison of common PNG compression tools:

• pngcrush: A PNG compression tool included with Xcode. It achieves good compression results compared to images exported by designers using Photoshop.
• ImageOptim: Takes optimization further by testing multiple compression algorithms on each image and selecting the one with the highest compression ratio, further reducing file size.
• TinyPNG.com: Offers an unusually high compression ratio. It compresses PNGs using a color index table similar to GIF, which may cause detail loss in images with rich colors. If using TinyPNG, it is recommended to have designers verify the color accuracy after compression.

3.3 WebP

The WebP standard is defined by Google, and to date, only Google’s libwebp library implements its encoding/decoding—making it the de facto standard for WebP.

Key WebP Encoding Parameters

• lossless: Boolean value (YES for lossless encoding, NO for lossy encoding). WebP’s main advantage lies in lossy encoding; its lossless encoding performance and compression ratio are only average.
• quality: Range 0–100 (controls image quality). 0 means the poorest quality, smallest file size, and severe detail loss; 100 means the highest quality and largest file size. This parameter only has a significant effect on lossy compression. Google officially recommends a value of 75, and Tencent also suggests 75 in its WebP evaluation. Around this value, WebP achieves a good balance between compression ratio and image quality.
• method: Range 0–6 (controls compression level). 0 means fast compression (short time, average quality); 6 means extreme compression (long time, high quality). This parameter also only affects lossy compression significantly. Adjusting this parameter can improve the compression ratio by up to 20%–40%, but encoding time increases by 5–20 times. Google recommends a value of 4.

Recommended Parameter Configurations

• Lossless encoding: Set quality=0 and method=0–3 to save encoding time while maintaining a decent compression ratio.
• Lossy encoding: Set quality=75 and method=2–4 to balance encoding time, image quality, and file size.

Key WebP Decoding Parameters

• use_threads: Boolean value (enables pthread multi-threaded decoding). Only effective for lossy images with a width greater than 512. Enabling it uses multi-threading for decoding, increasing CPU usage but reducing decoding time by an average of 10%–20%.
• bypass_filtering: Boolean value (disables filtering). Only effective for lossy images. Enabling it reduces decoding time by approximately 5%–10% but may cause banding in areas with smooth color transitions.
• no_fancy_upsampling: Boolean value (disables upsampling). Only effective for lossy images. In my tests, enabling it increased decoding time by 5%–25% while causing detail loss and unnatural noise on line edges.

Recommended Parameter Configurations

Typically, all three parameters should be set to NO. To prioritize faster decoding, try enabling use_threads and bypass_filtering; no_fancy_upsampling is unnecessary in all cases.

Due to the large volume of WebP test data, only partial results for 512×512 images are shown here (see the Excel attachment at the end of the article for full data). Key conclusions:

• For simple graphic-style images (e.g., UI assets in apps): WebP’s lossless compression sometimes outperforms PNG in both file size and decoding speed. It is worth trying if you want to optimize your app’s installation package size.
• For complex images (e.g., photos): WebP’s lossless encoding performs poorly, but its lossy encoding is excellent. At similar quality levels, WebP’s decoding speed is comparable to JPEG, while its compression ratio is significantly higher.

3.4 BPG

BPG is one of the most advanced lossy compression formats available, reducing file size by 50% compared to JPEG at the same image quality. Below is a comparison of the classic Lena image (link mentioned in the original text); you can also view online comparisons of compression effects between BPG, JPEG, JPEG2000, JPEG-XR, and WebP for more images—with striking differences.

Currently, only the libbpg library released by BPG’s author supports BPG encoding/decoding. However, the author has compiled a JavaScript decoder based on libbpg, greatly expanding its usability.

BPG supports both lossless and lossy encoding:

• For lossy compression, the quality parameter (range 0–51) controls the compression ratio (higher values mean higher compression ratios). A value around 25 is generally recommended, and the default value in BPG’s official tools is 28.

Currently, libbpg has not been optimized for ARM NEON instruction sets, so its performance on mobile devices is average. Below are performance test results on the iPhone 6: BPG encoding time was too long to include in the table. Tests show that at similar quality levels, BPG’s decoding speed is 3–5 times slower than JPEG.

Currently, BPG is suitable for scenarios where data traffic is critical but decoding time is not. According to online reports, Mobile Taobao and Mobile QQ have begun trialing BPG, but it is unclear whether they have optimized BPG decoding.

4. Encoding and Decoding of Dynamic Images

Dynamic images (GIFs/animated images) are very popular online. Similar to video but simpler to implement and smaller in file size, they have a wide range of applications. The pioneer of dynamic images is GIF, which has been popular on the Internet since the Windows 1.0 era and remains difficult to replace. Despite its age, its core principles are nearly identical to those of several emerging dynamic formats today.

Take a large QQ emoji in GIF format as an example: This emoji consists of 6 static images, each with a fixed display duration. Playing them sequentially creates an animation. Most content across these 6 images is similar—To reduce file size, dynamic image formats usually support special methods to crop similar images, retaining only the differences between consecutive frames.

When decoding dynamic images, decoders typically use a so-called "canvas mode" for rendering:

1. Imagine the playback area as a canvas. Before playing the first frame, clear the canvas and draw the first frame in full.
2. When playing the second frame, do not clear the canvas—only overlay the areas that differ from the first frame onto the canvas, similar to oil painting.

The first frame is called a "key frame" (I-frame, intra-coded frame), while subsequent frames generated through difference calculations are called "predictive coded frames" (P-frames). A well-compressed dynamic image contains only a few key frames and many predictive frames; a poorly compressed one (created by low-quality tools) consists mostly of key frames. Different dynamic image compression tools yield varying results.

In addition, dynamic image formats usually include detailed parameters to control the rendering of each frame. Below are core parameters common to GIF, APNG, and WebP:

• Disposal Method (Clear Mode)
  • Do Not Dispose: Draw the current frame incrementally on the canvas without clearing the canvas.
  • Restore to Background: Clear the canvas to the default background color before drawing the current frame.
  • Restore to Previous: Restore the canvas to the state of the frame before the current one before drawing the next frame.
• Blend Mode (Mixing Mode)
  • Blend None: When drawing, all channels (including the alpha channel) overwrite the canvas—equivalent to clearing the specified area of the canvas before drawing.
  • Blend Over: When drawing, the alpha channel is composited with the canvas (the common effect of overlapping two images).

The above technologies form the basis of common dynamic image formats. Below is an overview of the characteristics of different dynamic formats:

4.1 GIF

GIF has obvious drawbacks:

• It usually supports only 256 indexed colors, so it must simulate rich colors through dithering or interpolation.
• Its alpha channel is only 1-bit, meaning a pixel is either fully transparent or fully opaque.

As shown in a demo image from Tencent’s blog (link mentioned in the original text), GIF suffers from severe "edge artifacts" due to its alpha channel limitations. The current common solution is to add a white border around the image to reduce this visual flaw—Carefully observe the animated emojis in apps like QQ and WeChat: almost every emoji has a white border, which is undoubtedly a reluctant compromise.