#1694 closed task (fixed)
re-add webp codec
Reported by: | Antoine Martin | Owned by: | J. Max Mena |
---|---|---|---|
Priority: | major | Milestone: | 2.2 |
Component: | encodings | Version: | trunk |
Keywords: | Cc: |
Description
It was removed in r14508 as part of a codec cleanup.
The main problems with it were that:
- the distro libraries were often way too old - which is still the case in Debian land (no surprises there)
- the performance was inadequate in some cases
After playing with it on Fedora 27 with libwebp 0.6.0, it seems that there are settings we can use that will give us better compression and better performance than png. And we should be able to avoid using it for the cases where it isn't adequate.
We need something better than png to avoid using up all the bandwidth with lossless refresh. (see ticket:999#comment:20 for details)
Attachments (2)
Change History (10)
comment:1 Changed 2 years ago by
Status: | new → assigned |
---|
comment:2 Changed 2 years ago by
doh: we were forcing speed=100 when quality=100 (lossless).
Hardcoding the "method" to 0 (fast) and lossless mode (quality=100), we can fine tune the time spent compressing by setting webp's "quality" attribute (which has nothing to do with quality in this case..) - but the resulting output size remains pretty much the same!
Setting the method to 1 or higher and the compression becomes too slow (250ms or more), for only 1 percentage point of extra compression!
The reason why Pillow was doing better is that it wasn't doing true lossless as the quality value was clamped to 99 in our code!
comment:3 Changed 2 years ago by
Owner: | changed from Antoine Martin to J. Max Mena |
---|---|
Status: | assigned → new |
- r17467 adds support for it in the html5 client,
- r17468 re-adds the "webp" encoding (+r17469 build fixup for win32), and since the speed and quality settings are now much improved (no thanks to the complete lack of documentation on what those knobs do), we will use webp ahead of png in most cases. This should help with #999.
- r17471 + r17483: use webp more
- r17473 + r17474: build pillow without webp on centos7 to prevent conflicts between the host libwebp library and our private library - note: we no longer use private libraries for webp on Fedora (the spec file refuses to build there)
In debug mode, webp is shown using a pink contour colour as before.
All builds should have the correct dependencies added, including macos and win32 builds.
@maxmylyn: mostly a FYI, testing wouldn't hurt but feel free to just close.
Changed 2 years ago by
Attachment: | load-pillow-last.patch added |
---|
I don't think this is needed as long as pillow doesn't link with libwebp
comment:4 Changed 2 years ago by
Updates:
- r17483: can use webp at high res
- r17492: add threshold so we use webp in lossless mode for quality above 75%
Interesting thing I spotted during bandwidth tuning for #999, webp can compress the xterm in lossless mode 40 times better than when using lossy compression!
compress: 10.5ms for 499x316 pixels at 0,0 for wid=1 using webp \ with ratio 23.0% ( 615KB to 141KB), sequence 74, \ client_options={'quality': 99, 'speed': 97, 'rgb_format': 'RGBX'} compress: 2.6ms for 499x316 pixels at 0,0 for wid=1 using webp \ with ratio 0.6% ( 615KB to 3KB), sequence 75, \ client_options={'quality': 100, 'speed': 50, 'rgb_format': 'RGBX'}
Time for some window hints to make better guesses at what compression to use: #1699.
comment:6 Changed 2 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Noted. I'll also make a note to myself to add it to the test box.
Closing.
comment:7 Changed 2 years ago by
Found a bug with the non-opengl rendering: the red and blue channels would end up swapped.
That's because the webp encoder compresses BGRA (or BGRX) as input, so if it was fed "RGBA" (or "RGBX") then we have to swap the channels when decoding.
The correct fix is a bit long but it does make sense: r17688.
comment:8 Changed 2 years ago by
r17697 is a more complete end-to-end fix: the client tells the server which RGB modes it can handle for webp.
This fixes the potential problem where the HTML5 client would be asked to decode a swapped-channels-webp image. This could happen if we had a server that fed "RGBX" (or "RGBA") to the encoder instead of "BGRX" (or "BGRA"). ie: maybe on a little endian arch?
A very quick and dirty test with glxspheres at 1240x900 with speed=100 and quality=100 shows:
The pillow webp code is much slower (~100ms), but it also compresses better: the size is just 2.5%! So clearly we can do better with this codec, I'm just not sure how yet. Undoing all the configuration we do, the same image takes 2 seconds to compress! (and the gains really aren't worth it: only 6.5% compression ratio)
Here are the settings that we use when trying to go for maximum lossless compression:
The only major problem with this is that my xterm window comes out all black. (but the glxspheres window looks fine!)
Sadly, not many browsers support webp, but chrome does and we should be able to detect webp support.