Hacker News Reader

Comment by e-topy | Hacker News Reader

Instead of using a new PNG standard, I'd still rather use JPEG XL just because it has progressive decoding. And you know, whilst looking like png, being as small as webp, supporting HDR and animations, and having even faster decoding speed.

https://dennisforbes.ca/articles/jpegxl_just_won_the_image_w...

View on HN

JPEG XL definitely has advantages over PNG but there is one serious seemingly insurmountable obstacle:

https://caniuse.com/jpegxl

Nothing really supports it. Latest Safari at least has support for it not feature-flagged or anything, but it doesn't support JPEG XL animations.

To be fair, nothing supports a theoretical PNG with Zstandard compression either. While that would be an obstacle to using PNG with Zstandard for a while, I kinda suspect it wouldn't be that long of a wait because many things that support PNG today also support Zstandard anyways, so it's not a huge leap for them to add Zstandard support to their PNG codecs. Adding JPEG-XL support is a relatively bigger ticket that has struggled to cross the finish line.

The thing I'm really surprised about is that you still can't use arithmetic coding with JPEG. I think the original reason is due to patents, but I don't think there have been active patents around that in years now.

> The thing I'm really surprised about is that you still can't use arithmetic coding with JPEG.

I was under the impression libjpeg added support in 2009 (in v7). I'd assume most things support it by now.

Believe it or not, last I checked, many browsers and some other software (file managers, etc.) still couldn't do anything with JPEG files that have arithmetic coding. Apparently, although I haven't tried this myself, Adobe Photoshop also specifically doesn't support it.

Arithmetic coding decodes 1 bit at a time, usually in such a way that you can’t do two bits or more with SIMD instructions. So it will be slow and energy inefficient.

this isn't necessarily true. zstd uses an ans which is a type of arithmetic coding which is very efficient to decode

Nice to learn about. It’s good to know the field has progressed, however the context focused on JPEG, where my point does apply.

Deompression is limited by memory bandwidth IME, which means that more efficient compression is (almost) always more power-efficient too.

(I don't have numbers for this, but it was generally agreed by the x264 team at one point.)

> Nothing really supports it.

Everything supports it, except web browsers.

JPEG-XL is supported by a lot of the most important parts of the ecosystem (image editors and the major desktop operating systems) but it is a long way away from "everything". Browsers are the most major omission, but given their relative importance here it is not a small one. JPEG-XL is dead in the water until that problem can be resolved.

If Firefox is anything to go off of, the most rational explanation here seems to just be that adding a >100,000 line multi-threaded C++ codebase as a dependency for something that parses untrusted user inputs in a critical context like a web browser is undesirable at this point in the game (other codecs remain a liability but at least have seen extensive battle-testing and fuzzing over the years.) I reckon this is probably the main reason why there has been limited adoption so far. Apple seems not to mind too much, but I am guessing they've just put so much into sandboxing Webkit and image codecs already that they are relatively less concerned with whether or not there are memory safety issues in the codec... but that's just a guess.

Apple also adopted JPEG-XL across their entire software stack. It's supported throughout the OS, and by pretty much every application they develop, so I'm guessing they sunk a fair bit of time/money into hardening their codec

> >100,000 line multi-threaded C++

W. T. F. Yeah, if this is the state of the reference implementation, then I'm against JPEG-XL just on moral grounds.

Only because it's both the reference encoder and decoder, and the encoder tends to be a lot more complex than the decoder. (Source: I have developed a partial JPEG XL decoder in the past, and it was <10K lines of C code.)

> reference

They aren't going to give you two problems to solve/consider: clever code and novel design.

On Linux the browser can and should link dynamically against the system library for image formats.

webp still got a vulnerability

You can use a polyfill.

That's because people have allowed the accumulation of power and control by Big Tech. Features in and capabilities of end user operating systems and browsers are gate kept by a handful of people in Big Tech. There is no free market there. Winners are picked by politics, not merit. Switching costs are extreme due to vendor lock in and carefully engineered friction.

The justification for WebP in Chrome over JPEG-XL was pure hand waving nonsense not technical merit. The reality is they would not dare cede any control or influence to the JPEG-XL working group.

Hell the EU is CONSIDERING mandatory attestation driven by whitelisted signed phone firmwares for certain essential activities. Freedom of choice is an illusion.

Webp is a lot older than jpg xl, right?

It was behind a feature flag and then removed? I guess that's where the skepticism comes from

It's also because supporting features is work that takes time away from other bug fixes and other features

> I kinda suspect it wouldn't be that long of a wait

Yeah... guess again. It took Chrome 13 years to support animated PNG - the last major change to PNG.

Maybe they were focused on Webp?

APNG wasn't part of PNG itself until very recently, so I'd argue it's kind-of neither here nor there.

Every new image codec faces this challenge. PNG + Zstandard would look similar. The ones that succeeded have managed it by piggybacking off a video codec, like https://caniuse.com/avif.

Why would PNG + ZStandard have a harder time than AVIF? In practice, AVIF needs more new code than PNG + ZStandard would.

I'm just guessing, but bumping a library version to include new code cam integrating a separate library might be the differentiating factor.

The zstd library is already included by most major browsers since it is a supported content encoding. Though I guess that does leave out Safari, but Safari should probably support Zstd for that, too. (I would've preferred that over Brotli, but oh well.)

Btw, could you 'just' use no compression on this level in the PNG, and let the transport compression handle it?

So on paper (and on disk) your PNG would be larger, but the number of bits transmitted would be almost the same as using Zstd?

EDIT: similarly, your filesystem could handle the on-disk compression.

This might work for something like PNG, but would work less well for something like JPG, where the compression part is much more domain specific to image data (as far as I am aware).

If there is a particular reason why that wouldn't work, I'm not aware of it. Seems like you would eat a very tiny cost for deflate literal overhead (a few bytes per 65,535 bytes of literal data?) but maybe you would wind up saving a few bytes from also compressing the headers.

5 bytes per block or 0.000076 overhead.

zstd compresses less, so you wait a bit more for your data

It is possible to polyfill an image format, this was done with FLIF¹². Not that it mean FLIF got the traction required to be used much anywhere outside its own demos…

It is also possible to detect support and provide different formats (so those supporting a new format get the benefit of small data transfer or other features) though this doesn't happen as it isn't usually an issue enough to warrant the extra complication.

----

[1] Main info: https://flif.info/

[2] Demo with polyfill: https://uprootlabs.github.io/poly-flif/

Any polyfill requires JavaScript which is a dealbreaker for something as critical as image display, IMO.

Would be interesting if you could provide a decoder for <picture> tags to change the formats it supports but I don't see how you could do that without the browser first downloading the PNG/JPEG version first, thus negating any bandwidth benefits.

Depending on the site it might be practical to detect JS on first request and set a cookie to indicate that the new format (and polyfill) can be sent on subsequent requests instead of the more common format.

Or for a compiled-to-static site just use <NOSCRIPT> to let those with no JS enabled to go off to the version compiled without support/need for such things.

> but there is one serious seemingly insurmountable obstacle

It can be surmounted with WebAssembly: https://github.com/niutech/jxl.js/

Single thread demo: https://niutech.github.io/jxl.js/

Multithread demo: https://niutech.github.io/jxl.js/multithread/

Maybe for websites like Instagram that consist primarily of images. For everywhere else you have to amortize the cost of the download over the savings for the number of images in an average browsing session, as browsers segment the cache so you can't assume it will be available locally hot.

Actually I wonder, why in general not more decoders are just put into webassembly and are actually kept 'hot' on demand. Couldn't this also be an extension? Wouldn't that reduce the attack surface? I remember a time when most video and flash was a plugin. People would download the stuff. On the other hand using a public CDN at least would keep the traffic down for the one hosting the website.

Browser makers could easily let resources opt out of cache segmentation and then if everyone agreed on a CDN, or a resource integrity hash of a decoder, the wasm could be hot in the cache and used to extend the browser without Chrome needing to maintain it or worry about extra sandboxing.

They don't do it because they don't want people extending the web platform outside their control.

As I understand it JPEG XL has a lot of interest in medical imaging and is coming to DICOM. After it's in DICOM, whichever browser supports it best will rule hospitals.

Ha, yeah right, hospitals are still running IE11 in some places in the US

Yes, you're right. It'd be lovely to not need to install a DICOM viewer plugin thing.

JPEG XL support will probably resemble JPEG 2000 support after enough time has passed:

https://caniuse.com/jpeg2000

Except JXL has actual value unlike J2K which wasn't that much more efficient than JPEG and much slower.

So far, it is following the same pattern. Safari adopts it, no one else does and then one day, Safari drops it. It is currently on step 2. When step 3 occurs, the cycle will be complete.

except DNG, ProRAW, DICOM, GDAL, TIFF, Apple's and Microsoft's operating systems, Linux distros, and Windows support JPEG XL

otherwise the same

Look at the caniuse.com links. It is following the same pattern as JPEG 2000 in those charts. That is a fact.

It's better when the way it works is "this is format is good, therefore we will support it" rather than "people support this format, therefore it is good".

>he thing I'm really surprised about is that you still can't use arithmetic coding with JPEG

Or AVC YUV44 with Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1368063). Fortunately, AV1 YUV444 seems to be supported.

PNG with ZStandard or Brotli is much worse than WebP lossless.

I don't like progressive decoding. Lots of people don't realize that it's a thing, and complain that my photo is blurry when it simply hasn't loaded fully yet. If it just loaded normally from top to bottom, it would be obvious whether it has loaded or not, and people will be able to more accurately judge the quality of the image. That's why I always save my JPEGs as baseline encoding.

Is there no good progress indicator that gets you the best of both worlds - instant image recognition and the ability to wait and get better quality?

Web browsers already have code in place for webp (lossless,vp8) and avif (av1, which also supports animation), as well as classic jpeg and png, and maybe also HEIC (hevc/h265)... what benefit do we have by adding yet another file format if all the use cases are already covered by the existing formats? That said, I do like JPEG-XL, but I also kind of understand the hesitation to adopt it too. I imagine if Apple's push for it continues, then it is just a matter of time to get supported more broadly in Chrome etc.

Avif is cute but using that as an excuse to not add jxl is a travesty. At the time either one of those could have been added, jxl should have been the choice.

The biggest benefit is that it's actually designed as an image format. All the video offshoots have massive compromises made so they can be decoded in 15 milliseconds in hardware.

The ability to shrink old jpegs with zero generation loss is pretty good too.

The benefits are better quality, higher speed, and more features like progressive decoding. JXL is a single multi-trick pony unlike the others

Good summary https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...

Doesn't PNG have progressive decoding? I.e. adam7 algorithm

It does, using Adam7: https://en.wikipedia.org/wiki/Adam7_algorithm

The recently released PNG 3 also supports HDR and animations: https://www.w3.org/TR/png-3/

> The recently released PNG 3 also supports HDR and animations: https://www.w3.org/TR/png-3/

APNG isn't recent so much as the specs were merged together. APNG will be 21 years old in a few weeks.

True, but https://news.ycombinator.com/item?id=44802079 presumably holds the opinion that APNG != PNG, so I mentioned PNG 3 to counteract that. Animated PNGs being officially PNG is recent.

Adam7 is interlacing, not progressive decoding (i.e. it cannot be used to selectively decode a part of the image). It also interacts extremely poorly with compression; there is no good reason to ever use it.

Reply on news.ycombinator.com