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

71–80 of 144 posts

Re: Chrome Jpegxl Issue Reopened

#71

Post by spaceducks »

Pxtl wrote: post #66
spider-mario wrote: post #62

Earlier quoted context omitted.

Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.

AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go. Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels. With that in mind I'd actually prefer if those…

I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)

Re: Chrome Jpegxl Issue Reopened

#72

Post by hirako2000 »

magicalist wrote: post #68
hirako2000 wrote: post #45

Earlier quoted context omitted.

Even Google photo does not support avif. It's almost as if Google had an interest in increased storage and bandwidth. Of course they don't but as paying Driver used I'm overcharged for the same thing.

> Even Google photo does not support avif I have no previous first-hand knowledge of this, but I vaguely remember discussions of avif in google photos from reddit a while back so FWIW I just tried uploading some avif photos and it handled them just fine. Listed as avif in file info, downloads as the original file, though inspecting the network in the web frontend, it serves versions of it as jpg and webp, so there's…

You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail. Defeating the whole purpose of putting them into Photo.

Given it's an app, they didn't even need Google chrome to add support. Avif is supported on Android natively.

Re: Chrome Jpegxl Issue Reopened

#73

Post by hirako2000 »

lonjil wrote: post #60
hirako2000 wrote: post #45

Earlier quoted context omitted.

Even Google photo does not support avif. It's almost as if Google had an interest in increased storage and bandwidth. Of course they don't but as paying Driver used I'm overcharged for the same thing.

Some years ago, the Google Photos team asked the Chrome team to support JXL, so that they could use it for Photos. The request was ignored, of course.

They could have added support themselves to the app as it doesn't use the WebView

Re: Chrome Jpegxl Issue Reopened

#74

Post by spider-mario »

Pxtl wrote: post #66
spider-mario wrote: post #62

Earlier quoted context omitted.

Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.

AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go. Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels. With that in mind I'd actually prefer if those…

Well, sure, but wasn’t that the use case we were discussing?

Re: Chrome Jpegxl Issue Reopened

#75

Post by spider-mario »

mort96 wrote: post #51
magicalhippo wrote: post #42

Earlier quoted context omitted.

There's nothing stopping browsers from tone mapping[1] those HDR images using your tone mapping preference. [1]: https://en.wikipedia.org/wiki/Tone_mapping

What does that achieve? Isn't it simpler to just not support HDR than to support HDR but tone map away the HDR effect? Anyway, which web browsers have a setting to tone map HDR images such that they look like SDR images? (And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?)

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

Re: Chrome Jpegxl Issue Reopened

#76

Post by malfist »

lonjil wrote: post #58
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.

long term support is actually being provided by google... just a different team in a different country :D most jxl devs are at google research in zurich, and already pledged to handle long tetm support

Just like google pledges long term support for everything until the next new and shiny comes along.

Re: Chrome Jpegxl Issue Reopened

#77

Post by mort96 »

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

Earlier quoted context omitted.

What does that achieve? Isn't it simpler to just not support HDR than to support HDR but tone map away the HDR effect? Anyway, which web browsers have a setting to tone map HDR images such that they look like SDR images? (And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?)

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?

Re: Chrome Jpegxl Issue Reopened

#78

Post by magicalhippo »

mort96 wrote: post #51
magicalhippo wrote: post #42

Earlier quoted context omitted.

There's nothing stopping browsers from tone mapping[1] those HDR images using your tone mapping preference. [1]: https://en.wikipedia.org/wiki/Tone_mapping

What does that achieve? Isn't it simpler to just not support HDR than to support HDR but tone map away the HDR effect? Anyway, which web browsers have a setting to tone map HDR images such that they look like SDR images? (And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?)

> What does that achieve?

Because then a user who wants to see the HDR image in all its full glory can do so. If the base image is not HDR, then there is nothing they can do about it.

> And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?

While I very much support more HDR in the online world, I fully agree with you here.

However, I suspect the reason will boil down to what it usually does: almost no users change the default settings ever. And so, any default which goes the other way will invariably lead to a ton of support cases of "why doesn't this work".

However, web browsers are dark-mode aware, they could be HDR aware and do what you prefer based on that.

Re: Chrome Jpegxl Issue Reopened

#79

Post by Pxtl »

spider-mario wrote: post #74
Pxtl wrote: post #66

Earlier quoted context omitted.

AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go. Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels. With that in mind I'd actually prefer if those…

Well, sure, but wasn’t that the use case we were discussing?

Right. And that particular use-case sounds nice, but realistically this new format will not be exclusively used in that particular case.

Dealing with basically another .webp-like format in those cases (one that might be a backwards-compatible jpeg or might not and determining that can only be done by inspecting the file contents) doesn't sound super fun.

So ideally, to make up names, I wish they'd used separate extensions and so a ".jp3" is a file that can be downconverted to a jpg and you could get a browser extension to automate that for you if you wanted, and a ".jxl" is the new file format that's functionally another ".webp"-like thing to deal with and all the pain-points that implies.

Re: Chrome Jpegxl Issue Reopened

#80

Post by spider-mario »

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 ?

You asked “which web browsers have a setting to tone map HDR images such that they look like SDR images?”; I answered. Were you not actually looking for a solution?
Post reply on HN