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.
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).
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.