WebP Processing

WebP achieves better compression rates by being more complex. The cost of this complexity is that it’s slower, particularly at encoding.

“Therefore, it’s not usually advisable to convert images to WebP on the fly. WebP files should be generated in advance.” (@webmproject.org)

Detailed information about this image format can be obtained from Googles WebP Website and the WebP Discussion Group.

A simpler representative representation can be found at Learn Images! WebP.

Results based on the standard libraries and the ImageIO WebP extension

tile size [pixel]

ImageIO PNG [ms]

ImageIO Ext WebP [ms]

LibWebP encode [ms]

128

5

67

11.2

256

15

304

30.1

512

64

1034

91.4

1024

177

2089

440.5

2048

1068

8027

1595.9

Table 1: Comparison of the processing time for different tile sizes and image formats. For the ImageIO images, the average of 1000 .write functions was calculated. With LibWebP, the average of the encoding duration was calculated for 10 passes. For WebP processing, the default settings were used (lossy, q=75) and Version 1.0.0. GeoserverRequest for image (256*256).

tile size [pixel]

PNG original

ImageIO PNG

ImageIO Ext WebP

LibWebP

128

14

13

5

5

256

64

60

25

25

512

223

204

106

106

1024

805

769

352

352

2048

2283

2171

1062

1062

Table 2: Comparison of the size in KB for different tile sizes and image formats (see table above).

It is obvious that WebP can never match the performance of PNG images due to its encoding time.

However, this does not explain the much worse results of the ImageIO WebP extension. Unfortunately, the original repository is not available any more, and the main fork webp_imageio is outdated and unmaintained. The Geoserver plugin is based on the fork from GOTSON. A hopeful new pure Java implementation is TwelveMonkeysImageIO WebP, but so far only supports read access. Scrimage Webp produced mostly faster results, but does not fit in Geoservers ImageIO ecosystem. Google itself provides for Android libwebp Java bindings.

WebP supports lossless compression (for graphics) and lossy compression (for photos). Default is lossy with compression quality 75.

  • Lossy compression: A small compression quality factor (q) produces a smaller file with lower quality (best quality q=100).
  • Lossless compression: A small factor enables faster compression speed, but produces a larger file (maximum compression q=100).

q

lossless [ms]

lossless [kb]

lossy [ms]

lossy [kb]

0.0

48

57

18.6

25

0.1

48.8

57

19.5

26

0.2

48.7

57

19.7

27

0.3

82.6

45

20.4

27

0.4

84.6

45

20.6

28

0.5

85.6

45

20.8

29

0.6

89.1

45

20.8

29

0.7

93.9

45

21.2

30

0.8

99.3

45

21.4

32

0.9

99.3

45

22.5

36

1.0

1425

44

25.3

46

Table 3: Comparison of the lossy/lossless mode and compression factor (q) for LibWebP encoding time and file size. Input image, see below. The average of the encoding duration was calculated for 10 passes.

q

lossless [ms]

lossless [kb]

lossy [ms]

lossy [kb]

0.0

242

57

113

25

0.1

211

57

145

26

0.2

236

57

137

27

0.3

370

45

150

27

0.4

376

45

140

28

0.5

308

45

128

29

0.6

375

45

123

29

0.7

529

45

126

30

0.8

468

45

125

32

0.9

424

45

130

36

1.0

3106

44

184

46

Table 4: Comparison of the lossy/lossless mode and compression factor (q) for ImageIO WebP extension .write time and file size. Input image, see below. The average of 1000 .write functions was calculated.

../../_images/lossy_lossless.png

Figure 1: Input image for comparison in table 3 and 4 (PNG 256 * 256 px, 73 kb).

Unfortunately, the best result regarding speed and size is not really usable (see below).

../../_images/libweb_lossy_0_0.png

Figure 2: Image of the best result (lossy, q=0).

In general, the default values (lossy, q=0.75) are a good choice.

The significantly longer duration regarding the ImageIO Extension cannot be explained by the writing process alone (compare tables 3 & 4).

Processing time & energy consumption

The increased processing time correlates with increased energy consumption.

Measured with a commercial power meter on a local PC for one hour (multiple times).

Stack:

  • Windows10
  • Java11
  • Tomcat9
  • Chrome Browser
  • OpenLayers Client
  • random WMS GetMap requests every 0.5 seconds

Result:

  • PNG 0.067 kWh
  • WebP 0.071 kWh
  • NoRequests 0.047 kWh

This also applies to the JPEG format in a weakened way.

Browser rendering energy impact for different image formats

Image Format

Energie impact

WebP

0.4532

PNG

0.4545

PNG8

0.457

JPEG

0.4414

Table 5: Comparison of the rendering energy consumption for different image formats in Firefox. Average of 1000 WMS GetMap requests.

Firefox “Energy Impact” (about:processes page) shows the processing power being used by the CPU.

Despite the different file sizes of the image formats, no really significant differences can be seen. Of course, more complex coding also requires more complex decoding.