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.

[Scope]

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.
For speed, perhaps, but for everything else in more modern formats, I often found the opposite opinion (even from their developers):

https://forum.doom9.org/showpost.php?p=1930137&postcount=37
skal
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!


https://twitter.com/kornelski/status/1328786564416200709
@kornelski
4:2:0 in AVIF is dead to me: https://github.com/AOMediaCodec/av1-avif/issues/98 — the spec won't commit to any specific way to decode it, so there's no guarantee it will roundtrip even once. Given that AVIF has great 4:4:4 compression, just pretend 4:2:0 doesn't exist.

https://www.reddit.com/r/AV1/comments/jz6hkh/can_av1_hardware_decoding_be_used_for_avif/gdcckvz/
Jon Sneyers
Still images are nearly always 4:4:4 originally – no image editor I know of (Photoshop, GIMP, etc) works in 4:2:0, and photo camera sensors also typically produce 4:4:4 images.

For JPEG compression, 4:2:0 can be useful (in cases where the subsampling doesn't ruin the image) because its entropy coding is rather weak. In more modern codecs (everything since JPEG 2000), 4:2:0 is not really useful anymore from the compression point of view.

https://twitter.com/jonsneyers/status/1329708702690144256
In any codec with decent entropy coding (i.e. everything since JPEG 2000), I think there is no real reason to do 4:2:0, you can just do 4:4:4 all the time. It's only useful in the old JPEG because its entropy coding is not that great, especially for DC.

https://twitter.com/jyzg/status/1329711941233860612
Jyrki Alakuijala
Guetzli rarely chooses YUV420 for old JPEG format. It prefers YUV444 and quantizing the U and V channels more. This happens very even when the source is already in YUV420. In YUV420 quantization errors can propagate over 20 pixels of distance, often most noticeable in red ares.

[benwaggoner]

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.
For file size optimized JPEG, 4:2:0 is the name of the game. JPEG does 4:4:4 at higher "quality" settings by default.

With some handwaving, 4:2:0 is theoretically twice as fast as 4:4:4 as there are 12 bits per pixel instead of 24.

Fine by me, as long as no one calls it 'lossless' :-)
No argument there! 4:2:0 can be perceptually lossless for most use cases, but certainly isn't mathematically so. I believe there are some 4:4:4 YUV-like modes which offer better lossless encoding than RGB and are bit accurate, but that's a very different use case.

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 :-)
Video codecs have supported 4:4:4 for ages now, even if HW decoders don't always support those modes. But images are way more feasible to use in SW, so that's not a limitation. And decoder performance for JPEG isn't a huge factor anymore (although try waiting for Windows to generate thumbnails for a folder of thousands of JPEG files), newer image formats are a lot more complex. There will always be scenarios where "cheap way to get 2x faster, 1/2 memory, 1/2 memory bus pressure" is attractive.

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.
14.4? Hah! I was connecting to my school VAX at 1200 baud with my 2400 baud in 1992 ;)! I first did JPEG with Photoshop 1.0 (IIRC) on my 25 MHz 4 MB RAM Mac IIci. It was not fast.

[skal]

https://eclipseo.github.io/image-comparison-web/report.html

Btw, the latest commit (https://chromium.googlesource.com/codecs/libwebp2/+/6b0aaad12b1134d4562583d327428efcfdb880a0) 6b0aaad of libwebp2 should now produce better results on the type of images typically used in the above comparison...

[Marsu42]

on the type of images typically used in the above comparison

What kind of images would that be :-) ... photography, or...?

The commit logs are too cryptic to me to figure out what the improvement target is.

[skal]

What kind of images would that be :-) ... photography, or...?

That would be the ones with areas of highly different complexities (for instance the trees in 'Source du Pecher' use a lot of bits [~2bpp], whereas the wall on the left uses ~0.1bpp at max). Or the ones with a lot of camera grain (not the same as sensor noise, btw), which uses up a lot of bits.

Basically, the ones that compress around 1bpp at 'small' settings are difficult. 'Source du Pecher', 'Catedral de Toledo', 'Mercado dos lavradores', etc..

The commit logs are too cryptic to me to figure out what the improvement target is.

The interesting patches are the changes around the '-sns' option, which controls the allocation of bits according to area's perceived complexity...

[Jamaika]

predictor_enc.cc:188:11: error: no declaration matches 'WP2Status WP2::Predictors::FindBest(const WP2::EncoderConfig&, const WP2::Rectangle&, uint32_t, const WP2::BlockContext&, const WP2::Segment&, bool, const WP2::Vector<WP2::TransformPair>&, WP2::Counters*, WP2::CodedBlock*, float*, const WP2::Predictor**, WP2::TransformPair*, bool*) const'
188 | WP2Status Predictors::FindBest(
| ^~~~~~~~~~
predictor_enc.cc:188:11: note: no functions named 'WP2Status WP2::Predictors::FindBest(const WP2::EncoderConfig&, const WP2::Rectangle&, uint32_t, const WP2::BlockContext&, const WP2::Segment&, bool, const WP2::Vector<WP2::TransformPair>&, WP2::Counters*, WP2::CodedBlock*, float*, const WP2::Predictor**, WP2::TransformPair*, bool*) const'
In file included from predictor_enc.cc:24:
c:\msys1200\x86_64-w64-mingw32\include\src\common\lossy\predictor.h:139:7: note: 'class WP2::Predictors' defined here
139 | class Predictors {
| ^~~~~~~~~~

[skal]

predictor_enc.cc:188:11: error: no declaration matches ...
(...)


Thanks for the report! Should be fixed now.

[birdie]

WebP2 looks really great but I wonder why didn't you/Google use AV1 as a basis of a new image encoder? Or WebP2 is backward compatible with WebP, i.e. old applications can open WebP2 images? I don't think it's possible considering WebP doesn't even fully support 10bit color depth as far as I know.

I'd also suggest that WebP2 developers paid extra attention to its ability not to main and destroy images after multiple rounds of recompressions - it's a bane of many modern image codecs based on video compression codecs.

[benwaggoner]

WebP2 looks really great but I wonder why didn't you/Google use AV1 as a basis of a new image encoder? Or WebP2 is backward compatible with WebP, i.e. old applications can open WebP2 images? I don't think it's possible considering WebP doesn't even fully support 10bit color depth as far as I know.

I'd also suggest that WebP2 developers paid extra attention to its ability not to main and destroy images after multiple rounds of recompressions - it's a bane of many modern image codecs based on video compression codecs.
AVIF is the AV1-derived image format. It's an AVIF I-frame in a HEIF wrapper.

I've not compared AVIF to WebP2. The stock aomenc AV1 encoder isn't particularly psychovisually optimized, let alone for still images. But royalty free is even more important in images than video, and its feature set is pretty compelling. And beating JPEG by a big margin isn't hard.

[skal]

WebP2 looks really great but I wonder why didn't you/Google use AV1 as a basis of a new image encoder? Or WebP2 is backward compatible with WebP, i.e. old applications can open WebP2 images? I don't think it's possible considering WebP doesn't even fully support 10bit color depth as far as I know.


WebP2 is separate from WebP right now, as an experimental effort. But it shares WebP's goal (and learnings): be good for the web/transfert case, at super-low bitrate (and not necessarily for archival purpose).

AVIF uses AV1 as basis, but starting from a video codec has its shortcomings:

* video codec usually don't care about lossless / alpha
* yuv420 is often good-enough for video content
* decoding doesn't need to be interruptible at frame-level (when you're showing 60 frame / seconds, you can fully restart the decoding of the frame is you're running out of bits)
* quantization params are often tuned for video I-frame (often containing motion blur, etc.), which can be quite different-looking than a still photo.
* video codecs are optimized for hardware, which is close to useless for image decoding. But once you target software decoding mostly, you can chose different algo that better suit.
* video containers are not always the most efficient (size and pratical-wise) when they target flexibility and editing ease.



I'd also suggest that WebP2 developers paid extra attention to its ability not to main and destroy images after multiple rounds of recompressions - it's a bane of many modern image codecs based on video compression codecs.

Robustness to recompression has been often advanced as a critically missing feature. But it's in pratice quite difficult to guarantee: any very common editing operation (cropping, resizing, adding text) will ruin any codec's good intention. And it's not often the case you need to recompress more than 10-20 times (is it?).

[Jamaika]

* video codec usually don't care about lossless / alpha

Is it scam for the avif container that has lossless functionality added? Recently in the libheif discussion there is a question about adding the vvenc codec. There is no lossless feature to know how to apply it. The vvc codec is lossless but only for test trials.
I don't know how vvc works, but apparently it has alpha channels built in. So the layers do not need separate channels.

[benwaggoner]

Is it scam for the avif container that has lossless functionality added? Recently in the libheif discussion there is a question about adding the vvenc codec. There is no lossless feature to know how to apply it. The vvc codec is lossless but only for test trials.
I don't know how vvc works, but apparently it has alpha channels built in. So the layers do not need separate channels.
The AVIF container is HEIF. The HEVC HEIF (HEIC) already supports lossless, as HEVC supports lossless in all profiles. And it also supports alpha channels (https://devstreaming-cdn.apple.com/videos/wwdc/2019/506lqy7sprpfyo800/506/506_hevc_video_with_alpha.pdf?dl=1).

It's pretty trivial to combine a normal YUV image and then a lossless luma-only image for the alpha. Most alpha channels will encode to tiny with HEVC's lossless mode.

It certainly isn't a "scam!"

[jon]

Robustness to recompression has been often advanced as a critically missing feature. But it's in pratice quite difficult to guarantee: any very common editing operation (cropping, resizing, adding text) will ruin any codec's good intention. And it's not often the case you need to recompress more than 10-20 times (is it?).

For editing/authoring workflows, lossless is needed exactly because of that: any operation that moves pixels around will produce generation loss in any lossy codec. Also you want to have more precision/dynamic range than what you'll eventually export as a lossy image for end-user delivery.

But generation loss resilience is still useful in case after end-user delivery, further edits and recompression happens. The typical example is a meme, where an image hops between social media (which typically all apply lossy recompression), and occasionally gets edited (typically by changing a text caption or something like that). In these types of scenarios, often there is no editing at all, just recompression, and if there is editing, it's typically leaving most of the pixels intact (no cropping / rotation / rescaling etc, just replacing some text), and generation loss resilience can be useful.

A meme that goes viral can get recompressed MANY times - people download an image from Twitter, share it with a friend via Whatsapp, they post it on Instagram, then it goes to Facebook, back on Twitter, etc etc. When the artifacts get too bad, people might start looking for a 'cleaner' version, but I have seen images get to a point that probably corresponds to hundreds of generations...

[benwaggoner]

For editing/authoring workflows, lossless is needed exactly because of that: any operation that moves pixels around will produce generation loss in any lossy codec. Also you want to have more precision/dynamic range than what you'll eventually export as a lossy image for end-user delivery.

But generation loss resilience is still useful in case after end-user delivery, further edits and recompression happens. The typical example is a meme, where an image hops between social media (which typically all apply lossy recompression), and occasionally gets edited (typically by changing a text caption or something like that). In these types of scenarios, often there is no editing at all, just recompression, and if there is editing, it's typically leaving most of the pixels intact (no cropping / rotation / rescaling etc, just replacing some text), and generation loss resilience can be useful.

A meme that goes viral can get recompressed MANY times - people download an image from Twitter, share it with a friend via Whatsapp, they post it on Instagram, then it goes to Facebook, back on Twitter, etc etc. When the artifacts get too bad, people might start looking for a 'cleaner' version, but I have seen images get to a point that probably corresponds to hundreds of generations...
Great insight there.

A great thing about using HEIC is that its lossless mode is quite efficient; a lot better than PNG or lossless JPEG and better than J2K.

There is also the option of mixing lossless and lossy blocks in the same image. For example, lossless for text or graphics and high quality lossy for natural images. And transform-skip blocks can be a great middle ground as well.

I've been able to get HEIC to match JPEG quality at 5% the bitrate for comic book art (all those sharp lines are a poor fit for JPEG).

[Brazil2]

And it also supports alpha channels (file:///C:/Users/benwagg/Downloads/506_hevc_video_with_alpha.pdf).
file:///C:/Users/benwagg/Downloads/506_hevc_video_with_alpha.pdf
Linking to your hard drive won't work :p

Here is the public link ;) :
https://devstreaming-cdn.apple.com/videos/wwdc/2019/506lqy7sprpfyo800/506/506_hevc_video_with_alpha.pdf?dl=1

[benwaggoner]

file:///C:/Users/benwagg/Downloads/506_hevc_video_with_alpha.pdf
Linking to your hard drive won't work :p

Here is the public link ;) :
https://devstreaming-cdn.apple.com/videos/wwdc/2019/506lqy7sprpfyo800/506/506_hevc_video_with_alpha.pdf?dl=1
DOH!

Thanks for the catch and the fix!

[Jamaika]

What is not in the x265 codecs but in vvc. Why do libheif containers use dual x265 codec for only three additional alpha layers? :p

("Profile", extendedProfile, ExtendedProfileName::NONE, "Profile name to use for encoding. Use [multilayer_]main_10[_444][_still_picture], auto, or none")
("MultiLayerEnabledFlag", m_multiLayerEnabledFlag, false, "Bitstream might contain more than one layer")
("AllLayersIndependentConstraintFlag", m_allLayersIndependentConstraintFlag, false, "Indicate that all layers are independent")
( "MaxLayers", m_maxLayers, 1, "Max number of layers" )
( "MaxTemporalLayer", m_maxTemporalLayer, 500, "Maximum temporal layer to be signalled in OPI" )
("LambdaModifierI,-LMI", cfg_adIntraLambdaModifier, cfg_adIntraLambdaModifier, "Lambda modifiers for Intra pictures, comma separated, up to one the number of temporal layer. If entry for temporalLayer exists, then use it, else if some are specified, use the last, else use the standard LambdaModifiers.")

("SEIACIEnabled", m_aciSEIEnabled, false, "Control generation of alpha channel information SEI message")
("SEIACICancelFlag", m_aciSEICancelFlag, false, "Specifies the persistence of any previous alpha channel information SEI message in output order")
("SEIACIUseIdc", m_aciSEIUseIdc, 0, "Specifies the usage of the auxiliary picture in the alpha channel information SEI message")
("SEIACIBitDepthMinus8", m_aciSEIBitDepthMinus8, 0, "Specifies the bit depth of the samples of the auxiliary picture in the alpha channel information SEI message")
("SEIACITransparentValue", m_aciSEITransparentValue, 0, "Specifies the transparent interpretation sample value in the alpha channel information SEI message")
("SEIACIOpaqueValue", m_aciSEIOpaqueValue, 0, "Specifies the opaque interpretation sample value in the alpha channel information SEI message")
("SEIACIIncrFlag", m_aciSEIIncrFlag, false, "Specifies the opaque interpretation sample value in the alpha channel information SEI message")
("SEIACIClipFlag", m_aciSEIClipFlag, false, "Specifies whether clipping operation is applied in the alpha channel information SEI message")
("SEIACIClipTypeFlag", m_aciSEIClipTypeFlag, false, "Specifies the type of clipping operation in the alpha channel information SEI message")

[benwaggoner]

What is not in the x265 codecs but in vvc. Why do libheif containers use dual x265 codec for only three additional alpha layers? :p
x265 is a specific HEVC encoder. Others are available and can be used with HEIC, although x265 is quite good at the still image use case. The HEIF wrapper can use H.264, JPEG, AV1 (AVIF is AV1 in HEIF), and is easily extendible to other still image codecs.

I don't see where you are getting three additional alpha layers. MaxLayers=1 in your sample.

I'd not looked at these below. It's clever to allow lambda modifiers to be specified at this level. Alpha channel encoding likely benefits from different lambda tables, and it's more efficient to store it once per HEIF than in the bitstream for each individual alpha channel.

[Jamaika]

x265 is a specific HEVC encoder. Others are available and can be used with HEIC, although x265 is quite good at the still image use case. The HEIF wrapper can use H.264, JPEG, AV1 (AVIF is AV1 in HEIF), and is easily extendible to other still image codecs.

I don't see where you are getting three additional alpha layers. MaxLayers=1 in your sample.

I'd not looked at these below. It's clever to allow lambda modifiers to be specified at this level. Alpha channel encoding likely benefits from different lambda tables, and it's more efficient to store it once per HEIF than in the bitstream for each individual alpha channel.

Channel alpha for heif are recent added feature. I don't know the spec, but I see config like this .

two_layers.cfg
#======== Layers ===============
MaxLayers : 2
MaxSublayers : 7
DefaultPtlDpbHrdMaxTidFlag : 0
AllIndependentLayersFlag : 0
#======== OLSs ===============
EachLayerIsAnOlsFlag : 0
OlsModeIdc : 2
NumOutputLayerSets : 2
OlsOutputLayer1 : 1 0
NumPTLsInVPS : 2
#======== Layer-0 ===============
LayerId0 : 0
#======== Layer-1 ===============
LayerId1 : 1
NumRefLayers1 : 1
RefLayerIdx1 : 0
#======== OLS-0 ===============
OlsPTLIdx0 : 0
#======== OLS-1 ===============
LevelPTL1 : 6.2
OlsPTLIdx1 : 1

[birdie]

@skal

Thank you for the insightful answer!

[benwaggoner]

Channel alpha for heif are recent added feature. I don't know the spec, but I see config like this .

two_layers.cfg
#======== Layers ===============
MaxLayers : 2
MaxSublayers : 7
DefaultPtlDpbHrdMaxTidFlag : 0
AllIndependentLayersFlag : 0

I've not read the spec to this level, but that looks like a maximum of two layers to me.

[birdie]

@skal

I've been thinking about your reply and I have an issue with it.

Most modern videos are encoded with I frames inserted each 1 or 2 seconds, so the I frames compression ratio is super important - you may optimize your P and B frames all you want but if your I frames are huge, it's all for naught.

Doesn't that mean that AV1 should surpass anything before it in terms of compression efficiency including WebP/WebP2?

[benwaggoner]

Most modern videos are encoded with I frames inserted each 1 or 2 seconds, so the I frames compression ratio is super important - you may optimize your P and B frames all you want but if your I frames are huge, it's all for naught.

Doesn't that mean that AV1 should surpass anything before it in terms of compression efficiency including WebP/WebP2?
I don't know that it has been demonstrated that AV1 has the most efficient I-frame encoding to date, at least not psychovisually with still images. It might be true, but I'm not aware of any good double-blind testing demonstrating that is true.

Also, image sizes vary way more than in video (>8K is quite common), encode a much wider variety of images, and require different psychovisual tuning due to no motion and the variety of images. As old as JPEG is, we've still seen substantial compression efficiency improvements for it in the last decade.

I wouldn't expect a video encoder out of the box to do optimal image compression. We're probably comparing implementations as much as bitstream potentials.

[nhw_pulsar]

Video encoders are optimized for PSNR and SSIM which is not a guarantee that the (still) image and its artifacts will be visually pleasant... And with my experience, it's a big problem I had, because I tried to convince experts that a 30dB image was visually more pleasant than a 38dB image but it was inconceivable and impossible, and I was answered that they didn't trust my eyes and stick with the PSNR numbers...

I don't find that AV1 surpasses WebP2.AV1 has a notably better PSNR, but for those who care a lot about this, WebP2 last time I tested had a way better details preserving like grain, textures,... which is very impressive.

[benwaggoner]

Video encoders are optimized for PSNR and SSIM which is not a guarantee that the (still) image and its artifacts will be visually pleasant... And with my experience, it's a big problem I had, because I tried to convince experts that a 30dB image was visually more pleasant than a 38dB image but it was inconceivable and impossible, and I was answered that they didn't trust my eyes and stick with the PSNR numbers...
All too common a story. People with an engineering background but not an image science background can get into the "I don't care if it looks bad in practice, it still looks good in theory!" trap often.

One of the strengths of x264 and x265 is that they don't optimize for PSNR or SSIM directly, but for its own internal subjective quality metric.

I don't find that AV1 surpasses WebP2.AV1 has a notably better PSNR, but for those who care a lot about this, WebP2 last time I tested had a way better details preserving like grain, textures,... which is very impressive.
Exactly. PSNR is quite lousy at measuring a lot of those factors, and SSIM is only somewhat better.

[nhw_pulsar]

All too common a story. People with an engineering background but not an image science background can get into the "I don't care if it looks bad in practice, it still looks good in theory!" trap often.

One of the strengths of x264 and x265 is that they don't optimize for PSNR or SSIM directly, but for its own internal subjective quality metric.


Exactly. PSNR is quite lousy at measuring a lot of those factors, and SSIM is only somewhat better.

Thank you for your support Sir.

I'm however not saying that AVIF (AV1) is bad visually, absolutely not, just for me it visually decreases a little image neatness (which PSNR absolutely not measures), and when you compare with a codec like NHW which increases neatness, then for me you clearly see the neatness difference and that for example more neatness is visually more pleasant despite a 5-6dB PSNR difference between the 2 codecs...

Yes BPG x265 -m 1 fastest speed setting is very impressive, because it has an impressive ratio between subjective visual quality, high PSNR ad very fast speed, and I even wonder if it is not a similar setting that is implemented in smartphones to shoot photos (as speed is very important for portable devices)?

Coming back on topic, just as an indication, I looked again at the 8 images I tested with WebP2, AVIF and NHW at -l9 high compression setting, and when comparing WebP2 and AVIF, it's tight visually, but slightly on 4 images out of 8, I visually prefer WebP2 because it has an impressive fine details preserving, and on the 4 other images, I prefer AVIF, but it's very subjective and quite tight.It also seems that WebP2 has the most precise details (like grain, textures, and other...) preserving/retention, so congratulations to the WebP2 team!

Cheers,
Raphael

[skal]

@skal
Most modern videos are encoded with I frames inserted each 1 or 2 seconds, so the I frames compression ratio is super important - you may optimize your P and B frames all you want but if your I frames are huge, it's all for naught.

Doesn't that mean that AV1 should surpass anything before it in terms of compression efficiency including WebP/WebP2?

There's actually 3 situations where intra blocks are used:

a) Isolated intra-blocks in a P/B frame: they are used to fill-in "unpredictable" blocks (like: resolving silhouettes, unseen background appearing behind an object during a pan, etc.)
b) intra-blocks in a forced I-frame (or intra-refreshed sweeping refresh): these should be inter blocks, but...
c) "Real" intra-blocks on a real scene-change frame

The still image case is really only c), the other cases require the intra blocks specs (quant tables, how you predict from the context or bordering pixels, which are 'P-like' in essence) to be more tuned toward typical P video frame.

The forced intra-frames inserted every 1/2sec that you mentioned are mostly the b) case.

I'm thus not sure a video codec has to be the 'best still image' codec too, although it sure can't hurt!

[benwaggoner]

There's actually 3 situations where intra blocks are used:

a) Isolated intra-blocks in a P/B frame: they are used to fill-in "unpredictable" blocks (like: resolving silhouettes, unseen background appearing behind an object during a pan, etc.)
b) intra-blocks in a forced I-frame (or intra-refreshed sweeping refresh): these should be inter blocks, but...
c) "Real" intra-blocks on a real scene-change frame

The still image case is really only c), the other cases require the intra blocks specs (quant tables, how you predict from the context or bordering pixels, which are 'P-like' in essence) to be more tuned toward typical P video frame.

The forced intra-frames inserted every 1/2sec that you mentioned are mostly the b) case.

I'm thus not sure a video codec has to be the 'best still image' codec too, although it sure can't hurt!
Plus HEVC introduced intra-frame prediction, so you can actually have inter-predicted blocks on an IDR frame, referencing earlier parts of the same frame.

Sometimes I feel like we're walking backwards into fractal encoding, with all the new prediction modes getting implemented ;)! If a codec can warp and rotate, all the ferns in a frame can be predicted from a section of the very first top left fern.

Of course, having this all general purpose is way better than the old fractal encoding demos. A frame full of ferns and a graduate student to do motion estimation and rate control were the best case scenario...

[Jamaika]

I have question about the compression add-ons for libtiff zlib or facebook zstd. I know these aren't google products. Will it be possible to compress libtiff photos with libweb2? I mean adding the effort <0-9> function in the decoder.

[foxyshadis]

* video codecs are optimized for hardware, which is close to useless for image decoding. But once you target software decoding mostly, you can chose different algo that better suit.
Downside: If you don't target hardware in some fashion, even if only to make it FPGA or GPU-capable if not a full fixed chip, you end up with no mobile adoption, and mobile is the majority of the market now. AV1 got extraordinarily lucky that HEVC licensing imploded, otherwise it would never have existed as a consumer product because it requires herculean efforts to turn into hardware even with several advisors tweaking the final design. Cameras will want to offload as much encoding as possible, galleries and social media apps will want to offload as much decoding as possible, and even games will nearly always only ever use anything natively supported.

It doesn't need to be like MPEG, where almost every decision is based on hardware, but I hope at some point you have a plan for hardware engineers to at least take a look and point out where something that works in software is going to be nigh-impossible in hardware before it's too late.

* video containers are not always the most efficient (size and pratical-wise) when they target flexibility and editing ease.
I have a hard time squaring that idea with the fact that ISO-BMFF and Matroska have proven to be incredibly robust and versatile for images, without more than a few bytes of overhead compared to every vaunted custom container. With each generation it gets more confusing why the wheel keeps being reinvented but worse, if it's not just NIH. Then it has to be extended and re-extended until it finally has most of the features they could have had for free.

Let's face it, the Exif and thumbnail will always be orders of magnitude less efficient than container overhead.

[benwaggoner]

Downside: If you don't target hardware in some fashion, even if only to make it FPGA or GPU-capable if not a full fixed chip, you end up with no mobile adoption, and mobile is the majority of the market now. AV1 got extraordinarily lucky that HEVC licensing imploded, otherwise it would never have existed as a consumer product because it requires herculean efforts to turn into hardware even with several advisors tweaking the final design. Cameras will want to offload as much encoding as possible, galleries and social media apps will want to offload as much decoding as possible, and even games will nearly always only ever use anything natively supported.

It doesn't need to be like MPEG, where almost every decision is based on hardware, but I hope at some point you have a plan for hardware engineers to at least take a look and point out where something that works in software is going to be nigh-impossible in hardware before it's too late.
So true. Just like I worry about the global CO2 impact of using AV1 SW decoders when a HW decoder is available, I imagine the net impact of doing lot of SW image decode could hurt device battery life in an all AVIF world.

Also, all that new assembly code is new surface area for bugs and exploits. Decode in HW has a lot lower (but non-zero) risk of exploits. A huge share of device remote exploits have been on media features.

I have a hard time squaring that idea with the fact that ISO-BMFF and Matroska have proven to be incredibly robust and versatile for images, without more than a few bytes of overhead compared to every vaunted custom container. With each generation it gets more confusing why the wheel keeps being reinvented but worse, if it's not just NIH. Then it has to be extended and re-extended until it finally has most of the features they could have had for free.

Let's face it, the Exif and thumbnail will always be orders of magnitude less efficient than container overhead.
Yeah, I can't imagine a scenario where a custom wrapper would yield a material reduction in file size in apples-to-apples comparisons.

And MP4 container parsing is battle-hardened code. While wrapper code isn't as risky as actual DSP SW, those still have been a fertile area for exploits.

[nhw_pulsar]

Downside: If you don't target hardware in some fashion, even if only to make it FPGA or GPU-capable if not a full fixed chip, you end up with no mobile adoption, and mobile is the majority of the market now. AV1 got extraordinarily lucky that HEVC licensing imploded, otherwise it would never have existed as a consumer product because it requires herculean efforts to turn into hardware even with several advisors tweaking the final design. Cameras will want to offload as much encoding as possible, galleries and social media apps will want to offload as much decoding as possible, and even games will nearly always only ever use anything natively supported.

It doesn't need to be like MPEG, where almost every decision is based on hardware, but I hope at some point you have a plan for hardware engineers to at least take a look and point out where something that works in software is going to be nigh-impossible in hardware before it's too late.


Wow, sadly this is just another major hurdle when you are an individual and you have created a codec, to penetrate the codec market, because this is prohibitive to afford hardware experts that will tell you what is possible and what is not possible in hardware, and so what to code.

What also worries me is when you say: "before it's too late", because for example in NHW, I did not develop for hardware, and so this worries me that there are maybe main design choices/errors that prevent the codec from being feasible in hardware....

[skal]

Also, all that new assembly code is new surface area for bugs and exploits.


?! there's nothing really scary about assembly code, all things considered. I've seen more harm done by "malloc(-1)"'s than any SIMD code in media processing.


Decode in HW has a lot lower (but non-zero) risk of exploits. A huge share of device remote exploits have been on media features.

Bad drivers and HW interaction have caused quite some harm. And they are very hard to retro-fix or fuzz. It's actually pretty easy to make drivers freeze on bad corrupt bitstreams these days.

Anyways, complex containers are extremely difficult to get right. Stagefright exploit comes to mind:
https://www.kb.cert.org/vuls/id/924951.
WebP's RIFF container was very simple, and yet we had 1 exploit (only!) in 10 years. Not bad, but not zero.

If you're not receiving user media files uploaded from the wild, it's easy to think a container format is simple and safe.
VLC community has great horror stories about containers. Even after so many years of bug fixing, i still wouldn't trust ffmpeg to decode any MP4 file without proper sandboxing.

Regarding HW, in the past, we tried to reuse VP8 hardware decoding for WebP lossy, and it wasn't terribly faster. And actually quite brittle because of driver failures.
https://groups.google.com/a/webmproject.org/g/webp-discuss/c/lFOST2zWIjM/m/Ctl5wEoalGwJ

All in all, there's a real need for less flexible and easier-to-implement container, without any low-usage complex feature.
It's not just about size reduction, but also making sure it's easy for implementations to get right.

[Jamaika]

I created the newest file av1enc with
Library encoder: av1enc 0.0.1 8_12bit c++ [01 Feb 2022] {boost, mingw}
libWebP 1.2.2 c [20 Jan 2022]
aom 3.3.0 c [03 Feb 2022]
libavif 0.9.3 c [28 Jan 2022]
jpegxl 0.7.0 c++ [04 Feb 2022]
brotli 1.0.9 c [06 Dec 2021]
libyuv 1.8.10 c++ [03 Feb 2022]
boost 1.78.0 c++ [02 Dec 2021]
libJPEG-turbo 2.1.3 8bit c [01 Feb 2022] {assembler SIMD}
libPNG 1.6.38 c [12 Mar 2021] {zlib}
libTIFF 4.3.0 c [05 Feb 2022] {zlib, libdeflate, zstd}
giflib 5.2.1 c [24 Jun 2019]
zlib 1.2.11.1 c [01 Jan 2022]
I can see that the names of some functions have changed.
opt.Add("-pass <int>", "number of passes [1..2..3]");

cpi->source =
av1_scale_if_required(cm, cpi->unscaled_source, &cpi->scaled_source,
cm->features.interp_filter, 0, false, false);
if (cpi->unscaled_last_source != NULL) {
cpi->last_source = av1_scale_if_required(
cm, cpi->unscaled_last_source, &cpi->scaled_last_source,
cm->features.interp_filter, 0, false, false);
}
I am changing to:
cpi->source =
av1_realloc_and_scale_if_required(cm, cpi->unscaled_source, &cpi->scaled_source,
cm->features.interp_filter, 0, false, false, cpi->oxcf.border_in_pixels, cpi->oxcf.tool_cfg.enable_global_motion);
if (cpi->unscaled_last_source != NULL) {
cpi->last_source = av1_realloc_and_scale_if_required(
cm, cpi->unscaled_last_source, &cpi->scaled_last_source,
cm->features.interp_filter, 0, false, false, cpi->oxcf.border_in_pixels, cpi->oxcf.tool_cfg.enable_global_motion);
}
I add fix:
https://github.com/AOMediaCodec/libavif/pull/838
I also don't know why avif is no longer compatible with av1enc.
The file sizes for av1 and avif are different. I don't think command functions pass.
av1enc.exe -q 90 -420 -size 1563x1558 -effort 5 -thread 4 image_21447_24bit.jpg -d image_21447_24bitw1.av1 1239149kb
av1enc.exe -avif -q 90 -420 -size 1563x1558 -effort 5 -thread 4 image_21447_24bit.jpg -d image_21447_24bitw1.avif 931201kb

Codec works
av1enc.exe -q 90 -420 -size 1563x1558 -effort 5 -tune butteraugli -thread 4 image_21447_24bit.jpg -d image_21447_24bitw2.av1
Codec doesn't work tune butteraugli
av1enc.exe -avif -q 90 -420 -size 1563x1558 -effort 5 -tune butteraugli -thread 4 image_21447_24bit.jpg -d image_21447_24bitw2.avif

https://www.sendspace.com/file/iryn52

I add defined
opt.Add("-tune <metric>", "choose metric for tuning. "
#if CONFIG_TUNE_VMAF
"One of: psnr, ssim, vmaf"
#elif CONFIG_TUNE_BUTTERAUGLI
"One of: psnr, ssim, butteraugli"
#elif CONFIG_TUNE_VMAF && CONFIG_TUNE_BUTTERAUGLI
"One of: psnr, ssim, vmaf, butteraugli"
#else
"One of: psnr, ssim"
#endif // CONFIG_TUNE_VMAF
);
#if defined(WP2_HAVE_LIBGAV1)
opt.Add("-libgav1", "use libgav1 decoder");
#endif
#if CONFIG_TUNE_VMAF
} else if (!strcmp(argv[c], "vmaf") || !strcmp(argv[c], "VMAF")) {
params.tuning = WP2::ParamsAV1::Tuning::kVmaf;
#elif CONFIG_TUNE_BUTTERAUGLI
} else if (!strcmp(argv[c], "butteraugli") || !strcmp(argv[c], "BUTTERAUGLI")) {
params.tuning = WP2::ParamsAV1::Tuning::kButteraugli;
#endif
#if defined(WP2_HAVE_LIBGAV1)
} else if (!strcmp(argv[c], "-libgav1")) {
params.use_libgav1_decoder = true;
#endif
const int tuning =
(params.tuning == ParamsAV1::Tuning::kPsnr) ? AOM_TUNE_PSNR
: (params.tuning == ParamsAV1::Tuning::kSsim) ? AOM_TUNE_SSIM
#if CONFIG_TUNE_VMAF
: (params.tuning == ParamsAV1::Tuning::kVmaf) ? AOM_TUNE_VMAF_MAX_GAIN
#elif CONFIG_TUNE_BUTTERAUGLI
: (params.tuning == ParamsAV1::Tuning::kButteraugli) ? AOM_TUNE_BUTTERAUGLI
#endif
: 0;
const char* kTuningStr[] = {"PSNR", "SSIM"
#if CONFIG_TUNE_VMAF
, "VMAF"
#elif CONFIG_TUNE_BUTTERAUGLI
, "BUTTERAUGLI"
#endif
};
libavif
static const struct aomOptionEnumList tuningEnum[] = { //
{ "psnr", AOM_TUNE_PSNR }, //
{ "ssim", AOM_TUNE_SSIM }, //
#if CONFIG_TUNE_VMAF
{ "vmaf", AOM_TUNE_VMAF_MAX_GAIN }, //
#elif CONFIG_TUNE_BUTTERAUGLI
{ "butteraugli", AOM_TUNE_BUTTERAUGLI }, //
#endif
{ NULL, 0 }
};

[Jamaika]

It's December
For the sake of competitive balance libheif I created libwebp2 {no mabs}
Now you can convert the latest png,tiff,jxl,webp,jpeg(8/10/12bit),av1,av2 codecs. The libwebp2 converter is slowly being created and it is not known whether it will enter general use. However av2 codec is being modernized quite quickly and it is clear that almost all the forces are transferred from av1.

cwp2_avx.exe input.jpg -info -q 100 -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_jpeg.wp2
cwp2_avx.exe input.webp -info -q 100 -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_webp.wp2
cwp2_avx.exe input.tiff -info -q 100 -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_tiff.wp2
cwp2_avx.exe input.jxl -info -q 100 -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_jxl.wp2
av1enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -tune butteraugli input_jpeg.wp2 -d output.av1
av2enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -pass 1 -tune ssim input_jpeg.wp2 -d output.av2

Info: AV2 codec is difficult to create because it contains errors.
Detele error: CONFIG_ENABLE_IBC_NAT, CONFIG_IBP_WEIGHT

https://www.sendspace.com/file/cciwa6

[Jamaika]

https://www.sendspace.com/file/twkf0w

cwp2_avx.exe input.jpg -info -q 100 -8bits -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_jpeg.wp2
cwp2_avx.exe input.webp -info -q 100 -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_webp.wp2
cwp2_avx.exe input.tiff -info -q 100 -8bits -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_tiff.wp2
cwp2_avx.exe input.jxl -info -q 100 -8bits -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_jxl.wp2
av1enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -tune butteraugli input_jpeg.wp2 -d output.av1
av2enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -pass 1 -tune ssim input_jpeg.wp2 -d output.av2

Library encoder: av1enc 0.0.1 8_12bit c++ [4c63842] {boost}
avm 8.1.0 c [c11c85e]
libjxl 0.12.0 c++ [7597170] {brotli, highway, butteraugli}
highway 1.2.0 c++ [9aa447e]
brotli 1.1.0 c [91d96d3]
libJPEG-turbo 3.1.1 8_16bit c [e0e18de] {assembler SIMD}
libWEBP 1.5.0 c [2af6c03] {sharpyuv}
libPNG 1.6.45 c [c1cc0f3] {zlib}
libTIFF 4.7.0 c [c474fb8] {zlib, libdeflate, zstd, libwebp}
giflib 5.2.1 c [24 Jun 2019]
boost 1.84.0b1 c++ [16 Nov 2023]
zlib 1.3.1.1 c [ef24c4c]
zstd 1.5.5 c [ffde100]
libdeflate 1.23.0 c [7805198]
Compiled by Jamaika

[Jamaika]

https://www.sendspace.com/file/dje7cf

AV2 not compatible with msys2 gcc 15.1.0 rev5 so I used 11.5.0 and mingw64 12.0.0-r1

cwp2_avx.exe input.jpg -info -q 100 -8bits -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_jpeg.wp2
cwp2_avx.exe input.webp -info -q 100 -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_webp.wp2
cwp2_avx.exe input.tiff -info -q 100 -8bits -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_tiff.wp2
cwp2_avx.exe input.jxl -info -q 100 -8bits -nometadata -mt -effort 7 -uv_mode 2 -csp 0 -o output_jxl.wp2
av1enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -tune butteraugli input_jpeg.wp2 -d output.av1
av2enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -pass 1 -tune ssim input_jpeg.wp2 -d output.av2

Library encoder {old library}:
av2enc 0.0.1 8_12bit c++ [3313771] {boost}
avm 10.0.0 c [e97b8af]
libjxl 0.12.0 c++ [5220155] {brotli, highway, butteraugli}
highway 1.2.0 c++ [400fbf2]
brotli 1.1.1 c [434b582]
libJPEG-turbo 3.1.1 8_16bit c [e0e18de] {assembler SIMD}
libWEBP 1.5.0 c [fa6f564] {sharpyuv}
libPNG 1.6.50 c [8087a21] {zlib}
libTIFF 4.7.0 c [02c6feb] {zlib, libdeflate, zstd, libwebp}
giflib 5.2.1 c [24 Jun 2019]
boost 1.84.0b1 c++ [16 Nov 2023]
zlib 1.3.1.1 c [5a82f71]
zstd 1.5.5 c [ffde100]
libdeflate 1.23.0 c [7805198]

Compiled by Jamaika

[Jamaika]

https://www.sendspace.com/file/nufr7t

Library encoder:
av2enc 0.0.1 8_12bit c++ [aa3651e] {boost}
avm 10.0.1 c [6b2b423]
libjxl 0.12.0 c++ [c50010f] {brotli, highway, butteraugli}
highway 1.2.0 c++ [400fbf2]
brotli 1.1.1 c [434b582]
libJPEG-turbo 3.1.1 8_16bit c [e0e18de] {assembler SIMD}
libWEBP 1.6.0 c [484991c] {sharpyuv}
libPNG 1.6.50 c [8087a21] {zlib}
libTIFF 4.7.0 c [02c6feb] {zlib, libdeflate, zstd, libwebp}
giflib 5.2.1 c [24 Jun 2019]
boost 1.84.0b1 c++ [16 Nov 2023]
zlib 1.3.1.1 c [5a82f71]
zstd 1.5.5 c [ffde100]
libdeflate 1.23.0 c [7805198]

Compiled by Jamaika

[Jamaika]

https://www.sendspace.com/file/tiv5ih

Library encoder: av2enc 0.0.1 8_12bit c++ [dbbdedb] {boost}
avm 11.0.0 c [18d1a13]
libjxl 0.12.0 c++ [2a4f12b] {brotli, highway, butteraugli}
highway 1.3.0 c++ [7915090]
brotli 1.2.0 c [4b0f27b]
libJPEG-turbo 3.1.2 8_16bit c [42d2a24] {assembler SIMD}
libWEBP 1.6.0 c [23359a1] {sharpyuv}
libPNG 1.6.51 c [99230a0] {zlib}
libTIFF 4.7.0 c [02c6feb] {zlib, libdeflate, zstd, libwebp}
giflib 5.2.1 c [24 Jun 2019]
boost 1.84.0b1 c++ [16 Nov 2023]
zlib 1.3.1.1 c [5a82f71]
zstd 1.5.5 c [ffde100]
libdeflate 1.23.0 c [7805198]
Compiled by Jamaika

[Jamaika]

https://www.sendspace.com/file/rj8ynd

For the curious, libwebp2 encoders with av1,av2,jxl,webp add-ons.

Library encoder: av1enc 0.0.1 8_12bit c++ [d5920d8] {boost}
aom 3.14.1 c [1b5a433] {libyuv, butteraugli}
avm 1.0.0 c [f236400]
libjxl 0.12.0 c++ [743dc84] {brotli, highway, butteraugli}
highway 1.3.0 c++ [7915090]
brotli 1.2.0 c [6312ee2]
libJPEG-turbo 3.1.2 8_16bit c [42d2a24] {assembler SIMD}
libWEBP 1.6.0 c [6178b1d] {sharpyuv}
libPNG 1.6.51 c [99230a0] {zlib}
libTIFF 4.7.0 c [02c6feb] {zlib, libdeflate, zstd, libwebp}
giflib 5.2.1 c [24 Jun 2019]
boost 1.91.0 c++ [22 Apr 2026]
zlib 1.3.2.0 c [f9dd600]
zstd 1.5.5 c [ffde100]
libdeflate 1.23.0 c [7805198]

Compiled by Jamaika