WebP 2: experimental successor of the WebP image format

[Jyrki Alakuijala]

Update: latest ToT commit 6b0aaad of libwebp2 should behave better on the typical photo-like sources that were used in this comparison...

(ex. at 'small' : cwp2 -q 50 ...Attachment 8194 - 108329b)

Looks great. This is a substantial improvement! Now there is brick texture on the building.

If a neural codec is optimized for RGB/YUV color difference it creates a sky like in this WebP2 image, but if optimized for XYB, it creates a sky like we have in the JPEG XL image. Could be a good idea to try a more advanced colorspace -- perhaps try Lab or ICtCp if XYB is too untested for your preference. A modernized colorspace is very likely to fix some of the remaining issues in the sky.

Oklab is very similar to XYB, and while it has -- in my view -- too much S participation in Luma, would likely be able to get colors right. I'd guess it would have only 5 % disadvantage over XYB for image compression. For large constant colors it is likely more information efficient than XYB, but that is not where the information is in image compression.

[cssignet]

pure speculation according to my precedent tests, i did not check the code yet, but it seems that predictors would not be tried on paletted samples atm? also, is 'Palette' mode would be limited to 256 colors? if y, any specific reason?

[skal]

pure speculation according to my precedent tests, i did not check the code yet, but it seems that predictors would not be tried on paletted samples atm? also, is 'Palette' mode would be limited to 256 colors? if y, any specific reason?

Yes, it's not done yet (colormap + predictors) but should come 'soon'. We want first to move the lossless code to work with signed int16 instead of uint8 like before.
And yes, there's no reason to limit the palette to 256 colors.

[e8c]

convert: Maximum supported image dimension is 65500 pixels `big.jpg' @ error/jpeg.c/JPEGErrorHandler/322.

(UPD: I know about , but next link could be helpful any way.)
​
https://askubuntu.com/questions/1041349/imagemagick-command-line-convert-limit-values

$ /bin/time -f '\nUser time (seconds): %U\nMemory (kbytes): %M' \
​> ./guess -1 PIA23623_hires.ppm PIA23623_hires.guess
encode,   2 threads:   112 MPx/s

User time (seconds): 35.60
Memory (kbytes): 7743864
$ ls -l
total 12539741
-rwxrwx--- 1 root vboxsf 1794025332 янв 15 16:49 PIA23623_hires.guess
-rwxrwx--- 1 root vboxsf 2293756771 янв 15 15:56 PIA23623_hires.png
-rwxrwx--- 1 root vboxsf 6115804597 янв 15 15:20 PIA23623_hires.ppm
-rwxrwx--- 1 root vboxsf 2425213852 янв 14 02:08 PIA23623_hires.tif

VM: 2 v-Cores, 11 GB RAM
Host: Intel NUC8i3, SATA SSD

"35.60 seconds" is sum of 2 threads, about 18 s in user space.
(Said for those who are not familiar with profiling multi-threaded applications.)
Respectively: 8 cores - 4.5 s, 16 cores - 2.25 s, 32 cores - 1.125 s.

It is acceptable.

Most (if not all) of the imaging software i have on my desktop/laptop/phone will crash miserably handling a 2.43GB image (in whichever format).

See attachment. (Site engine converts PNG to JPG, why?)

[cssignet]

​

predictors would not be tried on paletted samples atm

571c204:

>cwp2 -q 100 -effort 1 -mt 8 box.png
output size:  70990 (2.17 bpp)
Kernel Time  =     0.000 = 00:00:00.000 =   0%
User Time    =     0.265 = 00:00:00.265 = 282%
Process Time =     0.265 = 00:00:00.265 = 282%
Global Time  =     0.094 = 00:00:00.094 = 100%

>cwp2 -q 100 -mt 8 box.png
output size:  60658 (1.85 bpp)
Kernel Time  =     0.015 = 00:00:00.015 =   4%
User Time    =     1.031 = 00:00:01.031 = 314%
Process Time =     1.046 = 00:00:01.046 = 319%
Global Time  =     0.328 = 00:00:00.328 = 100%

3db306e:

>cwp2 -q 100 -effort 1 -mt 8 box.png
output size:  55907 (1.71 bpp)
Kernel Time  =     0.015 = 00:00:00.015 =  10%
User Time    =     0.437 = 00:00:00.437 = 280%
Process Time =     0.453 = 00:00:00.453 = 290%
Global Time  =     0.156 = 00:00:00.156 = 100%

>cwp2 -q 100 -mt 8 box.png
output size:  50733 (1.55 bpp)
Kernel Time  =     0.046 = 00:00:00.046 =   8%
User Time    =     1.828 = 00:00:01.828 = 334%
Process Time =     1.875 = 00:00:01.875 = 342%
Global Time  =     0.547 = 00:00:00.547 = 100%

[cssignet]

- do you think there is room for improvement in encoding speed (if y, by how much distance from v1 efficiency?)
- would you plan to let straight alpha and preserve RGB if a=0? (or is it possible atm? — i did not check)

[skal]

Glad you noticed the introduction of palette + predictors

- do you think there is room for improvement in encoding speed (if y, by how much distance from v1 efficiency?)

Yes, since right now it's doing a pretty exhaustive search for predictors and transforms to apply. Going forward, some heuristic will help.

- would you plan to let straight alpha and preserve RGB if a=0? (or is it possible atm? — i did not check)

We're trying to work with premultiplied Argb as much as possible. Means the RGB can't be really preserved under alpha=0 (it's rather a niche use-case, despite regular complaints about it, even for v1 where we introduced the -exact flag).

​