WebP2 image codec

[skal]

Hi,

libwebp2 has been open-sourced (here (https://chromium.googlesource.com/codecs/libwebp2/)), and i see some users reporting compilation issues (example (https://forum.doom9.org/showthread.php?p=1928883#post1928883)).

Best is to start this thread proper and consolidate the reports here!

skal/

(tests welcome, too. Keep in mind the code is changing on a ~weekly basis, though!)

[Jamaika]

Errors can probably be added on the google forum. I create non-professional codecs in GCC. On Windows there is Visual Studio and others that have assembler and simd support.
Codec WebP2 works without AOM codecs. So all other AOM add-ons ie AVIF, DV1D, GAV1 will also not work under GCC.

[skal]

Errors can probably be added on the google forum.

Yes, compile errors with details should be reported there:

https://bugs.chromium.org/p/webp2/issues/list

I create non-professional codecs in GCC. On Windows there is Visual Studio and others that have assembler and simd support.
Codec WebP2 works without AOM codecs. So all other AOM add-ons ie AVIF, DV1D, GAV1 will also not work under GCC.

These pre-compiled binaries links can be posted here, indeed.

[skal]

Btw, for definiteness here are some command line examples if you want to test encoding / decoding:

cwp2 cat.png -o cat.wp2 -d cat.wp2.png -q 44

avifenc --min 40 --max 40 -s 2 cat.png cat.avif
avifdec cat.avif cat.avif.png

cwebp cat.png -o cat.webp -q 16
dwebp cat.webp -o cat.webp.png

====

[benwaggoner]

So, this is an enhanced encoder for the VP8 "WebP" format?

Do we care about WebP? I've not really seen exciting real-world implementations that were enough better than JPEG to merit the extra work, or close enough to HEIF H.264 that building a JavaScript implementation of that leveraging HW H.264 decoders wouldn't make more sense at scale. And AVIF is certainly going to outperform WebP while addressing the same licensing goals.

[VoodooFX]

Do we care about WebP?
I see up to ~50% better compression over PNG in my use scenarios.

[IgorC]

Do we care about WebP?
I see WebP quite ofent in internet.

Chrome/Firefox/Edge support WebP.
Such popular sites in Latin America as www.mercadolibre.com uses WebP.

I've not really seen exciting real-world implementations that were enough better than JPEG ...
This is far from reality (as many other of your statements regarding VP8/VP9/AV1)

WebP has its advantages on certain range of bitrates https://www.reddit.com/r/AV1/comments/jp9w41/why_webdevelopers_should_use_avif_comparison/

[skal]

So, this is an enhanced encoder for the VP8 "WebP" format?

Do we care about WebP? .

Hmm... if you missed the last 10 years of WebP development, i made a recap presentation here: http://shorturl.at/BEMV8

And yes, it's used a lot.

[Jamaika]

Btw, for definiteness here are some command line examples if you want to test encoding / decoding:

cwp2 cat.png -o cat.wp2 -d cat.wp2.png -q 44

avifenc --min 40 --max 40 -s 2 cat.png cat.avif
avifdec cat.avif cat.avif.png

cwebp cat.png -o cat.webp -q 16
dwebp cat.webp -o cat.webp.png
====
My test
dwp2.exe -v image_21447.wp2 -mt -o image_21447_64bit.jpg
Time to decode picture: 0.415s
Decoded image_21447.wp2. Dimensions: 1563 x 1558. Transparency: no.
Could not save to 'image_21447_64bit.jpg'
Error: unsupported feature
Status: WP2_STATUS_UNSUPPORTED_FEATURE
dwp2.exe -v image_21447.wp2 -mt -o image_21447_64bit.webp
Time to decode picture: 0.399s
Decoded image_21447.wp2. Dimensions: 1563 x 1558. Transparency: no.
Could not save to 'image_21447_64bit.webp'
Error: unsupported feature
Status: WP2_STATUS_UNSUPPORTED_FEATURE

avifenc and avifdec are a different library, unless something else has been added in the meantime.
Strange settings help av1enc. 'O' is not output and 'D' is not decode. What does not working 'o' and 'd' mean?
av1enc.exe -444 -size 1563x1558 -O image_21447_64bit.png
aom_codec_decode() failed.
Error compressing to AV1
Troublesome creating avif because you have to enter size image and chroma subsampling every time. Why are photos in webp2 and addons only 8bit? Additionally, to generate avif you need to add avif which is saved as av1.
To produce the avif with png you must add the 'D'. Why?
av1enc.exe -avif -420 -size 1563x1558 -D image_21447_64bit.avif -O image_21447_64bit.png
674650 35.965336 (99.000000 35.446957 39.947750 34.281830) [ 2.22 bpp ] [ 1563 x 1558 ] [73.223 / 0.632 secs]
Saved decoded image image_21447_64bit_dec.png
Saved encoded file: image_21447_64bit.av1 (674650 bytes) <-- ????
but
av1enc.exe -avif -444 -size 1563x1558 -D image_21447_64bit.avif -O image_21447_64bit.png
ERROR: Failed to encode: Decoding of color planes failed
Error while computing the distortion.
I will just add that when compiling libavif you should include the definition of IO. AVIF_CODEC_AOM, AVIF_CODEC_AOM_DECODE, AVIF_CODEC_AOM_ENCODE. This is an exception. Without this the accessory will not work.
File decoding RAW converted as TIFF RAW_CANON_EOS_5DS.cr2 8688x5792
Long waiting time. On my old computer thread 4 it is about 10 minutes.
cwp2.exe RAW_CANON_EOS_5DS.tiff -summary -lossless -mt -o RAW_CANON_EOS_32bit.wp2
Assertion failed: std::abs(progress_ + kProgressEnd - 1.f) < 0.001f, file progress_watcher.cc, line 52
Does WEBP2 codec handle metadata? Who knows that?

[skal]

My test
...
Could not save to 'image_21447_64bit.jpg'
Error: unsupported feature
Status: WP2_STATUS_UNSUPPORTED_FEATURE


That's expected: you cannot save to a lossy format (jpg, webp), since it would defeat the purpose of showcasing WP2's compression capabilities.

[skal]

...
aom_codec_decode() failed.

Sorry, i'm not an avifenc/avifdec specialist, just tried it quickly on Unix.


Why are photos in webp2 and addons only 8bit?

If you are interesting in non-8bit input/output, you can have a look at some tools in the 'extras (https://chromium.googlesource.com/codecs/libwebp2/+/refs/heads/master/extras/)' directory. For instance 'ewp2'. They can handle Y4M format.


File decoding RAW converted as TIFF RAW_CANON_EOS_5DS.cr2 8688x5792
Long waiting time. On my old computer thread 4 it is about 10 minutes.

Yes, lossless coding can be quite slow for such large photos. Note that compressing losslessly photo material is not the main use-case case WebP2 is targetting!


Assertion failed: std::abs(progress_ + kProgressEnd - 1.f) < 0.001f, file progress_watcher.cc, line 52


This is a know problem that has been fixed in the latest sync patch (https://chromium.googlesource.com/codecs/libwebp2/+/df4ec90a2befb79ed45cf8810e8ac93da7a47297).
You may want to recompile at HEAD to fix it (commit df4ec90a2befb79ed45cf8810e8ac93da7a47297).


Does WEBP2 codec handle metadata? Who knows that?
Yes. By default, cwp2 will copy EXIF, XMP and ICC metadata.

[Scope]

WebP 2 df4ec90, MinGW 64, GCC 10.2.0

dwp2
[ 90%] Building CXX object CMakeFiles/dwp2.dir/examples/dwp2.cc.obj
C:/msys64/home/Scope/libwebp2/examples/dwp2.cc: In function 'std::string {anonymous}::PrintSummary(const WP2::BitstreamFeatures&, size_t, bool)':
C:/msys64/home/Scope/libwebp2/examples/dwp2.cc:207:37: error: unknown conversion type character 'z' in format [-Werror=format=]
207 | str += SPrintf("file size: %zu\n", input_data_size);
| ^
[ 91%] Building CXX object CMakeFiles/extras.dir/extras/extras.cc.obj
cc1plus.exe: all warnings being treated as errors
make[2]: *** [CMakeFiles/dwp2.dir/build.make:82: CMakeFiles/dwp2.dir/examples/dwp2.cc.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:261: CMakeFiles/dwp2.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

CMakeError.log
Performing C++ SOURCE FILE Test WP2_HAVE_FLAG___SSE4_2__ failed with the following output:
Change Dir: C:/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp

Run Build Command(s):C:/msys64/usr/bin/make.exe cmTC_f9854/fast && /usr/bin/make -f CMakeFiles/cmTC_f9854.dir/build.make CMakeFiles/cmTC_f9854.dir/build
make[1]: Entering directory '/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_f9854.dir/src.cxx.obj

/C/msys64/mingw64/bin/g++.exe -DWP2_HAVE_FLAG___SSE4_2__ -o CMakeFiles/cmTC_f9854.dir/src.cxx.obj -c /C/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp/src.cxx
C:/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp/src.cxx: In function 'int main()':
C:/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp/src.cxx:4:9: error: invalid use of 'this' in non-member function
4 | this is not valid code
| ^~~~
make[1]: *** [CMakeFiles/cmTC_f9854.dir/build.make:85: CMakeFiles/cmTC_f9854.dir/src.cxx.obj] Error 1
make[1]: Leaving directory '/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:140: cmTC_f9854/fast] Error 2

Source file was:
int main(void) {
#if !defined(__SSE4_2__)
this is not valid code
#endif
return 0;
}

[skal]

WebP 2 df4ec90, MinGW 64, GCC 10.2.0
...



Thanks for the report, opened an issue (https://bugs.chromium.org/p/webp2/issues/detail?id=5) for it.

[Jamaika]

Yes. By default, cwp2 will copy EXIF, XMP and ICC metadata.
If I'm wasting my time I'm a bit of a piss off the creators. :D
Converting DNG to WEBP2 with metadata ICC, XMP, EXIF
TIFFFetchNormalTag: Warning, Incorrect value for "RichTIFFIPTC"; tag ignored.
Dimension: 5212 x 3468
animation: no
quality hint: 15
preview: no
preview color: 102, 85, 51
rotated by: 0 degrees clockwise
transfer: 0
ICC: no <-- ???
XMP/EXIF: no <-- ???
output size: 31860621 (14.10 bpp) [RAW_CANON_EOS_32bit.wp2]

What should be the config for libtiff? The library includes RichTIFFIPTC.

[skal]

TIFFFetchNormalTag: Warning, Incorrect value for "RichTIFFIPTC"; tag ignored.
...
What should be the config for libtiff? The library includes RichTIFFIPTC.



Hard to say without more details, the source image, compile flags, exact libtiff library version used, etc.

Best is to open an issue on the bug tracker (https://bugs.chromium.org/p/webp2/issues/list), with all the infos. But it looks like a libtiff issue, honestly...

[Jamaika]

Everything is here. The rest for those willing.
New codecs, untestet with bugs fixed 25.11.2020
https://www.sendspace.com/file/dbx3jx
Added:
https://chromium.googlesource.com/codecs/libwebp2/+/df4ec90a2befb79ed45cf8810e8ac93da7a47297
https://gitlab.com/libtiff/libtiff/-/commit/9dce07a777c01ec1d77ccc90cf81479c267febaa
https://github.com/m-ab-s/aom/commit/780a9e54d32b8af569d93ac482339afb1c3baaf5
https://github.com/AOMediaCodec/libavif/commit/894200ce824eebeffb7eaf7c78ee872c78c0bdb9
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/d523435e18dde75d936db8c15be2cc49cde3b1ac
https://github.com/webmproject/libwebp/commit/d2e245ea9e959a5a79e1db0ed2085206947e98f2
https://github.com/dcnieho/FreeGLUT/commit/349a23dcc1264a76deb79962d1c90462ad0c6f50
https://github.com/glennrp/libpng/commit/dbe3e0c43e549a1602286144d94b0666549b18e6
https://github.com/madler/zlib/commit/53ce2713117ef2a8ed682d77b944df991c499252
GCC 10.2.1 http://msystem.waw.pl/x265/mingw-gcc1021-20200926.7z

[skal]

latest submit 7c0dceb (https://chromium-review.googlesource.com/c/codecs/libwebp2/+/2560101) should fix the %zu problem.

It also introduced some ~10-15% speed-up on x86 contribution (thanks Ilya!) and a '-progress' option to cwp2/dwp2 to report the enc/dec progress.


thx!

[Scope]

WebP 2 7c0dceb, MinGW 64, GCC 10.2.0

[ 89%] Built target ansz
C:/msys64/home/Scope/libwebp2/examples/example_utils.cc: In function 'std::string WP2::PrintSummary(const WP2::BitstreamFeatures&, size_t, bool)':
C:/msys64/home/Scope/libwebp2/examples/example_utils.cc:157:20: error: unknown conversion type character 'l' in format [-Werror=format=]
157 | str += SPrintf("file size: %" PRIu64 "\n", (uint64_t)input_data_size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus.exe: all warnings being treated as errors
make[2]: *** [CMakeFiles/example_utils.dir/build.make:82: CMakeFiles/example_utils.dir/examples/example_utils.cc.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:463: CMakeFiles/example_utils.dir/all] Error 2
make: *** [Makefile:160: all] Error 2

This may be related to Microsoft's printf https://stackoverflow.com/questions/10763854/printf-and-llx-in-gcc-under-windows-64x

CMakeError.log
Performing C++ SOURCE FILE Test WP2_HAVE_FLAG___SSE4_2__ failed with the following output:
Change Dir: C:/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp

Run Build Command(s):C:/msys64/usr/bin/make.exe cmTC_f12f3/fast && /usr/bin/make -f CMakeFiles/cmTC_f12f3.dir/build.make CMakeFiles/cmTC_f12f3.dir/build
make[1]: Entering directory '/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_f12f3.dir/src.cxx.obj

/C/msys64/mingw64/bin/g++.exe -DWP2_HAVE_FLAG___SSE4_2__ -o CMakeFiles/cmTC_f12f3.dir/src.cxx.obj -c /C/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp/src.cxx
C:/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp/src.cxx: In function 'int main()':
C:/msys64/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp/src.cxx:4:9: error: invalid use of 'this' in non-member function
4 | this is not valid code
| ^~~~
make[1]: *** [CMakeFiles/cmTC_f12f3.dir/build.make:85: CMakeFiles/cmTC_f12f3.dir/src.cxx.obj] Error 1
make[1]: Leaving directory '/home/Scope/libwebp2/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:140: cmTC_f12f3/fast] Error 2

Source file was:

int main(void) {
#if !defined(__SSE4_2__)
this is not valid code
#endif
return 0;
}

[Jamaika]

I would also add this in vwp2.cc:
#if defined(__unix__) || defined(__CYGWIN__)
} else if (key == 'x' || key == 'X') {
Modify(wp2dbg_value_, 2u, key == 'x');
setenv("WP2DBG", (wp2dbg_value_ == 0) ? "0" : "1", 1);
if (!EncodeAndDecode()) return;
AddInfo(SPrintf("export WP2DBG=%d", wp2dbg_value_));
#endif
I would also add this in av1enc.cc:
#if defined(__unix__) || defined(__CYGWIN__)
for (size_t i = 0; i < std::max((size_t)1, env_vars.size()); ++i) {
#endif
...
#if defined(__unix__) || defined(__CYGWIN__)
if (!env_vars.empty()) {
setenv(env_vars[i].first.c_str(), env_vars[i].second.c_str(), 1);
if (env_vars.size() > 1) {
// Only append it to the file name if there are several env vars.
suffix = "_" + env_vars[i].first;
if (!env_vars[i].second.empty()) suffix += "_" + env_vars[i].second;
}
}
#endif
...
#if defined(__unix__) || defined(__CYGWIN__)
if (!env_vars.empty()) {
unsetenv(env_vars[i].first.c_str());
}
#endif
...
#if defined(__unix__) || defined(__CYGWIN__)
}
#endif

[skal]

I would also add this in vwp2.cc:
...


looks like we need a replacement for setenv/getenv under Windows env. Thanks for pointing this out!

[Scope]

WebP 2 + dlls [3724e16] [Windows][GCC 10.2.0][64 bit] (https://cdn.discordapp.com/attachments/673202643916816384/785551484922101760/webp2-mingw64-3724e16.7z)
WebP 2 + dlls [377656e] [Windows][GCC 10.2.0][64 bit] (https://cdn.discordapp.com/attachments/673202643916816384/785930879083610153/webp2-mingw64-377656e.7z)

[Marsu42]

Do we care about WebP?

Personally, I do care because webp has the highest lossless compression I've seen - making it my photo archival format, esp. because it still has fast decoding (unlike flif and other specialized codecs). A common fallacy seems to be that webp uses yuv/vp8 for lossless - but it's rgba and afaik a separate implementation added independently from the video codec legacy.

That's why I'm very excited to read about "improved lossless compression" and "full 10bit architecture (HDR10)" in "What to expect?" and I am keen to see comparisons 1.0 vs. 2.0 lossless.

Webp is added to most browsers, a lot of image viewers - so it might be possible that these will be quickly upgrading to 2.0 (except for older Android)

I see up to ~50% better compression over PNG in my use scenarios.

I'm recompressing all png as webp, saving a lot of space even though they are only image formats. I'm using the built-in pre-processing, which some might see as a hack and of course this is somewhat possible with png, too - but webp is very efficient at it.

Re-compressing gif animated webp is still a bit tricky since results vary (esp. with dithering in the gif), recompression is slow, and some image viewers only support non-animated webp

Note that compressing losslessly photo material is not the main use-case case WebP2 is targetting

I hope you're still optimizing it, because imho webp lossless is terrific - I don't care that much about compression time, but decompression has to be rather swift even for larger images. At least webp seems to be designed with loessless hdr in mind, while avif results are rather disappointing atm because av1 isn't really tuned for intra-only compression - and lossless avif seems a bit like a hack.

I'd really like to stop looking for an image archival format that supports hdr (12bit would be better though for dslr images...), has lossless compression with a high ratio plus fast decompression _and_ is widely supported... and I've tried just about anything that is out there.

libwebp2 has been open-sourced

Is the bitstream finalized and the lib ready enough so we can begin asking devs of image viewers to upgrade?

WebP 2 [b77ef4c] [Windows][GCC 10.2.0][64 bit]

This depends on a _lot_ of mingw shared dll - could you like them as static so this is stand-alone?

[skal]

I hope you're still optimizing it, because imho webp lossless is terrific - I don't care that much about compression time, but decompression has to be rather swift even for larger images.


Yes, lossless Photos are still on the radar, although probably less than -say- lossless coding of game assets (which are photo-like, sometimes!).

Tiles should help regarding decoding speed of large images, if multithreading is acceptable.


Is the bitstream finalized and the lib ready enough so we can begin asking devs of image viewers to upgrade?


It's still evolving a lot, don't use the format for anything precious!
(note that there's a 'vwp2' tool for visualization and for playing with the compression parameters in the library).

[skal]

Regarding WebP2's triangle-based compression for previews, i've set up a demo page you might find amusing here:

https://codepen.io/skal65535/project/full/ZwnQWM

You can visualize the base64-strings resulting from running 'mk_preview -b64 ...'

[Jamaika]

Sorry for no comment. I put it on quickly.
av1enc.cc: In function 'int main(int, const char**)':
av1enc.cc:243:46: error: 'env_vars' was not declared in this scope
243 | for (size_t i = 0; i < std::max((size_t)1, env_vars.size()); ++i) {
| ^~~~~~~~
Fix defined
#if !defined(_WIN32)
} else {
const char symbol = (std::abs(v) >= (norm * 0.50)) ? 'X'
: (std::abs(v) >= (norm * 0.25)) ? 'x'
: '.';
line += SPrintf(" %c ", symbol);
#endif
}

[skal]

Sorry for no comment. I put it on quickly.
av1enc.cc: In function 'int main(int, const char**)':
av1enc.cc:243:46: error: 'env_vars' was not declared in this scope
243 | for (size_t i = 0; i < std::max((size_t)1, env_vars.size()); ++i) {
| ^~~~~~~~



thanks for testing -> should be fixed now, hopefully!

[Jamaika]

https://chromium.googlesource.com/codecs/libwebp2/+/3724e165a6df9260eb30b9a731a9f9594d3c5703

Compressing AV1 at quality 0.0...
aom_codec_decode(&codec, (const uint8_t*) bitstream.data(), (size_t) bitstream.size(), NULL) failed!

cwp2.exe image_21447.ppm image_21447.wp2 -summary -q 68 -nometadata -effort 9 -inplace
image_21447.ppm
Assertion failed: effort != 9 || angle_scores.back().score <= min_allowed_score, file predictor.cc, line 961

cwp2.exe image_21447.ppm -summary -q 68 -nometadata -effort 6 -csp 3 -o image_21447.wp2
Assertion failed: id < FeatureMap::kHistogramSize, file segment_enc.cc, line 415

cwp2.exe image_21447.ppm image_21447.wp2 -summary -q 68 -nometadata -effort 9 -csp 2 -inplace
image_21447.ppm
Error! Cannot encode 'image_21447.ppm' as WP2
Status: WP2_STATUS_INVALID_PARAMETER

[skal]

https://chromium.googlesource.com/codecs/libwebp2/+/3724e165a6df9260eb30b9a731a9f9594d3c5703

cwp2.exe image_21447.ppm image_21447.wp2 -summary -q 68 -nometadata -effort 9 -inplace
image_21447.ppm
Assertion failed: effort != 9 || angle_scores.back().score <= min_allowed_score, file predictor.cc, line 961
...


Thanks! Could you upload image_21447.ppm somewhere please?
(or on the bug-tracker https://bugs.chromium.org/p/webp2, even)

[benwaggoner]

Regarding WebP2's triangle-based compression for previews, i've set up a demo page you might find amusing here:

https://codepen.io/skal65535/project/full/ZwnQWM

You can visualize the base64-strings resulting from running 'mk_preview -b64 ...'
Very cool!

[Marsu42]

(tests welcome, too. Keep in mind the code is changing on a ~weekly basis, though!)

How do I enable 10-bit output, or is this auto-selected depending on 8/16 bit input, or not imlemented yet? Thanks.

[skal]

How do I enable 10-bit output, or is this auto-selected depending on 8/16 bit input, or not imlemented yet? Thanks.

The special tool extras/ewp2 can handle Y4M files with higher bit-depth samples.

./extras/ewp2 -h
Usage:
ewp2 in_file [-o out_file] [options]

Options valid if 'out_file' has the .wp2 or .webp extension:
-q <float> ........................ quality factor (0:small..100:big),
default=75.0
-effort <int> ..................... compression effort
(0:fast..9:slower/better), default=5
-csp <int> ........................ color space (wp2 only)

Options valid if 'out_file' has the .y4m extension (4:4:4 8b by default):
-depth <int> ...................... output bit depth per plane per sample
(8..12)
-444 .............................. 4:4:4 output samples (full chroma
resolution)
-420 .............................. 4:2:0 output samples (half chroma
resolution)

Options valid if 'in_file' and/or 'out_file' are 4:2:0:
-sampling <filter> ................ algorithm to use for up- and/or chroma
downsampling: smooth (default), nearest

Options valid if 'out_file' is specified:
-[no]metadata ..................... include [or exclude] input metadata in
output
-[psnr|ssim] <file path> <float> .. error returned if output (or input if no
given output) has a distortion worse
than specified compared to a reference
file

Other options:
-v ................................ verbose
-size ............................. print size and bits-per-pixel
-rm [A|R|G|B|Y|U|V] ............... set specified input channel(s) values to
opaque/black/grey
System options:
-noasm ............................ disable all assembly optimizations
-version .......................... print version number and exit
-h / -help ........................ this help

[Marsu42]

The special tool extras/ewp2 can handle Y4M files with higher bit-depth samples.

Um, so this preprocesses images to y4m (which in turn can be fed to the cwp2 compressor, to get a hdr .wp2 file), or is the y4m compressed but another container?

Sorry if I'm jumping the gun, I'm simply very excited to see webp lossless compression getting to 10 (and 12?) bit, it's not like I can use it a lot right now. In any case, I don't compile this myself atm, so someone needs to provide windows binaries @Jamaika, @Scope

[Scope]

I don't compile this myself atm, so someone needs to provide windows binaries @Jamaika, @Scope
Added ewp2, mk_preview and rd_curve to webp2-mingw64-3724e16.7z (but some dlls are also still required, since it takes me more time to compile completely static exe)

and I am keen to see comparisons 1.0 vs. 2.0 lossless.

I did a Lossless Image Formats Comparison, it's not completely finished yet, I want to update some results and add a more denser Jpeg XL compression mode (-s 9 -E 3, but it slows down the decoding a bit).

Some notes:
- there are Tabs for switching between different types of sets
- AVIF is lossless, but AVIF 444 is lossy (--cicp 1/13/1) the difference with the original looks like this https://i.imgur.com/MSCaY6E.png
- BMF is a closed format, slow for decoding, does not support alpha, but one of the most effective, selected only to understand the compression possibilities
- PNGs have been optimized (Pingo + ECT), the original PNGs are much larger (as can be seen in the PNG tab, where I made a comparison of the most effective and popular optimizers) https://i.imgur.com/Zj62IEi.png

Lossless Image Formats Comparison (Jpeg XL, AVIF, WebP 2, WebP, FLIF, PNG, ...) (https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/)

Some general results (although it is better to compare by types of sets, as they are not equal in correlation):
https://i.imgur.com/wBPoclW.png

[skal]

- PNGs have been optimized (Pingo + ECT), the original PNGs are much larger (as can be seen in the PNG tab, where I made a comparison of the most effective and popular optimizers) https://i.imgur.com/Zj62IEi.png


That's quite interesting: does it look like PingoA+Brotli is the best tradeoff in size x time ?


Lossless Image Formats Comparison (Jpeg XL, AVIF, WebP 2, WebP, FLIF, PNG, ...) (https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/)


thanks for spending time / watts testing this! Very useful.

skal/

[Scope]

That's quite interesting: does it look like PingoA+Brotli is the best tradeoff in size x time ?

Yes, but this is uncompressed PNG + Brotli compression (it is supported by browsers, but not by applications), so this is only a theoretical option for comparison, in other cases it is better to use Pingo + ETC (which I used to optimize all PNGs)

[jethro]

The special tool extras/ewp2 can handle Y4M files with higher bit-depth samples.

./extras/ewp2 -h
Usage:
ewp2 in_file [-o out_file] [options]


Options valid if 'out_file' has the .y4m extension (4:4:4 8b by default):
-depth <int> ...................... output bit depth per plane per sample
(8..12)
-444 .............................. 4:4:4 output samples (full chroma
resolution)
-420 .............................. 4:2:0 output samples (half chroma
resolution)



Hi Skal,
Will 4:4:4 sampling be included in the standard Webp2 decoder? What about 4:2:2? And why there is a split between normal and special encoders? Thanks.

[skal]

Jethro,

Hi Skal,
Will 4:4:4 sampling be included in the standard Webp2 decoder? What about 4:2:2? And why there is a split between normal and special encoders? Thanks.

4:4:4 is pretty much the only (internal) working space.
webp2 is able to use a mixed per-block 4:2:0 / 4:4:4 switch right now. But considering that 4:2:0 was invented for reducing the storage of *reference frames* in video sequence, it's highly possible we'll just drop it from webp2 and just work everything as 4:4:4 with special quantization tricks for emulating 4:2:0 blocks locally.
Memory consumption of reference storage is less a problem when you're trying to blit everything on screen on a per-row basis!

And as of 4:2:2, well, it has too much a smell of the interlaced fields from the past to be very relevant nowadays.

Right now, there's a split between special encoder (ewp2) and the everyday-use encoder (cwp2) because most of casual users (i mean, outside of this specialized forum) are mostly concerned about just transcoding their good-old 8b jpeg or PNG, and would be confused by all this new stuff like HDR10, Y4M, PQ, etc.
cwp2 is supposed to work off-the-bat for 99% of everyday users, and ewp2 is supposed to empower the savvy curious ones.
Eventually they'll converge...

[Marsu42]

I did a Lossless Image Formats Comparison, it's not completely finished yet, I want to update some results and add a more denser Jpeg XL compression mode (-s 9 -E 3, but it slows down the decoding a bit).

That's great, thanks, that'll save me a lot of time doing it myself :-)

Why didn't you include heic (i.e. hevc-compression), as it's another currrent video codec with a widely used image spin-off? The performance seems to be somewhere between avif and webp, with the same problem for true rgb mode.

I'm currently trying to figure out how to do rgb-lossless heic: https://forum.doom9.org/showthread.php?p=1930194#post1930194


- AVIF is lossless, but AVIF 444 is lossy (--cicp 1/13/1) the difference with the original looks like this https://i.imgur.com/MSCaY6E.png

Um, could anyonye please evaluate what this means - since 'real' lossless avif seems to be off the charts, is 444-avif (and probably the same for hevc-heic) very close or not?

cwp2 is supposed to work off-the-bat for 99% of everyday users, and ewp2 is supposed to empower the savvy curious ones.

Speaking as an everyday user :-) compressing 16bit-something (like dslr images) to more-than-8-bit webp2 seems to be an important use case, esp. since this is one of the main difference vs. webp1.

[Scope]

Why didn't you include heic (i.e. hevc-compression), as it's another currrent video codec with a widely used image spin-off? The performance seems to be somewhere between avif and webp, with the same problem for true rgb mode.[/url]
Because I wanted to compare mainly open, royalty-free lossless formats (preferably also web-oriented), HEIC (HEVC) has very little chance of being supported in browsers because of its patent problems, it has the same bad efficiency of true RGB-lossless image compression as AVIF, it is also less efficient than AVIF (the current difference may not be as noticeable due to less mature encoders).


Um, could anyonye please evaluate what this means - since 'real' lossless avif seems to be off the charts, is 444-avif (and probably the same for hevc-heic) very close or not?

https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_formats_comparison_webp_jpeg_xl/fl3y57j/
jonsneyers
YUV444 is not actually lossless. Conversion of 8-bit RGB to 8-bit YCbCr reduces the number of colors from ~16m to ~4m. You're basically not encoding the least significant bits in the red and blue channels - and those are typically high-entropy bits, so you get a close to 2bpp advantage by not encoding them.


And https://www.reddit.com/r/AV1/comments/jp3ix7/avif_lossess_images_are_huge_compared_to_webp/gbe5fw5/

Also HEIC without --matrix_coefficients=0 (heifenc -p chroma=444 --lossless -e x265 -p preset=placebo ...)
https://i.imgur.com/ysoWbAK.png
Visually the result may be the same, but it's not real lossless and other formats also have more effective near-lossless modes, when the image becomes much smaller and it would be unfair to compare such modes with real lossless.

[skal]

Speaking as an everyday user :-) compressing 16bit-something (like dslr images) to more-than-8-bit webp2 seems to be an important use case, esp. since this is one of the main difference vs. webp1.

duly noted!

[Clare]

Does anyone know on what it is based? webp was derived from VP8, is webp2 based on VP9 or is it a completly new format?

[benwaggoner]

duly noted!
And >8-bit would also make native HDR photography feasible. Today it's a lot easier to convert HDR/RAW photography to a very low fps HEVC .mp4 using PQ Rec. 2020 and play it back on a HDR TV than it is to actually grade or view HDR photography AS HDR on a computer. I look forward to being able to embed HDR images in a web page and letting the OS map everything optimally to the available display.

[Scope]

Image formats comparison by eclipseo:
https://www.reddit.com/r/AV1/comments/k9kq5t/updated_my_image_formats_comparison_including/

https://eclipseo.github.io/image-comparison-web/
(Shift key to switch between images)

[skal]

Does anyone know on what it is based? webp was derived from VP8, is webp2 based on VP9 or is it a completly new format?

WebP2 is based on recycled bricks from WebP-v1 (lossless), along with elements from AV1 or similar, plus some new features (alpha, preview, ...) developed for the image use-case specifically.

For more illustrated details, see the second part of this presentation: http://bit.ly/image_ready_webp_slides

[Marsu42]

Image formats comparison by eclipseo:

This looks very promising for webp2, because like jpeg it doesn't achive high compression by smudging everything over - is this a coincidence, or a design goal?

https://eclipseo.github.io/image-comparison-web/#catedral-de-toledo&avif=t&webp=t

And looking at the file sizes, the "lossless" comparison is avif-yuv444 vs webp2-rgb?? ... Edit: Seems to be even worse :-p https://www.reddit.com/r/AV1/comments/k9kq5t/updated_my_image_formats_comparison_including/gf667qj/?utm_source=reddit&utm_medium=web2x&context=3

Whoever came up with the notion of calling something "lossless" only relative to some internal/intermediary step should be made to correct every confusion all over the internet :-\

[Scope]

This looks very promising for webp2, because like jpeg it doesn't achive high compression by smudging everything over - is this a coincidence, or a design goal?
Judging by the other images that I saw at the beginning of development and my own tests, this is a design goal

And looking at the file sizes, the "lossless" comparison is avif-yuv444 vs webp2-rgb?? ... Edit: Seems to be even worse :-p[/url]
As far as I understand, all images were exported in 4:2:0 formats, but yes, it is a strange decision to compare modern image formats on 4:2:0 image set
https://eclipseo.github.io/image-comparison-web/report.html

[skal]

Judging by the other images that I saw at the beginning of development and my own tests, this is a design goal


Yes, WebP2 is focussing on the low-bitrate primarily.
But it doesn't mean that the 'medium' and 'large' cases are neglected!

[skal]

For some other news, the 'Squoosh' app got updated right now, with WebP2 support: https://squoosh.app/
(amongst other codecs)

[benwaggoner]

As far as I understand, all images were exported in 4:2:0 formats, but yes, it is a strange decision to compare modern image formats on 4:2:0 image set
https://eclipseo.github.io/image-comparison-web/report.html
Well, 4:2:0 is only 50% the bits per pixel as 4:4:4, so will decode faster. And YUV is generally more efficient than RGB, even in 4:4:4. If I was optimizing for low bitrates and/or SW decode perf, YUV 4:2:0 is an effective cheap optimization that provides excellent quality for the vast majority of images.

[Marsu42]

Well, 4:2:0 is only 50% the bits per pixel as 4:4:4, so will decode faster.

I didn't benchmark it - what's the compressed space saving 4:2:0 vs 4:4:4, and and how much faster (or how much more energy-efficient) is 'faster'? It would have to be compared with a codec that is optimized for 4:4:4, too - the jpeg focus seems to be 4:2:0.

And YUV is generally more efficient than RGB, even in 4:4:4.

Fine by me, as long as no one calls it 'lossless' :-)


If I was optimizing for low bitrates and/or SW decode perf, YUV 4:2:0 is an effective cheap optimization that provides excellent quality for the vast majority of images.

That might be true, but still sounds a bit outdated to me - if avif/heic/... wouldn't be spin-offs from video codecs, i.e. decoding cost and storage/bandwidth are still at a premium - would we still be talking about 4:2:0 for images? It's not about sending images back from the mars mission to earth :-)

Alas, when jpeg with 4:2:0 was introduced in 1992, it was the time of the mighty Intel(tm) 486dx, reaching impressive speeds up to 100Mhz, and data made the wire melt at 14.4 kbps.