Live data from Hacker News

Google Revisits JPEG XL in Chromium After Earlier Removal

windowsreport.com

31–40 of 104 posts

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#31

Earlier quoted context omitted.

> I can share HDR images via phones Sure, me too! I can take a HDR P3 gamut picture with my iPhone and share it with all my friends and relatives... that have iPhones. What I cannot do is take a picture with a $4000 Nikon DSLR and share it in the same way... unless I also buy a Mac so I can encode it in the magic Apple-only format[1] that works... for Mac and IOS users. I have a Windows PC. Linux users are similarly…

Not that I disagree, but HEIF is a container format. What is inside that container is essential. HEIC in HEIF, AVIF in HEIF, etc.

Sure, but Apple doesn't fully support HEIC either.

They support only a very specific subset of it, in a particular combination.

Some Apple apps can open third-party HEIC-in-HEIF files, and even display the image correctly, but if you try anything more "complex", it'll start failing. Simply forwarding the image to someone else will result in thumbnails looking weirdly corrupted, brightness shifting, etc...

I've even seen outright crashes, hangs, visible memory corruption, etc...

I bet there's at least one exploitable security vulnerability in this code!

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#32

2026 is nearly upon us, and Google, Microsoft, and Apple remain steadfast in the refusal to ever allow anyone to share wide-gamut or HDR images. Every year, I go on a rant about how my camera can take HDR images natively, but the only way to share these with a wider audience is to convert them to a slideshow and make a Rec.2020 HDR movie that I upload to YouTube. It's absolutely bonkers to me that we've all collectiv…

Just use PNG: https://www.w3.org/TR/png-3/ (for HDR content, see the cICP, mDCV and cLLI chunks; also note that PNG supports up to 16-bit channel depth out of the box).

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#33
post #29

It is absolutely insane that google has not implemented this yet. They implement all sort of unimportant stuff but not the most critical image format of this decade, what a joke

And the things they do implement, they kill 8 or so years later.

https://killedbygoogle.com/

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#34
post #9

Earlier quoted context omitted.

What I mean to say is, I believe browsers do support JPEG 2000 in PDF, just not on the web.

the last time that I check it, I find that I need to convert to Jpeg to show the image in browsers.

A *PDF* with embedded JPEG 2000 data should, as far as I know, decode in modern browser PDF viewers. PDF.js and PDFium both are using OpenJPEG. But despite that, browsers don't currently support JPEG 2000 in general.

I'm saying this to explain how JPEG XL support in PDF isn't a silver bullet. Browsers already support image formats in PDF that are not supported outside of PDF.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#35
post #2

The final piece of the JPEG XL puzzle!

A large and important piece, but not the final. If it will remain web-only codec, that is no Android and iOS support for taking photos in JPEG XL, then the web media will still be dominated with JPEGs.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#36
post #30

While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinem…

>medical images

Isn't JPEG-XL a lossy codec?

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#37
post #36
post #30

While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinem…

>medical images Isn't JPEG-XL a lossy codec?

It has both lossy and lossless modes.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#38
post #7

Earlier quoted context omitted.

Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?

I don't think so: JPEG 2000, as far as I know, isn't generally supported for web use in web browsers, but it is supported in PDF.

So Firefox (or others) can't open a pdf with a embedded jpeg-2000/XL? Or does pdf.js somehow support it?

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#40
post #36
post #30

While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinem…

>medical images Isn't JPEG-XL a lossy codec?

JPEG-XL is both a lossy and lossless codec. It is already being used in Camera DNG format, making the RAW image smaller.

While lossy codec is hard to compare and up for debate. JPEG-XL is actually better as a lossless codec in terms of compression ratio and compression complexity. There is only one other codec that beats it but it is not open source.

Post reply on HN