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. |
8th December 2020, 22:48 | #42 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
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.
|
9th December 2020, 13:19 | #43 | Link |
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) |
9th December 2020, 14:43 | #44 | Link | |
Registered User
Join Date: Jun 2003
Posts: 121
|
Quote:
For more illustrated details, see the second part of this presentation: http://bit.ly/image_ready_webp_slides |
|
9th December 2020, 20:25 | #45 | Link |
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
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. |
9th December 2020, 21:40 | #46 | Link | ||
Registered User
Join Date: Feb 2020
Posts: 13
|
Quote:
Quote:
https://eclipseo.github.io/image-com...eb/report.html
__________________
Lossless Image Formats Comparison Last edited by Scope; 9th December 2020 at 21:46. |
||
9th December 2020, 22:11 | #48 | Link |
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) |
10th December 2020, 02:02 | #49 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
|
|
10th December 2020, 02:37 | #50 | Link | |||
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
Quote:
Quote:
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.
__________________
"The innocent have nothing to fear" :stupid: Last edited by Marsu42; 10th December 2020 at 02:44. |
|||
10th December 2020, 09:15 | #51 | Link | ||||||
Registered User
Join Date: Feb 2020
Posts: 13
|
Quote:
https://forum.doom9.org/showpost.php...7&postcount=37 Quote:
Quote:
Quote:
Quote:
Quote:
__________________
Lossless Image Formats Comparison |
||||||
10th December 2020, 18:35 | #52 | Link | ||||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
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:
Quote:
Quote:
|
||||
21st December 2020, 17:37 | #53 | Link | |
Registered User
Join Date: Jun 2003
Posts: 121
|
Quote:
|
|
23rd December 2020, 12:39 | #54 | Link |
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
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: |
23rd December 2020, 13:25 | #55 | Link |
Registered User
Join Date: Jun 2003
Posts: 121
|
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 interesting patches are the changes around the '-sns' option, which controls the allocation of bits according to area's perceived complexity... |
11th June 2021, 05:36 | #56 | Link |
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 { | ^~~~~~~~~~ |
12th June 2021, 15:31 | #58 | Link |
Artem S. Tashkinov
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. |
14th June 2021, 02:56 | #59 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
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. |
|
14th June 2021, 10:23 | #60 | Link | |
Registered User
Join Date: Jun 2003
Posts: 121
|
Quote:
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. 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?). |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|