Converting a UIImage to the WebP format is extremely slow

[pogong]

Converting a UIImage to the WebP format is extremely slow. For a 2.5-megabyte photo with a compression ratio of 0.85, it takes approximately 13.5 seconds

let webpCoder = SDImageWebPCoder.shared
var options: [SDImageCoderOption: Any] = [:]
options[SDImageCoderOption.encodeCompressionQuality] = 0.85

if let webpData = webpCoder.encodedData(with: image, format: .webP, options: options) {
compressionImageData = webpData
}

[dreampiggy]

Image encoding takes more time than JPEG, it's a by-design behavior.

You can upgrade libwebp version instead, or more

We can added something like cwebp 's -m [method] API, which allows you to control the speed-compression tradeoff. The more method you provided, the less compression ratio and faster speed you gain. (Means, fast encoding speed produce larger webp file)

[pogong]

Image encoding takes more time than JPEG, it's a by-design behavior.

You can upgrade libwebp version instead, or more

We can added something like cwebp 's -m [method] API, which allows you to control the speed-compression tradeoff. The more method you provided, the less compression ratio and faster speed you gain. (Means, fast encoding speed produce larger webp file)

I get. SDWebImageWebPCoder dependency on libwebp for conver UIImage to WebP. libwebp version I import is too low. I will upgrade it and try again.
libwebp (~> 1.0)

For [added something like cwebp], The ultimate goal is to have a very small file size for uploading. We won't consider it if the file is too large.

[dreampiggy]

You can have a try. But anyway, maybe provide some detailed control options like the Google official CLI tool is a OK feature request

https://developers.google.com/speed/webp/docs/cwebp

-m int
Specify the compression method to use. This parameter controls the trade off between encoding speed and the compressed file size and quality. Possible values range from 0 to 6. Default value is 4. When higher values are used, the encoder will spend more time inspecting additional encoding possibilities and decide on the quality gain. Lower value can result in faster processing time at the expense of larger file size and lower compression quality.

I can have a check whether it's suitable and easy to implements. Recently I provided the similar encoding options on libjxl codec (in https://github.com/SDWebImage/SDWebImageJPEGXLCoder?tab=readme-ov-file#advanced-jxl-codec-options)

[joaofreitas-karmanow]

Hi @pogong we're having the same issue, even if we reduce compression quality it's slower than the expected speed. Have you come to an alternative solution in the meanwhile?