Hacker News Reader

Comment by Pxtl | Hacker News Reader

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images

Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format.

For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.

View on HN

If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs.

JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that.

The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.

Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression.

Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.

Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.

In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'.

You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gained widespread support in browsers, it had competition from other interesting formats like FLIF, which addressed some of its flaws, and I have to wonder how it compares to the even older JPEG 2000.

FLIF got integrated in to JPEG-XL as the modular mode.

If I recall correctly, that's FUIF, originally created by the same author as FLIF's successor of sorts.

Not really. FLIF is too slow to decode, about 20x slower than WebP lossless. JPEG XL modular mode uses a similar static context modeling with WebP lossless and Brotli and likely LZHAM where all the entropy codes are generated at decoding time. Also JPEG XL forces tiled coding, making multi-threaded decoding a possibility.

When I built WebP lossless format I kept testing design decisions against PNG. The average gain against my Internet PNG test corpus was 42 % and 26.5 % if I optimized the PNGs with pngcrush and pngout (kzip). I had not yet come up with ZopfliPNG ideas, those were backports from some WebP lossless ideas into gzip and PNG.

You're not being fair. Webp has been the only choice for lossy image compression with alpha layer. Give it some credit.

Fair point, though not entirely true: you can run an image through lossy compression and store the result in a PNG, using tools like pngquant [1]. Likely not as efficient for many kinds of images, but totally doable.

[1] https://pngquant.org/

I think there's a difference here.

If I right click save and get a webp, it was probably converted from JPG. Very very few images are uploaded in webp. So getting a webp image means you've downloaded an inferior version.

JXL doesn't have this issue because conversion from jpeg is lossless. So you've still gotten the real, fully-quality image.

Let's be realistic - when most users are upset they got a .webp, they're not annoyed because of quality-loss, they're annoyed because they can't immediately use it in many other services & software.

This is still a problem with AVIF, too. Image viewers that support the format often don't support animated AVIFs, and even GitHub still for some godforsaken reason treats .avif files in a repo/PR as binary files instead of images. I think Discord just recently started supporting AVIFs, so that's progress.

20% is massive for those storing those social media images though.

I get that there are people who are super excited by this for very good reasons, but for those of us downstream this is just going to be a hassle.

> For example, ask a normal social media user how they feel about .webp and expect to get an earful.

I've seen enough software that gets petulant about not supporting webp to fight the Google monopoly or whatever to understand their frustration.

That's also not the only potential gain. You get 20% gain on baseline compression but you also no longer need to store variants at different sizes since JPEG-XL's progressive decode is essentially equivalent to downscaling in terms of quality.

i.e. you can also serve downscaled & thumbnail versions directly from the original image.

Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.

AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go.

Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels.

With that in mind I'd actually prefer if those were treated as separate file-formats with distinct file-extensions (backwards-compatible jpeg->jxls vs pure-jxl). The former could be trivially handled with automated tools, but the latter can't.

I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)

Well, sure, but wasn’t that the use case we were discussing?

Right. And that particular use-case sounds nice, but realistically this new format will not be exclusively used in that particular case.

Dealing with basically another .webp-like format in those cases (one that might be a backwards-compatible jpeg or might not and determining that can only be done by inspecting the file contents) doesn't sound super fun.

So ideally, to make up names, I wish they'd used separate extensions and so a ".jp3" is a file that can be downconverted to a jpg and you could get a browser extension to automate that for you if you wanted, and a ".jxl" is the new file format that's functionally another ".webp"-like thing to deal with and all the pain-points that implies.

The names and extensions of JPEG XL files aren't specified, except that the IANA media type is `image/jxl`. I think an argument could be made to use the double extension convention when the encoder performs lossless JPEG recompression, so image.jpg becomes image.jpg.jxl (while not entirely semantically correct, since it's not an additional layer of compression around the JPEG, it's a reimplementation of the image using identical coding features as JPEG, in JXL).

But like I said in my other comment (which got hidden for some reason), it should be noted that a recompressed JPEG is also a valid JXL on its own. If you have the means to turn a recompressed JPEG into the original, you also have the means to view native JXLs.

Hopefully adoption is widespread and we won't really have to worry about it. JPEG XL is a much more appealing format than WebP, and unlike WebP there are great arguments for software to support it other than "Google started using them, so they're everywhere now."

Reply on news.ycombinator.com