WebP encodedData loads for 30+ seconds

[OmarJalil]

iOS version: 13.1
iPhone: X
I'm currently using DBAttachmentPickerController to choose from a variety of images, the problem comes when I take a picture directly from the camera and try to upload it to our server. The SDImageWebPCoder.shared.encodedData loads for about 30 seconds more less.

Here is the code I use

let attachmentPickerController = DBAttachmentPickerController(finishPicking: { attachmentArray in
            self.images = attachmentArray
            var currrentImage = UIImage()
            self.images[0].loadOriginalImage(completion: { image in
                self.userImage.image = image
                currrentImage = image!
            })
            //We transform it to webP 
            let webpData = SDImageWebPCoder.shared.encodedData(with: currrentImage, format: .webP, options: nil)
            self.api.editImageUser(data: webpData!)
        }, cancel: nil)
        attachmentPickerController.mediaType = DBAttachmentMediaType.image
        attachmentPickerController.allowsSelectionFromOtherApps = true
        attachmentPickerController.present(on: self)

[dreampiggy]

WebP encoding speed is related slow, it use software encoding and VP8 compression algorithm (complicated), compared to the Hardware accelerated JPEG/PNG encoding. (Apple's SoC).

picture directly from the camera

The original image taken on iPhone camera may be really lark, like 4K resolution. If you don't do some pre-scale and try to encode it, you may consume much more time.

The suggestion can be like this:

1. Try to use the options like the compressionQuality, the higher cost more time, but compress more. By default it's 1.0, which is the higest and most time consuming.
2. Try to pre-scale the original image. For image from Photos Libraray, you can always use the API to control the size. Or, you can use SDWebImage's transform method like - [UIImage sd_resizedImage:].
3. Do all the encoding in background thread, never block main thread
4. If all these is not suitable, the better solution, it's to use JPEG and PNG format instead of WebP. Then, on your image server side code, transcoding the JPEG/PNG to WebP. Server side processing is always the best idea for this thing.

[dreampiggy]

If you're intersted the real benchmark or something, compared to JPEG/PNG (Hardware) and WebP (Software). You can try to use my benchmark code demo here, to help you do your decision.

https://github.com/dreampiggy/ModernImageFormatBenchmark

iPhone XR, iOS 13.0, CompressionQuanlity: 1.0, image: 512x512 pixels

<Decode> [PNG]: Time: 1.24 ms, RAM: 0.016 MB
<Decode> [JPEG]: Time: 2.48 ms, RAM: 0.016 MB
<Decode> [HEIC]: Time: 12.93 ms, RAM: 0.047 MB
<Decode> [HEIF]: Time: 102.57 ms, RAM: 0.766 MB
<Decode> [WebP]: Time: 28.28 ms, RAM: 1.000 MB
<Decode> [BPG]: Time: 34.94 ms, RAM: 0.781 MB
<Decode> [FLIF]: Time: 510.65 ms, RAM: 1.000 MB
<Decode> [AVIF]: Time: 177.39 ms, RAM: 0.922 MB
<Encode> [PNG]: Time: 81.30 ms, RAM: 0.641 MB
<Encode> [JPEG]: Time: 2.32 ms, RAM: 0.078 MB
<Encode> [HEIC]: Time: 80.94 ms, RAM: 0.719 MB
<Encode> [HEIF]: Time: 2425.87 ms, RAM: 5.938 MB
<Encode> [WebP]: Time: 633.70 ms, RAM: 0.031 MB
<Encode> [BPG]: Time: 3931.02 ms, RAM: 0.359 MB

[dreampiggy]

The libwebp encoding performance is related to the quality. Try with 0.6.0+ version's maxFileSize option and limit a high size (Higher size, faster; Lower size, slower)