Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome Jpegxl Issue Reopened

issues.chromium.org

Post reply on HN
Print view View original

21–30 of 144 posts

Re: Chrome Jpegxl Issue Reopened

#21

Post by F3nd0 »

Pxtl wrote: post #10

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and exp…

If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs.

JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that.

The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.

Re: Chrome Jpegxl Issue Reopened

#22

Post by zozbot234 »

ansgri wrote: post #18
arccy wrote: post #16

Earlier quoted context omitted.

if you actually read your parent comment: "typical web image quality"

Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!

PNG supports HDR with up to 16 bits per channel, see https://www.w3.org/TR/png-3/ and the cICP, mDCV and cLLI chunks.

Re: Chrome Jpegxl Issue Reopened

#23

Post by xeeeeeeeeeeenu »

homebrewer wrote: post #13
wizee wrote: post #4

JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support J…

It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just a…

>avif is just better for typical web image quality,

What does "typical web image quality" even mean? I see lots of benchmarks with very low BPPs, like 0.5 or even lower, and that's where video-based image codecs shine.

However, I just visited CNN.com and these are the BPPs of the first 10 images my browser loaded: 1.40, 2.29, 1.88, 18.03 (PNG "CNN headlines" logo), 1.19, 2.01, 2.21, 2.32, 1.14, 2.45.

I believe people are underestimating the BPP values that are actually used on the web. I'm not saying that low-BPP images don't exist, but clearly it isn't hard to find examples of higher-quality images in the wild.

Re: Chrome Jpegxl Issue Reopened

#24

Post by Dwedit »

F3nd0 wrote: post #21
Pxtl wrote: post #10

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and exp…

If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs. JPEG XL is the first image format in a long while that's been actually designed for images…

Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression.

Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.

Re: Chrome Jpegxl Issue Reopened

#25

Post by asadotzler »

kps wrote: post #19
homebrewer wrote: post #13

Earlier quoted context omitted.

It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just a…

Not everything in the world is passive end-of-the-line presentation. JPEG-XL is the only one that tries to be a general-purpose image format.

If that's the case, let it be a feature of image editing packages that can output formats that are for the web. It's a web standard we're talking about here, not a general-purpose image format, so asking browsers to carry that big code load seems unreasonable when existing formats do most of what we need and want for the web.

Re: Chrome Jpegxl Issue Reopened

#26

Post by crote »

asadotzler wrote: post #25
kps wrote: post #19

Earlier quoted context omitted.

Not everything in the world is passive end-of-the-line presentation. JPEG-XL is the only one that tries to be a general-purpose image format.

If that's the case, let it be a feature of image editing packages that can output formats that are for the web. It's a web standard we're talking about here, not a general-purpose image format, so asking browsers to carry that big code load seems unreasonable when existing formats do most of what we need and want for the web.

People generally expect browsers to display general-purpose image formats. It's why they support formats like classical JPEG, instead of just GIF and PNG.

Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.

Re: Chrome Jpegxl Issue Reopened

#27

Post by mort96 »

ansgri wrote: post #18
arccy wrote: post #16

Earlier quoted context omitted.

if you actually read your parent comment: "typical web image quality"

Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!

HDR should not be "typical web" anything. It's insane that websites are allowed to override my system brightness setting through HDR media. There's so much stuff out there that literally hurts my eyes if I've set my brightness such that pure white (SDR FFFFFF) is a comfortable light level.

I want JXL in web browsers, but without HDR support.

Re: Chrome Jpegxl Issue Reopened

#28

Post by [deleted] »

homebrewer wrote: post #13
wizee wrote: post #4

JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support J…

It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just a…

[deleted]

Re: Chrome Jpegxl Issue Reopened

#29

Post by lonjil »

zozbot234 wrote: post #22
ansgri wrote: post #18

Earlier quoted context omitted.

Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!

PNG supports HDR with up to 16 bits per channel, see https://www.w3.org/TR/png-3/ and the cICP, mDCV and cLLI chunks.

With incredibly bad compression ratios.

Re: Chrome Jpegxl Issue Reopened

#30

Post by mort96 »

albert_e wrote: post #20

> Chrome Jpegxl Issue Reopened > (this is the tracking bug for this feature) Is it just me -- or it's confusing to use the terms issue / bug / feature interchangeably?

It's not really used interchangeably: "bug" is used to mean "entry in the bug tracker database", while "feature" is used to mean what we colloquially think of as a feature of a computer program.

It's arguably a slight abuse of a bug tracking system to also track progress and discussion on features, but it's not exactly uncommon; it's just that many systems would call it an "issue" rather than a "bug".

Post reply on HN