jonsneyers

5 ms·

1.
by jonsneyers 8mo ago
Exactly. Image compression should excel at avoiding excess. Though maybe some people think the JPEG committee is now creating spreadsheet formats...
2.
by jonsneyers 8mo ago
JPEG XP would have been a nice name for a successor of JPEG 2000, I suppose :) There's also a JPEG XE now ( https://jpeg.org/jpegxe/index.html ), by the way.
3.
by jonsneyers 8mo ago
PNG can and is often used in a lossy way. Reducing the number of colors so PNG8 can be used instead of PNG24/PNG32 is the most common way to do that. Tools like pngquant exist, and for example Photoshop when exporting to PNG also has a
4.
by jonsneyers 10mo ago
It's technically correct. Googlers (at Google Research Zurich) have been working on jxl-rs, a Rust implementation of JPEG XL. Google Research has been involved in JPEG XL from the beginning, both in the design of the codec and in the i
5.
by jonsneyers 11mo ago
For lossless, bitdepth of course does matter. Lossless image compression is storing a 2D array of integer numbers exactly, and with higher bitdepth, the range of those numbers grows (and the amount of hard-to-compress least significant bits
6.
by jonsneyers 1y ago
Thanks! Yes, my hope is that jxl can become an interoperable format for layered images. It does not have all the functionality of image editor formats (PSD, XCF, etc), but it does have a very useful subset of that (named layers with basic b
7.
by jonsneyers 2y ago
This article is from 2020. I think so far it has aged reasonably well. But you might be interested in my more recent articles too. You can find those here: https://cloudinary.com/blog/author/jon_sneyers
8.
by jonsneyers 2y ago
Last time I tested, libjxl e1 had a better compression ratio than default libpng, while being two orders of magnitude faster. See https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the... The point of reference h
9.
by jonsneyers 2y ago
Lossless compression is not about importance of data. Lossless is lossless, if the result of a roundtrip is not EXACTLY IDENTICAL then it is by definition not lossless but lossy. Maybe you're confusing with "visually lossless&quot
10.
by jonsneyers 3y ago
The above claims are not very accurate. JPEG and JPEG 2000 were based on the principle that the core codec was royalty-free but there might be patent-encumbered optional things (such as arithmetic coding, in the case of JPEG) that could be
11.
by jonsneyers 3y ago
JPEG XL is a royalty-free codec and "generating revenue streams" was never a goal for the project. You can see this already in the very first draft call for proposals from 2017: https://jpeg.org/downloads/jpeg
12.
by jonsneyers 3y ago
Chair of the JPEG XL adhoc group of JPEG here. I wasn't around when the name for this project was chosen (I only got involved after the call for proposals, at which point the codec already had a name even if it didn't exist yet).
13.
by jonsneyers 3y ago
Thanks for the suggestion, oxipng is indeed a better choice. Next time I will add it to the plots!
14.
by jonsneyers 3y ago
It is unlikely that there will be any bitstream changes in JPEG XL. There is still a lot of potential for encoder improvements within the current bitstream, both for lossy and for lossless.
15.
by jonsneyers 3y ago
No it doesn't. And yes, regular JPEG is still a fine format. That's part of the point of the article. But for many use cases, better compression is always welcome. Also having features like alpha transparency, lossless, HDR etc ca
16.
by jonsneyers 3y ago
Assuming the websites are using images of appropriate dimensions (that is, not using huge images and relying on browser downscaling, which is a bad practice in any case), you can quite easily do the math. A 1080p screen is about 2 megapixel
17.
by jonsneyers 3y ago
Humans generally tend to prefer smoothing over visible blocking artifacts. This is especially true when a direct comparison to the original image is not possible. Of course different humans have different tastes, and some do prefer blocking
18.
by jonsneyers 3y ago
It has lossless just to check a box in terms of supported features. A bit like how JPEG XL supports animation just to have feature parity. But in most cases, you'll be better off using a video codec for animation, and an image format f
19.
by jonsneyers 3y ago
You are right, but that would make an uglier plot :) Some of the intermediate options are available though, through various more fine-grained encoder settings than what is exposed via the overall effort setting. Of course they will not fall
20.
by jonsneyers 3y ago
This matters way more for video (where you are decoding 30 images per second continuously) than it does for still images. For still images, the main thing that drains your battery is the display, not the image decoding :) But in any case, t
21.
by jonsneyers 3y ago
Safari/Webkit has added JPEG XL support already. Firefox is "neutral", which I understand as meaning they'll do whatever Chrome does. All the code has been written, patches to add JPEG XL support to Firefox and Chromium
22.
by jonsneyers 3y ago
Lossless WebP is very good indeed. The main problem is that it is not very future-proof since it only supports 8-bit. For SDR images that's fine, but for HDR this is a fundamental limitation that is about as bad as GIF's limitatio
23.
by jonsneyers 3y ago
Both rav1e and libaom have a speed setting. At similar speeds, I have not observed huge differences in compression performance between the two.
24.
by jonsneyers 3y ago
No browser bothers with hardware decode of WebP or AVIF even if it is available. It is not worth the trouble for still images. Software decode is fast enough, and can have advantages over hw decode, such as streaming/progressive decodi
25.
by jonsneyers 3y ago
There are no royalties to be paid on JPEG XL. Nobody but Cloudinary and Google is claiming to hold relevant patents, and Cloudinary and Google have provided a royalty free license. Of course the way the patent system works, anything less th
26.
by jonsneyers 3y ago
If you read the Chromium bugtracker comments ( https://bugs.chromium.org/p/chromium/issues/detail?id=117805... ) and see the messages of support from e.g. Facebook, Adobe, Intel, VESA, Krita, etc then I think i
27.
by jonsneyers 3y ago
Those Microsoft patents are not relevant for JPEG XL. Their licensing is therefore also not relevant for JPEG XL.
28.
by jonsneyers 3y ago
Actually Safari added support for three new image formats at the same time: JPEG XL, AVIF and HEIC.
29.
by jonsneyers 3y ago
JPEG XL uses the ISOBMFF container, with an option to skip the container completely and just use a raw codestream. HEIF is also ISOBMFF based but adds more mandatory stuff so you end up with more header overhead, and it adds some functional
30.
by jonsneyers 3y ago
Containers are just containers — you still need a decoder for their payload codec. This is the same for video and images. For video, containers are more important because you typically have several different codecs being used together (in p

More ›