Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th December 2020, 21:48   #41  |  Link
Clare
Registered User
 
Join Date: Apr 2016
Posts: 61
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?
Clare is offline   Reply With Quote
Old 8th December 2020, 22:48   #42  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by skal View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th December 2020, 13:19   #43  |  Link
Scope
Registered User
 
Join Date: Feb 2020
Posts: 13
Image formats comparison by eclipseo:
https://www.reddit.com/r/AV1/comment...son_including/

https://eclipseo.github.io/image-comparison-web/
(Shift key to switch between images)
Scope is offline   Reply With Quote
Old 9th December 2020, 14:43   #44  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 121
Quote:
Originally Posted by Clare View Post
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
skal is offline   Reply With Quote
Old 9th December 2020, 20:25   #45  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
Quote:
Originally Posted by Scope View Post
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-com...&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/comment...eb2x&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 :-\
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 9th December 2020 at 20:31.
Marsu42 is offline   Reply With Quote
Old 9th December 2020, 21:40   #46  |  Link
Scope
Registered User
 
Join Date: Feb 2020
Posts: 13
Quote:
Originally Posted by Marsu42 View Post
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

Quote:
Originally Posted by Marsu42 View Post
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-com...eb/report.html

Last edited by Scope; 9th December 2020 at 21:46.
Scope is offline   Reply With Quote
Old 9th December 2020, 22:10   #47  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 121
Quote:
Originally Posted by Scope View Post
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 is offline   Reply With Quote
Old 9th December 2020, 22:11   #48  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 121
For some other news, the 'Squoosh' app got updated right now, with WebP2 support: https://squoosh.app/
(amongst other codecs)
skal is offline   Reply With Quote
Old 10th December 2020, 02:02   #49  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Scope View Post
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-com...eb/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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th December 2020, 02:37   #50  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
Quote:
Originally Posted by benwaggoner View Post
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.

Quote:
Originally Posted by benwaggoner View Post
And YUV is generally more efficient than RGB, even in 4:4:4.
Fine by me, as long as no one calls it 'lossless' :-)

Quote:
Originally Posted by benwaggoner View Post
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.
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 10th December 2020 at 02:44.
Marsu42 is offline   Reply With Quote
Old 10th December 2020, 09:15   #51  |  Link
Scope
Registered User
 
Join Date: Feb 2020
Posts: 13
Quote:
Originally Posted by benwaggoner View Post
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...7&postcount=37
Quote:
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...86564416200709
Quote:
@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/comment..._avif/gdcckvz/
Quote:
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/statu...08702690144256
Quote:
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
Quote:
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.
Scope is offline   Reply With Quote
Old 10th December 2020, 18:35   #52  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Marsu42 View Post
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.

Quote:
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.

Quote:
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.

Quote:
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 21st December 2020, 17:37   #53  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 121
Quote:
Originally Posted by Scope View Post
Btw, the latest commit 6b0aaad of libwebp2 should now produce better results on the type of images typically used in the above comparison...
skal is offline   Reply With Quote
Old 23rd December 2020, 12:39   #54  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
Quote:
Originally Posted by skal View Post
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.
__________________
"The innocent have nothing to fear" :stupid:
Marsu42 is offline   Reply With Quote
Old 23rd December 2020, 13:25   #55  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 121
Quote:
Originally Posted by Marsu42 View Post
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..

Quote:
Originally Posted by Marsu42 View Post
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...
skal is offline   Reply With Quote
Old 11th June 2021, 05:36   #56  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Code:
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 {
      |       ^~~~~~~~~~
Jamaika is offline   Reply With Quote
Old 11th June 2021, 10:39   #57  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 121
Quote:
Originally Posted by Jamaika View Post
Code:
predictor_enc.cc:188:11: error: no declaration matches ...
(...)
Thanks for the report! Should be fixed now.
skal is offline   Reply With Quote
Old 12th June 2021, 15:31   #58  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
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.

Last edited by birdie; 12th June 2021 at 15:35.
birdie is offline   Reply With Quote
Old 14th June 2021, 02:56   #59  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by birdie View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 14th June 2021, 10:23   #60  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 121
Quote:
Originally Posted by birdie View Post
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.


Quote:
Originally Posted by birdie View Post
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?).
skal is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:01.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.