Webp decode speed

[Denis]

Hello!

I use webp for storing images in my game and faced that webp decode is several times slower that png. :(
For example, on iPad3 (old hardware, but retina etxtures) 2048x2048 webp file with compression level 0.7 decodes 3.2 seconds with 0.5.1.sources ( it was 3.8 with 0.4.3), Png decode time is 0.8 second.

Is there ways to improve decode time? For example:
- Use never cwebp.exe encoder (I use rather old version from here: https://www.codeandweb.com/texturepacker)
- Change the compression level (how?)
- Check if the code below may be optimized (it just works, but I never thought of its optimization)
- Anything else?

Any suggestions appreciated!

byte* Decode_WEBP(const byte* dataIn, int length, int& width, int& height)
{
    byte* image = 0;

    WebPDecoderConfig config;
    if (WebPInitDecoderConfig(&config))
    {
        WebPBitstreamFeatures* const bitstream = &config.input;
        WebPDecBuffer* const outputBuffer = &config.output;
        outputBuffer->colorspace = MODE_RGBA;

        const uint8_t* data = (const uint8_t*)dataIn;

        VP8StatusCode status = WebPGetFeatures(data, size_t(length), bitstream);
        if (status == VP8_STATUS_OK)
        {
            status = ExUtilDecodeWebP(data, size_t(length), 0, &config);
            if (status == VP8_STATUS_OK)
            {
                width = outputBuffer->width;
                height = outputBuffer->height;
                int renderWidth = NextHigherPOT(width, true);
                int renderHeight = NextHigherPOT(height, true);

                image = new byte[renderWidth * renderHeight * 4];
                assert(outputBuffer->u.RGBA.size == width * height * 4);
                const byte* rgb = (const byte*)outputBuffer->u.RGBA.rgba;

                if (width == renderWidth && height == renderHeight) // NPOT textures support
                    memcpy(image, rgb, width * height * 4);
                else // no NPOT textures support
                {
                    memset(image, 0, renderWidth * renderHeight * 4 * sizeof(byte));
                    for (int i = 0; i < height; ++i)
                        memcpy(&image[i * renderWidth * 4], &rgb[i * width * 4], width * 4 * sizeof(byte));
                }

                WebPFreeDecBuffer(outputBuffer);
            }
        }
    }
    return image;
}

The textures I work with:
https://www.dropbox.com/s/9fkblqkrhd5yuwr/characters_all_hr.png?dl=0
https://www.dropbox.com/s/yws6h6746vx0c5d/characters_all_hr.webp?dl=0

Thanx in advance!

Denis

[Jyrki Alakuijala]

WebP has two separate formats inside it: a lossy VP8 video-format based image format, and a novel lossless format developed specifically for WebP.

The lossless decoder is sometimes more than 2x faster than the lossy decoder. For some categories of non-photographic images the (near)lossless encoding is also smaller. Try storing your image losslessly or 'near losslessly' with --near_lossless 40

As a third option, the highly experimental 'delta palettization' encoding might work if you don't have alpha and if you are not picky about quality. Delta palettization images are the fastest way to decode photographic images. Again the lossless codec is used in the decoding.

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss+unsubscribe@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Denis]

Thanx, jyrki!

I tried -near_lossless 40. File is 50% bigger (990K vs 640K), loading is 20% faster (2.5s vs 3.2s), but still far from png's 0.8s.
-lossless leads to worse results compared to -near_lossless 40.

PS: I do need alpha in my images, so 'delta palettization' is not for me.

Denis

[Pascal Massimino]

Hi Denis,

few points:

On Fri, Dec 9, 2016 at 2:43 PM, Denis <joyfuls...@gmail.com> wrote:

Hello!

I use webp for storing images in my game and faced that webp decode is several times slower that png. :(
For example, on iPad3 (old hardware, but retina etxtures) 2048x2048 webp file with compression level 0.7 decodes 3.2 seconds with 0.5.1.sources ( it was 3.8 with 0.4.3), Png decode time is 0.8 second.

I can't test right now on iPad3, but something seems off. On an x86_64, your webp file decodes 30% faster than PNG (with latest libwebp at HEAD), and that's the expected figure. You webp file uses 'mixed' mode, where the RGB is compressed lossily, and the alpha plane (transparency) with lossless compression. Using only lossless mode for all (cwebp -z 9 ... ) would result in a larger file (~1M). This file would be even faster to decompress (70% faster here).

I'm not sure about your setup on the iPad, but you should check that optimizations are turned on if you compiled the library yourself.

 

Is there ways to improve decode time? For example:
- Use never cwebp.exe encoder (I use rather old version from here: https://www.codeandweb.com/texturepacker)
- Change the compression level (how?)
- Check if the code below may be optimized (it just works, but I never thought of its optimization)
- Anything else?

Regarding the code below, note that you could decompress directly into the final 'rgb' buffer, even if not a POT image.

This would save the memcpy. All you have to do is fill the fields in 'outputBuffer' accordingly, and mark it 

outputBuffer->is_external_memory = 1

This explained here: https://developers.google.com/speed/webp/docs/api#advanced_decoding_api

hope it helps!

skal/

 

--

[Denis]

Hi skal,

I've refactored code according to the link you provided.
Here are new decode results from release version (sorry, I measured debug last time):
Png 2048x2048: 360 ms
Original webp 2048x2048: 600 ms
Near _lossless_40 webp 2048x2048: 560 ms

I can't test right now on iPad3, but something seems off. On an x86_64, your webp file decodes 30% faster than PNG (with latest libwebp at HEAD), and that's the expected figure. You webp file uses 'mixed' mode, where the RGB is compressed lossily, and the alpha plane (transparency) with lossless compression. Using only lossless mode for all (cwebp -z 9 ... ) would result in a larger file (~1M). This file would be even faster to decompress (70% faster here).

I'm not sure about your setup on the iPad, but you should check that optimizations are turned on if you compiled the library yourself.

That seems to be the clue. I compile library from .c sources, which Xcode options should I check?

Denis

[Pascal Massimino]

Hi Denis,

if you included the (properly configured) file src/webp/config.h, make sure you defined HAVE_CONFIG_H somewhere.

Otherwise, you should check that NEON support is enabled for iPAD3 (which is armv7 iirc).

The important final flag to be defined is WEBP_HAVE_NEON. But make sure that XCode defines properly the flags

like __ARM_NEON__ or similar. If so, the file src/dsp/dsp,.h will take care of enabling WEBP_HAVE_NEON eventually.

Also, you should have a look at the file iosbuild.sh that helps you set up a project properly (and the flags it defines).

Here: https://github.com/webmproject/libwebp/blob/master/iosbuild.sh

hope it helps,

skal/

(ps: and of course, make sure -O3 -DNDEBUG are used for the Release build).

[Denis]

Hi skal,

Thank you for suggestions!

I checked WEBP_USE_NEON define, the program uses it, I can set a breakpoint there. The same for -O3 and -DNDEBUG.
I tried both ways: compile lib from sources and use WebPDecode.framework compiled by iosbuild.sh. Timings are the same.
But the picture is completely different on PC/Win10: on the same files webp decodes 25% faster, exactly as you expect!
Can we investigate the issue deeper, as I really want to see real webp decoding speed on iOS? I can provide you with a simple project to work with.

Denis

[Denis]

Hi skal,

Here is the sample project:
https://www.dropbox.com/s/ie85yfgs63ra296/WebpSpeedTest.zip?dl=0

Denis

On Tuesday, December 13, 2016 at 1:47:10 PM UTC+3, skal wrote:

[Denis]

Hi skal,

Can we return to the issue? Could you run the simple project I attached on XCode?
My results are (Simulator / iPad mini 1st gen/ iPhone 5s):
png:                              69 /  388 / 197 ms
webp mixed mode:         86 /  613 / 219 ms
webp near lossless 40:   65 /  515 / 170 ms
webp lossless:             142 / 1090 / 372 ms

You don't even need a device to check, as simulator speed ratios are similar to iPhone 5s'.

Denis

[Pascal Massimino]

Hi Denis,

On Wed, Jan 11, 2017 at 7:20 AM, Denis <joyfuls...@gmail.com> wrote:

Hi skal,

Can we return to the issue? Could you run the simple project I attached on XCode?
My results are (Simulator / iPad mini 1st gen/ iPhone 5s):
png:                              69 /  388 / 197 ms
webp mixed mode:         86 /  613 / 219 ms
webp near lossless 40:   65 /  515 / 170 ms
webp lossless:             142 / 1090 / 372 ms

There is a bug in your timing code, at  SpeedTest.cpp:73

          fmt << "Webp (3) decode time: " << ((t5.tv_sec - t4.tv_sec) * 1000000 + t5.tv_usec - t3.tv_usec) / 1000 << "ms";

It should be:

          fmt << "Webp (3) decode time: " << ((t5.tv_sec - t4.tv_sec) * 1000000 + t5.tv_usec - t4.tv_usec) / 1000 << "ms";

Attached, a fixed version, along with the modified WebpTextureLoader.cpp file.

There were some leaks and error there some, nothing critical.

The timing measured on simulator and real devices are:

simulator (release)

2017-01-13 14:33:33.491 WebpSpeedTest[45824:1547781] Png decode time: 82ms

2017-01-13 14:33:33.491 WebpSpeedTest[45824:1547781] Webp (1) decode time: 94ms

2017-01-13 14:33:33.492 WebpSpeedTest[45824:1547781] Webp (2) decode time: 83ms

2017-01-13 14:33:33.492 WebpSpeedTest[45824:1547781] Webp (3) decode time: 184ms

simulator (release+fix)

2017-01-13 14:37:51.448 WebpSpeedTest[45898:1549860] Png decode time: 83ms

2017-01-13 14:37:51.448 WebpSpeedTest[45898:1549860] Webp (1) decode time: 95ms

2017-01-13 14:37:51.448 WebpSpeedTest[45898:1549860] Webp (2) decode time: 82ms

2017-01-13 14:37:51.449 WebpSpeedTest[45898:1549860] Webp (3) decode time: 98ms

iPhone 5s (release)

2017-01-13 14:31:38.149791 WebpSpeedTest[2357:163408] Png decode time: 150ms

2017-01-13 14:31:38.150036 WebpSpeedTest[2357:163408] Webp (1) decode time: 199ms

2017-01-13 14:31:38.150177 WebpSpeedTest[2357:163408] Webp (2) decode time: 181ms

2017-01-13 14:31:38.150327 WebpSpeedTest[2357:163408] Webp (3) decode time: 410ms

iPhone 5s (release+fix)

2017-01-13 14:40:36.103111 WebpSpeedTest[2376:165874] Png decode time: 142ms

2017-01-13 14:40:36.103359 WebpSpeedTest[2376:165874] Webp (1) decode time: 197ms

2017-01-13 14:40:36.103501 WebpSpeedTest[2376:165874] Webp (2) decode time: 177ms

2017-01-13 14:40:36.103635 WebpSpeedTest[2376:165874] Webp (3) decode time: 226ms

Note that i used the official framework[1] for timing.

I'll try to get new timing with the HEAD library soon.

hope it helps,

skal/

[1] https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-0.5.2-ios-framework.tar.gz

--

[Denis]

Hi skal,

Thank you for analyzing the test project, and sorry for a bug, which downperformed lossless packing!
But the original question still exists. No test shows us webp speed preference against png.

Denis

Hi Denis,

To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.

[Pascal Massimino]

Hi Denis,

On Mon, Jan 16, 2017 at 7:58 AM, Denis <joyfuls...@gmail.com> wrote:

Hi skal,

Thank you for analyzing the test project, and sorry for a bug, which downperformed lossless packing!
But the original question still exists. No test shows us webp speed preference against png.

Here are the timing results using the top-of-the-tree (not an official release yet. But soon!). There were

ARM optimizations that were not included in the bugfix-only 0.5.2 release. They speed things up noticeably:

iPhone 5s, Release, libwebp HEAD

2017-01-16 11:07:35.875859 WebpSpeedTest[2500:247560] Png decode time: 142ms

2017-01-16 11:07:35.875985 WebpSpeedTest[2500:247560] Webp (1) decode time: 178ms    [Original]      [5x smaller]

2017-01-16 11:07:35.876067 WebpSpeedTest[2500:247560] Webp (2) decode time: 152ms    [Nearlossless40][3x smaller]

2017-01-16 11:07:35.876308 WebpSpeedTest[2500:247560] Webp (3) decode time: 180ms    [Lossless]      [2x smaller]

With this input, the webp version will be slower to decode. Because more complex compression tools are required (there's color-transform and predictors

used, e.g.). This makes the decoding slower than for simpler sources like low-color icons e.g.

Still, the tradeoff is that you get a substantial size reduction for extra decoding time. Up to 5x for Original, which i'd say is quite interesting for game assets.

All in all, Nearlossless40 does look interesting in your case: 7% slower decoding than PNG, for a 3x size saving.

hope it helps,

skal/

To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss+unsubscribe@webmproject.org.

[Denis]

Hi skal,

Thanx, I'll keep an eye to the official release notification.
And sure, you are completely right about size/speed tradeoffs, and NearLossless40 seems cool!
But... I hoped for a silver bullet, as on PC... :)

Denis

[Denis]

Hi skal,

BTW, is there a way to know about stable releases? Mailing list or so?

Denis

[Pascal Massimino]

Hi Denis,

On Mon, Jan 16, 2017 at 8:14 AM, Denis <joyfuls...@gmail.com> wrote:

Hi skal,

BTW, is there a way to know about stable releases? Mailing list or so?

This mailing list is where the announcement for release (and release candidates) are made.

Just search for "[ANN]" in the message subjects [2].

Also, the developer pages[1] are updated shortly after with the latest archives. 

skal/

[1] https://developers.google.com/speed/webp/download

[2] https://groups.google.com/a/webmproject.org/forum/#!searchin/webp-discuss/%5BANN%5D%7Csort:date

To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss+unsubscribe@webmproject.org.

[Denis]

Thanx, skal!