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

111–120 of 144 posts

Re: Chrome Jpegxl Issue Reopened

#111

Post by spaceducks »

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

Earlier quoted context omitted.

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 exten…

The names and extensions of JPEG XL files aren't specified, except that the IANA media type is `image/jxl`. I think an argument could be made to use the double extension convention when the encoder performs lossless JPEG recompression, so image.jpg becomes image.jpg.jxl (while not entirely semantically correct, since it's not an additional layer of compression around the JPEG, it's a reimplementation of the image using identical coding features as JPEG, in JXL).

But like I said in my other comment (which got hidden for some reason), it should be noted that a recompressed JPEG is also a valid JXL on its own. If you have the means to turn a recompressed JPEG into the original, you also have the means to view native JXLs.

Hopefully adoption is widespread and we won't really have to worry about it. JPEG XL is a much more appealing format than WebP, and unlike WebP there are great arguments for software to support it other than "Google started using them, so they're everywhere now."

Re: Chrome Jpegxl Issue Reopened

#112

Post by Dylan16807 »

mort96 wrote: post #110
Dylan16807 wrote: post #109

Earlier quoted context omitted.

Yes, it's uncomfortable to have it get "ridiculously" bright. But there's a level that is comfortable that is higher than what you set for FFFFFF. And the comfortable level for 1% of the screen is even higher. HDR could take advantage of that to make more realistic scenes without making you uncomfortable. If it was coded right to respect your limits. Which is probably isn't right now. But it could be .

I severely doubt that I could ever be comfortable with 10% of my screen getting much brighter than the value I set as max brightness. But say you're right. Now you've achieved images looking completely out of place. You've achieved making the surrounding GUI look grey instead of white. And the screen looks broken when it suddenly dims after switching tabs away from one with an HDR video. What's the point ? Even ignor…

In general, people report that HDR content looks more realistic and pretty. That's the point, if it can be done without hurting you.

Re: Chrome Jpegxl Issue Reopened

#113

Post by mort96 »

Dylan16807 wrote: post #112
mort96 wrote: post #110

Earlier quoted context omitted.

I severely doubt that I could ever be comfortable with 10% of my screen getting much brighter than the value I set as max brightness. But say you're right. Now you've achieved images looking completely out of place. You've achieved making the surrounding GUI look grey instead of white. And the screen looks broken when it suddenly dims after switching tabs away from one with an HDR video. What's the point ? Even ignor…

In general, people report that HDR content looks more realistic and pretty. That's the point, if it can be done without hurting you.

Do they? Do people report that an HDR image on a web page that takes up roughly 10% of the screen looks more realistic? Do they report that an HDR YouTube video, which mostly consists of a screen recording with the recorded SDR FFF being mapped to the brightness of the sun, looks pretty? Do people like when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white? (see e.g https://floss.social/@mort/115147174361502259)

Because that's what HDR web content is.

HDR movies playing on a livingroom TV? Sure, nothing against that. I mean it's stupid that it tries to achieve some kind of absolute brightness, but in principle, some form of "brighter than SDR FFF" could make sense there. But for web content, surrounded by an SDR GUI?

Re: Chrome Jpegxl Issue Reopened

#114

Post by mort96 »

magicalhippo wrote: post #78
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?)

> 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…

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

Re: Chrome Jpegxl Issue Reopened

#115

Post by Dylan16807 »

mort96 wrote: post #113
Dylan16807 wrote: post #112

Earlier quoted context omitted.

In general, people report that HDR content looks more realistic and pretty. That's the point, if it can be done without hurting you.

Do they? Do people report that an HDR image on a web page that takes up roughly 10% of the screen looks more realistic ? Do they report that an HDR YouTube video, which mostly consists of a screen recording with the recorded SDR FFF being mapped to the brightness of the sun, looks pretty ? Do people like when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white?…

> when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white

I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that.

And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up. I am aware that HDR can be done wrong...

But for HDR videos where the HDR actually makes sense, yeah it's fine for highlights in the video to be a little brighter than the GUI around them, or for tiny little blips to be significantly brighter. Not enough to make it look gray like the misbehavior you linked.

Re: Chrome Jpegxl Issue Reopened

#116

Post by mort96 »

Dylan16807 wrote: post #115
mort96 wrote: post #113

Earlier quoted context omitted.

Do they? Do people report that an HDR image on a web page that takes up roughly 10% of the screen looks more realistic ? Do they report that an HDR YouTube video, which mostly consists of a screen recording with the recorded SDR FFF being mapped to the brightness of the sun, looks pretty ? Do people like when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white?…

> when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that. And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up. I am aware that HDR can be done wrong... But for HDR vide…

> I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that.

Other than the exaggerated 10x, I don't understand how it violates the rules you proposed. You proposed a scheme where part of the screen should be allowed to be significantly brighter than the surrounding SDR GUI's FFF. That makes the surrounding GUI look grey.

> And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up.

I'm bringing it up because that's how HDR looks on the web. Most web content isn't made by professional movie studios.

The example video I linked conforms with your suggested rules, FWIW: most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF. Yet it still hurts.

Re: Chrome Jpegxl Issue Reopened

#117

Post by Dylan16807 »

mort96 wrote: post #116
Dylan16807 wrote: post #115

Earlier quoted context omitted.

> when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that. And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up. I am aware that HDR can be done wrong... But for HDR vide…

> I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that. Other than the exaggerated 10x, I don't understand how it violates the rules you proposed. You proposed a scheme where part of the screen should be allowed to be significantly brighter than the surrounding SDR GUI's FFF. That makes the surrounding GUI look grey. > And obviously boosting the brightness of a scre…

The whole chip in the middle is brighter than white. Half that video is super bright, making this example way more than I was suggesting in both area and average brightness.

> most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF.

It's a lot more than I suggested, and I said average brightness half of FFF for my example.

Also if I knew you were going to hammer on the loose example numbers I would have said 2% or 1%.

> I'm bringing it up because that's how HDR looks on the web.

But I'm not defending how it looks. I'm defending how it could look, since you don't see why anyone would even want HDR on the web.

Re: Chrome Jpegxl Issue Reopened

#118

Post by mort96 »

Dylan16807 wrote: post #117
mort96 wrote: post #116

Earlier quoted context omitted.

> I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that. Other than the exaggerated 10x, I don't understand how it violates the rules you proposed. You proposed a scheme where part of the screen should be allowed to be significantly brighter than the surrounding SDR GUI's FFF. That makes the surrounding GUI look grey. > And obviously boosting the brightness of a scre…

The whole chip in the middle is brighter than white. Half that video is super bright, making this example way more than I was suggesting in both area and average brightness. > most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF. It's a lot more than I suggested, and I said average brightness half of FFF for my example. Also if I knew you wer…

This is going on for too long. Maybe you can somehow find a way to process all HDR content so that it's reasonable (i.e never makes the surrounding SDR GUI look grey, never makes bright pots which are bright enough to hurt) across all screens imaginable and all contexts. Maybe. I have my doubts, but go ahead.

Convince the web standards bodies and browser implementers and transform the world into one where HDR on the web is perfect and never causes issues.

But until that's done, there's a simple solution: Just don't support HDR. Until your hypothetical perfect solution is universally implemented, it does more harm than good on the web and should not be supported.

I don't see why anyone would want HDR on the web in its current form.

Re: Chrome Jpegxl Issue Reopened

#119

Post by Dylan16807 »

mort96 wrote: post #118
Dylan16807 wrote: post #117

Earlier quoted context omitted.

The whole chip in the middle is brighter than white. Half that video is super bright, making this example way more than I was suggesting in both area and average brightness. > most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF. It's a lot more than I suggested, and I said average brightness half of FFF for my example. Also if I knew you wer…

This is going on for too long. Maybe you can somehow find a way to process all HDR content so that it's reasonable (i.e never makes the surrounding SDR GUI look grey, never makes bright pots which are bright enough to hurt) across all screens imaginable and all contexts. Maybe. I have my doubts, but go ahead. Convince the web standards bodies and browser implementers and transform the world into one where HDR on the…

Well the reason I was talking about limits that way is because it's something screens already do when displaying HDR content. They can't go full power over much area, and the bigger you go the dimmer your limit gets. So repurposing those existing algorithms with some tweaking.

It's not very hard on a technical level.

And no it doesn't have to be universal and perfect to reach the point that HDR is a benefit. There are some blatant flaws that need fixing, and just a few fixes would get us a lot closer.

Re: Chrome Jpegxl Issue Reopened

#120

Post by mort96 »

Dylan16807 wrote: post #119
mort96 wrote: post #118

Earlier quoted context omitted.

This is going on for too long. Maybe you can somehow find a way to process all HDR content so that it's reasonable (i.e never makes the surrounding SDR GUI look grey, never makes bright pots which are bright enough to hurt) across all screens imaginable and all contexts. Maybe. I have my doubts, but go ahead. Convince the web standards bodies and browser implementers and transform the world into one where HDR on the…

Well the reason I was talking about limits that way is because it's something screens already do when displaying HDR content. They can't go full power over much area, and the bigger you go the dimmer your limit gets. So repurposing those existing algorithms with some tweaking. It's not very hard on a technical level. And no it doesn't have to be universal and perfect to reach the point that HDR is a benefit. There ar…

It has to be universally not harmful.

Again, go convince standards bodies and browser implementers to implement those algorithms after doing studies to demonstrate that it fixes the issue. Until then, I just don't want it in my browser.

Post reply on HN