.. _webp_processing: 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:: 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). .. figure:: 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.