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

131–140 of 144 posts

Re: Chrome Jpegxl Issue Reopened

#131

Post by OneDeuxTriSeiGo »

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…

That's also not the only potential gain. You get 20% gain on baseline compression but you also no longer need to store variants at different sizes since JPEG-XL's progressive decode is essentially equivalent to downscaling in terms of quality.

i.e. you can also serve downscaled & thumbnail versions directly from the original image.

Re: Chrome Jpegxl Issue Reopened

#133

Post by PaulHoule »

rjh29 wrote: post #97
bigbuppo wrote: post #50

Earlier quoted context omitted.

LOL. Google, the "yeah that thing we bought six months ago, we're killing it off 30 days for 4 weeks ago" company demanding "long-term" anything.

That conversation doesn't apply to their core products: Search, Mail, Maps, Chrome, Android. Their commitment to maintaining these services over decades has been amazing. It's everything else that sucks.

I could almost imagine the normal search going away to be replaced by a chatbot.

Re: Chrome Jpegxl Issue Reopened

#134

Post by magicalhippo »

magicalhippo wrote: post #122
mort96 wrote: post #114

Earlier quoted context omitted.

What user wants the web to look like this? https://floss.social/@mort/115147174361502259

That video is clearly not encoded correctly. If it were the levels would match the background, given there is no actual HDR content visible in that video frame. Anyway, even if the video was of a lovely nature scene in proper HDR, you might still find it jarring compared to the surrounding non-HDR desktop elements. I might too, depending on the specifics. However, like I said, it's up to the browser to handle this. O…

> That video is clearly not encoded correctly.

Actually I forgot about auto-HDR conversion of SDR videos which some operating systems do. So it might not be the video itself, but rather the OS and video driver ruining things in this case.

Re: Chrome Jpegxl Issue Reopened

#135

Post by mort96 »

magicalhippo wrote: post #122
mort96 wrote: post #114

Earlier quoted context omitted.

What user wants the web to look like this? https://floss.social/@mort/115147174361502259

That video is clearly not encoded correctly. If it were the levels would match the background, given there is no actual HDR content visible in that video frame. Anyway, even if the video was of a lovely nature scene in proper HDR, you might still find it jarring compared to the surrounding non-HDR desktop elements. I might too, depending on the specifics. However, like I said, it's up to the browser to handle this. O…

Ideally, browsers should just not support HDR.

Re: Chrome Jpegxl Issue Reopened

#136

Post by magicalhippo »

mort96 wrote: post #135
magicalhippo wrote: post #122

Earlier quoted context omitted.

That video is clearly not encoded correctly. If it were the levels would match the background, given there is no actual HDR content visible in that video frame. Anyway, even if the video was of a lovely nature scene in proper HDR, you might still find it jarring compared to the surrounding non-HDR desktop elements. I might too, depending on the specifics. However, like I said, it's up to the browser to handle this. O…

Ideally, browsers should just not support HDR.

Well I strongly disagree on that point.

Just because we're in the infancy of wide HDR adoption and thus experience some niggling issues while software folks work out the kinks isn't a good reason to just wholesale forego the feature in such a crucial piece of infrastructure.

Sure, if you don't want HDR in the browser I do think there should be a browser option to let you achieve that. I don't want to force it on everyone out there.

Keep in mind the screenshot you showed is how things looked on my Windows until I changed the auto-HDR option. It wasn't the browser that did it, it was completely innocent.

It was just so long ago I completely forgot I had changed that OS configuration.

Re: Chrome Jpegxl Issue Reopened

#137

Post by Dwedit »

F3nd0 wrote: post #63
Dwedit wrote: post #24

Earlier quoted context omitted.

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.

In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'. You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gaine…

FLIF got integrated in to JPEG-XL as the modular mode.

Re: Chrome Jpegxl Issue Reopened

#138

Post by gsnedders »

mort96 wrote: post #77
spider-mario wrote: post #75

Earlier quoted context omitted.

How about a user stylesheet that uses https://www.w3.org/TR/css-color-hdr-1/#the-dynamic-range-lim... ?

How about websites just straight up aren't allowed to physically hurt me, by default ?

Note the spec does recommend providing a user option: https://drafts.csswg.org/css-color-hdr-1/#a11y

Re: Chrome Jpegxl Issue Reopened

#139

Post by hxtk »

gethly wrote: post #96

jpg -> png -> webp -> avif Why are we going backward?

JPEGXL doesn't refer to the same standard as JPEG. JPEGXL competes with AVIF in as a next-generation image format. It also has some properties that make it very nice for the web, such as the fact that a truncated (e.g., because the download hasn't completed yet) JPEGXL image is also a reduced-fidelity version of the same image, which with large images gets you much faster LCP compared to AVIF where the image remains unusable until fully downloaded.

Re: Chrome Jpegxl Issue Reopened

#140

Post by gethly »

hxtk wrote: post #139
gethly wrote: post #96

jpg -> png -> webp -> avif Why are we going backward?

JPEGXL doesn't refer to the same standard as JPEG. JPEGXL competes with AVIF in as a next-generation image format. It also has some properties that make it very nice for the web, such as the fact that a truncated (e.g., because the download hasn't completed yet) JPEGXL image is also a reduced-fidelity version of the same image, which with large images gets you much faster LCP compared to AVIF where the image remains…

Seems like a very small advantage to warrant all the necessary work needed to make it mainstream. Who would use it as advanced image format when a person that would be interested in such a thing would likely already be handling webp or avif?
Post reply on HN