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

Google Revisits JPEG XL in Chromium After Earlier Removal

windowsreport.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#91

Post by gsnedders »

JimDabell wrote: post #22
adzm wrote: post #10

jxl-rs https://github.com/libjxl/jxl-rs was referenced as a possibility; what library is Safari using for jpegxl?

libjxl: https://github.com/libjxl/libjxl https://github.com/WebKit/WebKit/blob/7879cb55638ec765dc033d...

The second link isn't applicable to Apple's WebKit ports — it's entirely built via Xcode.

https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines USE_JPEGXL only for macOS All the in-tree JPEG XL support, e.g., https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... is behind a "USE(JPEGXL)" ifdef — so none of that is compiled in.

Instead, it's using what Apple ships at a system level, in Image I/O.

https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines HAVE_JPEGXL for recent versions of Apple's OSes. https://github.com/WebKit/WebKit/commit/932073284e4c73ce9884... is the commit which added this — there's really not much there, because it's just setting the define and adding it to the allowlist of image types.

And yeah, currently I believe this is libjxl — or a fork thereof — hence the inclusion of libjxl in the Acknowledgements.rtf file on macOS.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#92

Post by basilgohar »

account42 wrote: post #89
crazygringo wrote: post #61

Earlier quoted context omitted.

I find it incredibly helpful to know that .jpg is lossy and .png is lossless. There are so many reasons why it's almost hard to know where to begin. But it's basically the same reason why it's helpful for some documents to end in .docx and others to end in .xlsx. It tells you what kind of data is inside. And at least for me, for standard 24-bit RGB images, the distinction between lossy and lossless is much more impor…

> .png is lossless pngquant and similar tools disagree

pngquant does the lossy conversion, not the PNG format.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#93

Post by jorvi »

account42 wrote: post #89
crazygringo wrote: post #61

Earlier quoted context omitted.

I find it incredibly helpful to know that .jpg is lossy and .png is lossless. There are so many reasons why it's almost hard to know where to begin. But it's basically the same reason why it's helpful for some documents to end in .docx and others to end in .xlsx. It tells you what kind of data is inside. And at least for me, for standard 24-bit RGB images, the distinction between lossy and lossless is much more impor…

> .png is lossless pngquant and similar tools disagree

Well yeah, you can turn any lossless format lossy by introducing an intermediate step that discards some amount of information. You can't practically turn a lossy format into a lossless format by introducing a lossless intermediate step.

Although, if you're purely speaking perceptually, magic like RAISR comes pretty close.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#94

Post by jaffathecake »

eviks wrote: post #58
ksec wrote: 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…

> AV2 .... 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 at what cost? From this the en/decoding speed (links below) is much higher for those advanced video codecs, so for various lower powered devices they wouldn't be very suitable? Also, can we expect "near max potential" with AV2/near…

Fwiw, JPEG XL takes around 2.5x the time to decode as an equivalent AVIF, and has worse compression https://jakearchibald.com/2025/present-and-future-of-progres...

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#95

Post by spider-mario »

gen2brain wrote: post #27
jiggawatts wrote: post #25

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.

There’s more to it than that. Canon and Apple do HDR HEIC in mutually incompatible ways.

https://www.dpreview.com/articles/8980170510/how-hdr-tvs-cou...

> HEIF/HEIC is a broad standard, and the files from Canon and Apple are not cross-compatible with one another

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#96

Post by oktoberpaard »

fingerlocks wrote: post #82
oktoberpaard wrote: post #73

Earlier quoted context omitted.

What you are taking about is also called HDR, but has nothing to do with what the other person is talking about. The other person is talking about the still image equivalent of HDR video formats. When displayed on an HDR capable monitor, it will map the brightest parts of the image to the extended headroom of the monitor instead of tone mapping it to be displayed on a standard SDR monitor. So to be even more clear: i…

Even when HDR tone mapping in real time, such as a game engine or raw video feed, you would still be merging two or four multi-sampled tile memory blocks into a single output image. This is not fundamentally different, just a fancier pipeline on modern GPUs. And it’s completely unrelated to OPs rant about stupid developers preventing them for sharing their HDR images or whatever.

HDR photos taken on iOS or Android devices are displayed as SDR images when opened on Windows. The gain map that they contain (see ISO 21496-1) is ignored. Before the ISO standard it didn’t even work between iOS and Android. This is what OP’s frustration is about.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#97

Post by GuB-42 »

JyrkiAlakuijala wrote: post #87
GuB-42 wrote: post #86

Earlier quoted context omitted.

Brotli? Is it still relevant now that we have Zstandard? Zstandard is much faster in just about every benchmark, sometimes Brotli has a small edge when it comes to compression ratio, but if you go for compression ratio over speed, LZMA2 beats them both. Both Zstandard (zstd) and LZMA2 (xz) are widely supported, I think better supported than Brotli outside of HTTP.

Brotli decompresses 3-5x faster than LZMA2 and is within 0.6 % of the compression density, and much better for short documents. ZStandard decompresses ~2x faster than Brotli but is 5 % less dense in compression density, and even less dense for short documents or documents where the static dictionary can be used. Brotli is not slow to decompress -- generally a little faster then deflate through zlib. Last time I measu…

Straight from the horse's mouth!

The thing is that Brotli is clearly optimized for the web (it even has a built-in dictionary), and ZStandard is more generic, being used for tar archives and the likes, I wonder how PDF would fit in here.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#98

Post by eviks »

jaffathecake wrote: post #94
eviks wrote: post #58

Earlier quoted context omitted.

> AV2 .... 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 at what cost? From this the en/decoding speed (links below) is much higher for those advanced video codecs, so for various lower powered devices they wouldn't be very suitable? Also, can we expect "near max potential" with AV2/near…

Fwiw, JPEG XL takes around 2.5x the time to decode as an equivalent AVIF, and has worse compression https://jakearchibald.com/2025/present-and-future-of-progres...

Interesting, looks like another opportunity for Chrome to avoid the Safari mistake

> slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement.

Though their own old attempt was even worse

> of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#99

Post by alwillis »

jiggawatts wrote: post #11

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…

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

It appears we’re getting closer to being able to exchange HDR images [1]:

[1]: https://gregbenzphotography.com/hdr-photos/iso-21496-1-gain-...

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#100

Post by kasabali »

viktorcode wrote: post #35
mikae1 wrote: 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.

Samsung is claimed to be supporting it: https://cloudinary.com/blog/samsung-now-supports-dng-1-7-inc...
Post reply on HN