| ▲ | kelseydh 4 hours ago |
| Every time a new image format comes out, I think about the compatibility crisis between apps. E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats. |
|
| ▲ | pmarreck 4 hours ago | parent | next [-] |
| JPEG-XL is not particularly patent-laden and its license is correct for the use-case. Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it. It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc. And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!) iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max). |
| |
| ▲ | crote 3 hours ago | parent | next [-] | | I think the bigger driver is that, due to it being the next PDF image format, most platforms will already be forced to add some form of support to it. When literally every OS already comes with a form of libjxl pre-installed there is no good reason not to add support for it. > you just truncate the output stream at the right proportion of pixel data Does the format have explicit support for this? As in, is there any easy way to do, say, an exact Range request after reading the file header? | | |
| ▲ | yangm97 2 hours ago | parent [-] | | That doesn’t seem related to the codec itself but rather how you fetch said image. Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url. |
| |
| ▲ | weberer 3 hours ago | parent | prev | next [-] | | >JPEG-XL is not particularly patent-laden and its license is correct for the use-case. The same could be said for .webm, but Apple refused to support it because they wanted to patent-laden alternative to thrive. | | |
| ▲ | alwillis 38 minutes ago | parent [-] | | > Apple refused to support it because they wanted to patent-laden alternative to thrive. Where do people get this stuff? Apple finally supported WebP in 2020, 10 years after it was released by Google. Firefox added WebP support in 2019, a year before Safari. Was Mozilla also part of conspiracy to undermine WebP? Come on now. Seems to me neither Apple or Mozilla wanted to be forced to support a format they had no say in developing. Usually there's a process for coming to consensus on standards. WebP is ubiquitous now, not the case in 2010 when it was released. It had advantages compared to JPEG, but not enough at the time to justify changing workflows, etc. WebP initially had better compression than JPEG, but as encoders/decoders improved (MozJPEG, Jpegli, turbo-libjpeg, Guetzli) the lead WebP had mostly went away regarding compression and visual fidelity. Going forward, WebP is becoming less relevant by the day; it doesn't support wide gamut color; it only supports RGB. It's max pixel count is quite limited compared to AVIF and JPEG XL. Newer formats have use cases beyond the web; WebP doesn't. |
| |
| ▲ | bmacho 43 minutes ago | parent | prev | next [-] | | > you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!) It's an attack vector for images to have different thumbnail/first bytes than the final image so software still have to decode the whole image. | | | |
| ▲ | zigzag312 an hour ago | parent | prev | next [-] | | Can progressive loading be made less fine-grained? With too many levels you don't know, if image is still loading or is just low-res. Loading vs loaded difference needs to be clear. | | | |
| ▲ | esafak an hour ago | parent | prev [-] | | The problem with progressive rendering is that the user never knows when downloading is complete unless you add loaders to each image. |
|
|
| ▲ | alwillis 3 hours ago | parent | prev | next [-] |
| > MacOS can take a long time to update with support for new formats. Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2]. When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder. [1]: https://webkit.org/blog/14445/webkit-features-in-safari-17-0... [2]: "iPhone 17 Pro’s Camera Leap: JPEG‑XL, Cleaner Shots, and Pro Filmmaking Tools" - https://modernengineeringmarvels.com/2025/09/19/iphone-17-pr... |
| |
| ▲ | mrpippy 4 minutes ago | parent [-] | | When Apple adopts jxl-rs? Any source for them doing that? I can’t think of any Rust code that Apple is shipping. |
|
|
| ▲ | weinzierl 4 hours ago | parent | prev | next [-] |
| True, but in my opinion JPEG XL has the right balance of features to become a true replacement of almost every relevant image format we use today, on the web and elsewhere. Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats. |
| |
| ▲ | cubefox 4 hours ago | parent | next [-] | | Yeah. Here is a surprisingly readable article on all the supported features and design decisions of JPEG XL:
https://arxiv.org/abs/2506.05987 The format is designed to be as general as possible, potentially replacing many common (JPEG, GIF, PNG) and professional image formats. For example, JPEG XL supports pages (e.g. for comic books), layers (with variable frame sizes, positions and blend modes) and timed animations. | | |
| ▲ | yangm97 2 hours ago | parent | next [-] | | I wish they had kept the support for progressive decoding of animations just like FLIF had but I guess they had to draw the complexity line somewhere. | |
| ▲ | Unai 2 hours ago | parent | prev [-] | | That was indeed surprisingly readable and very in-depth at the same time. Thanks for sharing! |
| |
| ▲ | shevy-java 4 hours ago | parent | prev [-] | | How about AVIF? I have not read that many direct comparisons here. | | |
| ▲ | spider-mario 3 hours ago | parent [-] | | Much worse at lossless at least. | | |
| ▲ | farlight 2 hours ago | parent [-] | | Depends on who you listen to, or what you test it on. It goes either way, and avif is typically significantly better at small files sizes where loading speed (or saving data) is the priority. | | |
| ▲ | mort96 28 minutes ago | parent | next [-] | | Really? The lossless comparisons I've seen has JXL winning over AVIF, do you have a link to the comparisons you've seen where AVIF wins in lossless? | |
| ▲ | spider-mario 2 hours ago | parent | prev [-] | | On lossless? No. |
|
|
|
|
|
| ▲ | Gormo 4 hours ago | parent | prev | next [-] |
| It's too bad that the concept of having a system-wide plugin architecture for importing/exporting formats never caught on outside a few niche platforms. AmigaOS had DataTypes back in the '80s, and BeOS had Translators back in the '90s. The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it. |
| |
| ▲ | GrantMoyer 3 hours ago | parent | next [-] | | Windows has, for a while, had Windows Imaging Component for images (https://learn.microsoft.com/en-us/windows/win32/wic/-wic-lh) and Microsoft Media Foundation for video (https://learn.microsoft.com/en-us/windows/win32/medfound/mic...). Not sure how widespread actual use is though. | | |
| ▲ | ack_complete an hour ago | parent [-] | | WIC is reasonably widely used since it's used by WPF to load images. The problem is that a plugin codec structure exposes you to bad codecs. We had a tool at work break because someone installed a fast image viewer that overrode the default WIC JPEG decoder with a faster one that crashed loading our tool's splash screen image. |
| |
| ▲ | etatester 4 hours ago | parent | prev | next [-] | | Codecs have been a thing on both major OSes, Windows Media Player could open DivX and QuickTime could open MKV. I think they were only limited to videos however. | | |
| ▲ | kccqzy 3 hours ago | parent [-] | | I think QuickTime 7 had that capability (I remember installing a codec to make it play wmv video) but Apple removed the plugin architecture in QuickTime X. |
| |
| ▲ | 3 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | zarify 4 hours ago | parent | prev | next [-] |
| Ugh. Every time I accidentally put a HEIC on my Windows machine, or one of my students tries to upload a WEBP to our school's LMS :/ |
| |
| ▲ | childintime 4 hours ago | parent [-] | | The user's OS or the LMS should offer to convert it on the spot. Worst case to .bmp |
|
|
| ▲ | 3 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | AlienRobot 4 hours ago | parent | prev [-] |
| If I remember correctly Instagram didn't support WebP either. |
