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

JPEG XL Test Page

tildeweb.nl

Post reply on HN
Print view View original

151–160 of 170 posts

Re: JPEG XL Test Page

#151

Post by p_ing »

Dylan16807 wrote: post #123
p_ing wrote: post #119

Earlier quoted context omitted.

They request formats that their equipment handles. They're not in the business of converting a user's file type from one to another. That would be inconsistent from what the user sent. Here's who I order from, you can see the particulars of what they request. https://support.bayphoto.com/hc/en-us/articles/4026658357979...

> They're not in the business of converting a user's file type from one to another. Their job is getting an image file into reality, not to be the absent owner of a big machine. > That would be inconsistent from what the user sent. If the machine accepts some type of normal image file, then they can losslessly convert other file formats to that type. There is nothing inconsistent about that.

You're free to make such assumptions.

Re: JPEG XL Test Page

#152

Post by iam-TJ »

pkulak wrote: post #106
senfiaj wrote: post #95

Starting from v145 Chrome supports JXL. There is also an extension for this: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhd...

And Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/

Firefox Nightly v149 has added experimental support via Settings > Firefox Labs:

  Webpage Display
  Media: JPEG XL
  With this feature enabled, Nightly supports the JPEG XL (JXL) format. This is an enhanced image file format that supports lossless transition from traditional JPEG files. See bug 1539075 for more details.

Re: JPEG XL Test Page

#153

Post by bmacho »

lonjil wrote: post #150
bmacho wrote: post #148

Earlier quoted context omitted.

That's not the reason , but the excuse . The reason Firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die. Also the parent comment was about that you really shouldn't just let a random Russian guy run any javascript on any website you visit, that's stupid. Also also, am I missing something, or Firefox extensions are broken , there is no way to limit an extension to…

> That's not the reason, but the excuse. The reason firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die. So what, you think they were just lying when they said that they'll ship JXL when it has a Rust implementation? You think Mozilla devs were just bluffing when they were working directly with the JXL devs over the last year to make sure everything would work rig…

No, I don't think they can withhold support if it's a no-brainer to support it. But they also tried everything they could to not support it.

Re: JPEG XL Test Page

#154

Post by tasty_freeze »

demetris wrote: post #128

I published some benchmarks recently: https://op111.net/posts/2025/10/png-and-modern-formats-lossl... I compare PNG and the four modern formats, AVIF, HEIF, WebP, JPEG XL, on tasks/images that PNG was designed for. (Not on photographs or lossy compression.)

It seems like the natural categories are (1) photographs of real things, (2) line art, (3) illustrator images, (4) text content (eg, from a scanned document).

Is there a reason you used only synthetic images, ie, nothing from group 1?

Re: JPEG XL Test Page

#156

Post by Dylan16807 »

p_ing wrote: post #151
Dylan16807 wrote: post #123

Earlier quoted context omitted.

> They're not in the business of converting a user's file type from one to another. Their job is getting an image file into reality, not to be the absent owner of a big machine. > That would be inconsistent from what the user sent. If the machine accepts some type of normal image file, then they can losslessly convert other file formats to that type. There is nothing inconsistent about that.

You're free to make such assumptions.

What are you calling an assumption?

My first statement is an opinion/judgement, not an assumption.

I'm confident my second statement is true. Note that any argument that says niche formats are a problem because color space might be ambiguous also applies to the formats they do accept.

Re: JPEG XL Test Page

#157

Post by demetris »

tasty_freeze wrote: post #154
demetris wrote: post #128

I published some benchmarks recently: https://op111.net/posts/2025/10/png-and-modern-formats-lossl... I compare PNG and the four modern formats, AVIF, HEIF, WebP, JPEG XL, on tasks/images that PNG was designed for. (Not on photographs or lossy compression.)

It seems like the natural categories are (1) photographs of real things, (2) line art, (3) illustrator images, (4) text content (eg, from a scanned document). Is there a reason you used only synthetic images, ie, nothing from group 1?

Hey, tasty_freeze!

The motivation behind the benchmarks was to understand what are the options today for optimizing the types of image we use PNG for, so I used the same set of images I had used previously in a comparison of PNG optimizers.

The reason the set does not have photographs: PNG is not good at photographs. It was not designed for that type of image.

Even so, the set could do with a bit more variety, so I want to add a few more images.

Re: JPEG XL Test Page

#158

Post by tedd4u »

demetris wrote: post #144
enimodas wrote: post #136

Earlier quoted context omitted.

Would be nice to also see decompression speed and maybe a photo as a bonus round.

Yeah. Numbers for decompression speed is one of the two things I want to add. The other is a few more images, for more variety.

Max memory required during decompression is also important. Thanks for sharing this research.

Re: JPEG XL Test Page

#159

Post by N19PEDL2 »

judah wrote: post #51
uyzstvqs wrote: post #36

JPEG XL is also good, but why not use AVIF? It's widely supported by browsers, and rivals JPEG XL in being the best lossy image format.

Jake Archibald has an excellent post about progressive image rendering, including some metrics on JPEG XL compared to AVIF[0]. > "I was also surprised to see that, in Safari, JPEG XL takes 150% longer (as in 2.5x) to decode vs an equivalent AVIF. That's 17ms longer on my M4 Pro. Apple hardware tends to be high-end, but this could still be significant. This isn't related to progressive rendering; the decoder is just s…

>> My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought.

This would be great.

Re: JPEG XL Test Page

#160

Post by flexagoon »

dylan604 wrote: post #66
flexagoon wrote: post #26

Earlier quoted context omitted.

I feel like "jpeg" has generally become a shorthand for "low quality compressed digital picture"

I feel like you need to find better places on the internet. It's no longer 1997 downloading from dial up.

I'm not saying it's true, I obviously understand that not all jpegs are low quality and over compressed. That's just how the word is generally used by people, especially those outside of tech who aren't well versed in different image formats.
Post reply on HN