Issue 486 in webp: Poor quality on ARM Cortex-M7 processor (IAR Compiler)

[vam… via monorail]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 486 by vam...@gmail.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486

What steps will reproduce the problem?

The following steps are also in ReadMe.txt

1- Download and install the "IAR Embedded Workbench for Arm" 30 days free demo from:
https://www.iar.com/iar-embedded-workbench/#!?currentTab=free-trials

Note: no need to install "Probe drivers" nor "Dongle drivers"

2- Open IAR Embedded Workbench and:
- click on menu: "File->Open workplace"
navigate to "webpTest.eww"

Note: you may need to accept/activate your demo license.

3- Enable a break point in line #88 (while instruction).

4- Run the program. It will take ~10 seconds to reach the breakpoint

5- Check the values of the variables img_out and img_out_idx (use a "watch" windows by "View->Watch->Watch 1")

the values will probably match the following:
img_out = 0x8000afc8
img_out_idx = 308

6- Save the output buffer the the desktop by "Debug->Memory->Save"
The Start Address is img_out (likely 0x8000afc8)
The End Address is img_out + HEX(img_out_idx) =
0x8000afc8 + HEX(308) =
0x8000afc8 + 0x134 = 0x8000b0fc
End Address = 0x8000b0fc

7- Run the python script to extract the binaries from the hex file:

python hex_to_bin.py memory.hex memory.webp

8- Open memory.webp in a webp app to visualize it (Chrome/Firefox/Gimp/etc)


What is the expected output?
A "Test" Image with smooth gray gradient on background

What do you see instead?
A "Test" Image with very high compression but pixelated (See Screenshots folder)


What version of the product are you using? On what operating system?
IAR Workbench 8.50.6


Please provide any additional information below.
Project is attached for reproducing the issue. No embedded hardware is required as IAR has a ARM emulator already configure in the project.

Attachments:
webpTest.zip 722 KB

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[jz… via monorail]

Comment #1 on issue 486 by jz...@google.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c1

For posterity the source of this report was a thread on webp-discuss [1]. The images from that thread are attached.

[1] https://groups.google.com/a/webmproject.org/g/webp-discuss/c/op9vojdC89s/m/ZVKdGJbcAwAJ

Attachments:
images.zip 8.5 KB

[vam… via monorail]

Comment #2 on issue 486 by vam...@gmail.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c2

I am also adding my libwebp "example" folder with "cwebp" with more verbose. Compiled on MacOSX.
It should be easier to compare the embedded and desktop encodings to find the difference.

test.pgm is the very same image than embedded in IAR project code. On Mac ise the command:

./cwebp -q 80 test.pgm -o test.webp

Attachments:
examples.zip 2.6 MB

[jz… via monorail]

Updates:
Status: Started

Comment #3 on issue 486 by jz...@google.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c3

Thanks for the build instructions. One issue I see is that in the sample code you're using memset to clear both the picture and config. They both start with this underneath, but you miss some defaults by skipping WebPConfigInit [1]. qmax is 0 in the old code. This should improve things, but I haven't checked whether things are bitwise exact yet.

Aside from the settings the chip supports NEON, does the device? Given it's armv7 the *_neon.c files will need to be flagged explicitly with -mfpu=neon [2]. That will help with performance if it's available.

[1]
// Replace these calls with the Init()s and check their returns.
// memset(c, 0, sizeof(WebPConfig));
// memset(p, 0, sizeof(WebPPicture));
WebPPictureInit(p);
WebPConfigInit(c);

c->quality = 80.000000;
c->method = 4;
c->segments = 4;
c->sns_strength = 50;
c->filter_strength = 60;
c->filter_sharpness = 0;
c->filter_type = 1;
c->alpha_compression = 1;
c->alpha_filtering = 1;
c->alpha_quality = 100;
c->pass = 1;
c->near_lossless = 100;

[2] https://chromium.googlesource.com/webm/libwebp/+/refs/heads/master/configure.ac#171

[jz… via monorail]

Comment #4 on issue 486 by jz...@google.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c4

That seems to have been it. If I compile the main.c from webPTest.zip on Linux I get the same output as under the embedded workbench [1]. Note that's using img_out_idx - 1, you picked up an extra byte in (6) in the original post.

[1] a0511549265ae1ed2a8f9cc0781ab21c memory.webp

[vam… via monorail]

Comment #5 on issue 486 by vam...@gmail.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c5

My bad James, you are right. It is working now. Cortex-M7 does not have NEON and it is taking ~6 seconds to encode. JPEG takes ~1.5 sec.
It is also generating larger output than JPEG. However, for quality < 20 WebP looks better.
One thing is that I may not be setting up WebP properly for Grayscale 8. The libjpeg does handle it
So the question is if there is an way to better use linwebp for Grayscale 8 (other than faking u and v = 128).

[jz… via monorail]

Comment #6 on issue 486 by jz...@google.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c6

Without NEON your best option for performance will be to make sure -O2 and/or arm mode are used for the library if you can tolerate the size increase from -Os (or similar optimize for size) and thumb mode.

For monochrome images your technique is the best option. We have a helper function for that as well [1].

[1] https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v1.1.0/extras/extras.c#32

[vam… via monorail]

Comment #7 on issue 486 by vam...@gmail.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c7

We will turn on optimization for speed as we have lots of flash space available.
Thanks for everything.

[jz… via monorail]

Updates:
Status: Done

Comment #8 on issue 486 by jz...@google.com: Poor quality on ARM Cortex-M7 processor (IAR Compiler)
https://bugs.chromium.org/p/webp/issues/detail?id=486#c8

I'm glad everything is working for you. Thanks again for putting together the report. If you run into any other issues please feel free to file a new bug or ask about it on the mailing list.