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

The case for JPEG XL

cloudinary.com

Post reply on HN
Print view View original

101–110 of 210 posts

Re: The case for JPEG XL

#101

Post by hypothesis »

jokabrink wrote: post #52

I think the solely reason why JPEG XL did not go off is simple: It had no lobby. No large tech company actively promotes it and so, many people hadn't heard of it. Ironically, the deprecation of it in chrome made me aware of it in the first place. Technically, JPEG XL may be a superior contestant. But from a 'social' point of view? Disastrous, especially considering it already has "JPEG" in it. (To be fair, its also…

Now imagine that you saw a presentation couple years back with all the nice features that smart people packed in… and here is what it came to, parlor games basically.

Maybe a nimbler PR approach would help, but then we know that standards like websql are shutdown over nothing, even though sqlite eating the world alive…

Re: The case for JPEG XL

#102

Post by JyrkiAlakuijala »

vanderZwan wrote: post #98
enimodas wrote: post #94

Tangentially, in his linked page "hall of shame" https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMUL... , he argues humans prefer row A to row C. Personally in most cases I prefer row C. It may have less color accuracy, but is often a lot sharper, which in my eyes stands out a lot more.

Did you read the sentence right after he makes that claim? > At Cloudinary, we recently performed a large-scale subjective image quality assessment experiment, involving over 40,000 test subjects and 1.4 million scores. This isn't about your, my or Jon Sneyer's individual opinions on these photos, it's the consensus of 40,000 test subjects. And yeah, I agree with you that for a significant number of photos I disagree…

Psychovisual image quality tests are difficult and complicated. Selection of the population, methods, guiding text, motivation, etc. can lead to strange things happening.

As an example of the difficulties an academy leading corpora TID2013 has a reversal in quality between categories 4 and 5 -- highest quality images seem to get slightly worse quality ratings than the next highest quality images.

I observed a leading image quality laboratory to produce substantially different results for the same codec when the person conducting the experiments changed.

There are hard opinions if images should be reviewed one image pixel to one monitor pixel, or if images should be zoomed like they are in practical use, particularly on mobile.

Should zooming be allowed? Should people be allowed to move closer to the monitor if they want as part of the viewing? etc. etc.

Re: The case for JPEG XL

#103

Post by vanderZwan »

JyrkiAlakuijala wrote: post #102
vanderZwan wrote: post #98

Earlier quoted context omitted.

Did you read the sentence right after he makes that claim? > At Cloudinary, we recently performed a large-scale subjective image quality assessment experiment, involving over 40,000 test subjects and 1.4 million scores. This isn't about your, my or Jon Sneyer's individual opinions on these photos, it's the consensus of 40,000 test subjects. And yeah, I agree with you that for a significant number of photos I disagree…

Psychovisual image quality tests are difficult and complicated. Selection of the population, methods, guiding text, motivation, etc. can lead to strange things happening. As an example of the difficulties an academy leading corpora TID2013 has a reversal in quality between categories 4 and 5 -- highest quality images seem to get slightly worse quality ratings than the next highest quality images. I observed a leading…

Yes, I agree it is incredibly hard. On the other hand, if anyone has put in the work to give the "least bad answer so far" to this question it's Jon Sneyers.

I don't have time to dig through Twitter just now, but instead of just picking one image metric they've used all of them to also compare the testing methods themselves.

Re: The case for JPEG XL

#104

Post by MagnumOpus »

plantain wrote: post #4
sedatk wrote: post #3

Browser support: - JPEG XL: none - HEIF: none - AVIF: all but Edge - WebP: all

JPEG-XL is already implemented in ~95% of browsers in the wild (Chrome, Edge, Opera and Firefox), just only behind a flag.

That list seems desktop centric - more browsing happens on the mobile. Hence Safari is a glaring omission on your list... Until Safari for iOS implements JPEG-XL, it is sadly not ready for mass deployment.

Re: The case for JPEG XL

#105

Post by danielheath »

syrgian wrote: post #92
conaclos wrote: post #89

Earlier quoted context omitted.

Could you elaborate on 5) thermal camera support? How thermal camera could replace normal camera (this only capture infrared light?)? Why thermal camera are more ecological-friendly?

It would not replace the existing cameras. A thermal camera is a great tool for energy conservation: you can find misbehaving appliances consuming too much electricity idling, compare waste of different appliances, heat leaks at home, find hotspots in devices you maintain (say, a badly connected cable can offer extra resistance and become hot). Though I don't think thermal cameras will be user affordable for a long w…

I picked up a basic one for about $60 on aliexpress. It's good enough to find heat leaks at home, but only barely, and to get usable results I had to turn the home heating to maximum (to increase the thermal contrast).

The ones that let you just walk into a house and immediately see cold areas cost more like $800.

Re: The case for JPEG XL

#106

Post by danielheath »

toastal wrote: post #93
squarefoot wrote: post #74

Earlier quoted context omitted.

Situation has changed dramatically wrt points 1 and 2 since years, however. As for 3, I'm no web developer so can't comment on this.

The dev tools are really good in Firefox and its browser forks.

One or two devtool features are better in firefox, but when I gave it a good try a year or so back I had the devtools get stuck / crash / fail to find an element that's onscreen moderately often - enough that I'm not keen to use it for work by default.

Re: The case for JPEG XL

#107

Post by vanderZwan »

JyrkiAlakuijala wrote: post #25

Beautifully written article -- I couldn't agree more. From my personal point of view the biggest impact are: 1) e-commerce textures such as cloths are more faitfully represented -- more trust in e-commerce, more revenue 2) more equity for selfies, people-of-color skin is better represented in JPEG XL, selfies in general look more people like with less smoothing of skin performed at compression stage -- I'm a great fr…

Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all.

For example, I remember reading somewhere that there are people looking at whether or not it makes sense to convert all of the existing JPEGs to JPEG XL on their servers for storage, then reconstruct the JPEG when needed. If so, then there is a niche where it can find adoption even if browsers don't support it yet. It also looks like it might find a use for medical and scientific imaging.

What I personally really would like to know is if it would be possible to losslessly recompress the RAW files from my camera. It looks like it should support everything required, and the claim that it "is the first serious candidate to become a universal image format that “works across the workflow”, in the sense that it is suitable for the lifecycle of a digital image, from capture and authoring to interchange, archival, and delivery" kind of implies that it is, but I haven't seen anyone say it out loud yet.

Because I must say: DNG is really slow and clunky to work with, and I bet has terrible compression on top of that.

Re: The case for JPEG XL

#108

Post by markdog12 »

delroth wrote: post #67
Heikete wrote: post #53

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting f…

How is this relevant to this article given that Firefox has never shipped JPEG XL support in a public build? Not even behind an experimental flag like Chrome did.

They did. image.jxl.enabled in about:flags

Re: The case for JPEG XL

#109

Post by jonsneyers »

Semaphor wrote: post #88
jl6 wrote: post #68

Earlier quoted context omitted.

There’s a Twitter thread by a JPEG XL dev who tries to explain some of this in terms of the XYB color space giving more bits to dark tones: https://mobile.twitter.com/jonsneyers/status/155021585930558... But I’m not clear if this was a design goal of JPEG XL, or a theoretical side-benefit, or something you would need an HDR screen to appreciate (I couldn’t tell the difference in any of the example images, but those m…

Also not sure if this is a Twitter issue (wait, another reason not to use twitter? So why do people keep using it for something it’s bad at? /rant), but I got a different result. I can clearly see the differences between the encodings (I shuffled the images and sorted them by perceived quality), and I disagree that JXL looks better / is less racist. For both sides, the AVIF version looks significantly better, but esp…

It was probably a bad idea to put such examples on twitter, since twitter recompression is quite aggressive and makes a big difference.

I don't have the original decoded images nearby but it is best to do these kinds of comparisons without any recompression.

Re: The case for JPEG XL

#110

Post by jonsneyers »

markdog12 wrote: post #108
delroth wrote: post #67

Earlier quoted context omitted.

How is this relevant to this article given that Firefox has never shipped JPEG XL support in a public build? Not even behind an experimental flag like Chrome did.

They did. image.jxl.enabled in about:flags

Warning: this only works in nightly builds of firefox. In stable and beta they have the flag but they're not compiling the code, so it just doesn't work.
Post reply on HN