What rest of the industry? Apple is clearly not interested, neither is Microsoft[0], and xl weirdoes have been busting mozilla's balls for years with little progress.
Even if you manage to bully Mozilla into shipping and default-enabling xl rather than just removing it, Firefox is currently sitting at an incredible 2.5% market share (and I'm saying that as a Firefox user).
[0] well they obtained a patent on rANS so they might be interested in other people using it I guess, that's money in the bank: https://www.theregister.com/2022/02/17/microsoft_ans_patent/
They have made no such statement AFAIK. The fact that they adopted AVIF relatively swiftly, and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two.
Can be linked to Apple being a governing member of AOM.
> and generally improved their cadence a bit, makes me ready to not be surprised if they ship JPEG XL in a year or two.
Feel free to hold your breath, but I don't think that'll be good for your health.
The webkit bug for AVIF was opened in February 2020, an "initial support" patch was proposed in May, support was merged in March 2021. Apple separately shipped the decoder[0] in iOS and macOS in September/Octoboer 2022, and enabled the feature for Safari.
The webkit bug for JXL was opened in February 2020. That's about all that's happened to it. Reaction has been:
- Webkit is not super interested in adding a bunch of third-party unsafe code[1]
- Safari support requires OS support, which is non-existent for JXL[2]
[0] Webkit on non-apple platforms can use Webkit's decoders, on Apple platforms it uses CoreGraphics, though as seen with HEIF having CG support doesn't mean Apple enables the format in Safari.
[1] https://lists.webkit.org/pipermail/webkit-dev/2021-May/03184...
[2] https://lists.webkit.org/pipermail/webkit-dev/2021-May/03185...
To be clear I didn’t say I’m holding my breath. Just that it’s not “obviously” impossible.
Apple ain’t going to enable features they don’t support on safari.
That's why there are regular "Webkit features in Safari X": that something is added to webkit does not guarantee it'll land in Safari, ever.
Hell, it took 18 months and 2 iOS/macOS releases for the AVIF support to go from landing in Webkit to landing in Safari. And that was something Apple wanted.
Neither was webm support, but that didn't stop them from taking several years to implement it (and even then it was half-finished). Apple clearly wants to play the superiority game with their own codecs. They have zero incentive to support any codecs they didn't build, and have been known to abandon standards that they help develop.
Nothing is technically impossible for Apple, but codec support is stuck between an ideological/financial rock and a hard place.
And on the other end you have Google who threatens others if they don't bend over and implement Google's codecs in hardware [1]. The codecs space is, and has always been, a game of shitty players.
[1] e.g. https://www.protocol.com/bulletins/av1-android-14-requiremen... and https://www.protocol.com/youtube-tv-roku-issues
Which doesn’t seem to be the case with this format.
And in any case, I think the person you responded to is referring to non-web actors like Abode, who seem to like JXL.
In the article I linked, the creator of ANS asserts that Microsoft's patent covers the variant used in JXL.
A Cloudinary lead says it doesn't but they're not a lawyer, and it's not exactly in their interest to say it does.
> And in any case, I think the person you responded to is referring to non-web actors like Abode, who seem to like JXL.
That is completely irrelevant to Chrome, why would Google change their mind on that basis?
This doesn't necessarily mean JPEG XL is patent-encumbered (the patent is still annoying, but not necessarily this way). It is recommended for ISO standards that relevant patents should be disclosed and available on a non-discriminatory basis [1], and while patent holders can ignore this recommendation they generally have no reason to do so. In the case of JPEG XL only Google [2] and Cloudinary [3] filed patent declarations, so Microsoft is reasonably thought to have no patents relevant to JPEG XL.
[1] https://www.iso.org/iso-standards-and-patents.html
[2] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770...
[3] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770...
Microsoft is a member of ISO. They're obligated to notify ISO if they have any relevant patents to new standards. The subcommittee that JPEG is part of is even chaired by a Microsoft employee, so it's not like they'd be unaware.
Duda seems to think that Microsoft's patent simply covers rANS in general, but this seems dubious. Not only would it cover a lot more than JXL, it would have shitloads of prior art. The patent seems to describe an improvement of rANS, which isn't used in JXL.
Further still, Microsoft has straight up said that the patent is free to use for any open codec.
> That is completely irrelevant to Chrome, why would Google change their mind on that basis?
WebP adoption was slowed, and is to some extent widely hated, because it for many years had zero support outside the web. Not only is JXL seeing faster than adoption outside the web than WebP, it's seeing faster adoption than AVIF. That seems relevant to me. And of course, web companies literally can't adopt it until at least one browser starts supporting it. Shopify already serves JXL when you enable the flag. Facebook wants to use it. Yet Chrome's devs claim that there is basically no ecosystem interest. It's pretty ridiculous.
https://encode.su/threads/3863-RANS-Microsoft-wins-data-enco...
No one has any plans to decode AVIF still images in hardware. There are two problems. The subset of AV1 supported by hardware is much narrower than what is in practice used in AVIF images. Such images cannot be decoded by hardware. Second is that it actually doesn't get you any speed. Each image would need to be shuffled to the GPU, decoded, then sent back because browsers aren't really set up right for doing everything on the GPU. And any non-stateless HW decoder would be problematic, since every single image would need to reconfigure the decoder state, which is slow.
This isn’t a problem on any mobile SoC because “sent to the GPU” doesn’t mean anything on a unified memory system. (And Safari does use hardware image decoding.)
The majority of AVIF images are hardware decodeable, even if most viewers don't bother with it. The biggest limitation is that profile 0 decoders are 4:2:0 only, but that describes the majority of Web images.
Krita, GIMP, DarkTable, Affinity, and freaking Adobe are just "some" image viewing programs to you?
Adobe supports it... for importing, but you can't export to JXL. You can count plenty of obscure photo formats like JPEG 2000, IFF, PCX, OpenEXR, etc. in that category.
I guess I’m not an actual user.
Starting to think Firefox users can be put on the "non team players list" and "people that have something to hide list".
As for the amount of existing JPEGs that people care about decreasing over time: This might eventually become true, but only to a point. People's existing photo archives are generally all JPEGs. People care about even (especially?) the older images in their photo albums. And it will take a long time before everyone is adding exclusively AVIF-encoded rather than JPEG-encoded images to their archives.
As for people's photo albums. The iPhone is already storing new images in HEIF, so JPEGs are becoming less relevant with each passing day. And of course, you can still view the old images perfectly fine as JPEGs.
Old images in your photo library aren't becoming less relevant with each passing day. I don't know why you would suggest that they are. I know that iPhone has switched to storing images as HEIF and nothing in my comment suggested otherwise.
Yes exactly, nothing new is unlocked. So why would I use this format? Was the old size of the images preventing me from enjoying them in any way? No. Of all the old JPEGs out there that absolutely must be losslessly transcoded from the already lossy JPEG encoding, how many are prohibitively large? You can still look at both a JPEG and JPEG XL image locally. Most likely you'd be able to serve both images over HTTP, although the JPEG image may take a bit longer to load. And how many cases require the new and old images be exactly the same? My point is that, if the main selling point of your codec is that you can create the same thing as 30 years ago only smaller, then it's going to be a hard sell compared to other formats out there. If the choice was between JPEG and JPEG XL, then sure, let's use JPEG XL. But the choice is between JPEG XL and other formats with better features.
Other image formats like AVIF add new features that enhance images. Yes, the images are smaller, but also way more powerful. Image sequences, for instance, enable new features like "live images." Converting your old JPEG to a smaller JPEG isn't going to magically enable live images.
tldr: I'm looking for a reason to care that I can losslessly re-transcode my old JPEGs. Ok, the re-transcoded images are smaller and exactly the same as before, but what is a real world reason why I would need that vs. using the old JPEG directly or re-transcoding it to AVIF?
Because the size is smaller and the quality is the same? Literally the same reason why you'd use any new image format, except that this benefit also applies to existing images, not just new ones?
I'm not against AVIF or anything, if you want to add future images which are using fancy animation features from AVIF then that's cool. You don't have to choose between image formats, you can (and already do!) use the right one for the task.
> tldr: I'm looking for a reason to care that I can losslessly re-transcode my old JPEGs. Ok, the re-transcoded images are smaller and exactly the same as before, but what is a real world reason why I would need that vs. using the old JPEG directly or re-transcoding it to AVIF?
You can use the old JPEG directly, but then your library takes up more space. If you re-transcode your old JPEGs to AVIF, you're losing quality or at the very least irreversibly changing the images.
I'm not arguing that it's the world's biggest deal or anything, but a free 20% size reduction on all photos in an image library and all JPEGs sent over the web doesn't seem like a bad deal.
Technology is a means to an end. Transcoding images is a means. The end is what you do with it. In the 90s and early 2000s, encoding images in JPEG allowed for digital cameras to store vastly more images on their limited storage space. Bandwidth was extremely limited, so JPEG encoding allowed for detailed images to be shared over the web, which wouldn't have been possible in a different format. Today, however, storage and bandwidth are cheap. JPEG already does a decent enough job for old images. Making old images even smaller isn't really enabling any new "ends."
I guess the ultimate question I'm asking is "Why do you want your old JPEGs to be smaller?" What is the end you hope to achieve with smaller JPEGs?
But anyway, this conversation was helpful. I guess there aren't really many reasons to use JPEG XL.
Killer feature #1 is compressing existing JPEG images. Nothing else can do this
Killer feature #2 is HDR images with over 10 bits of depth and high resolution. It comes out of your camera/phone already like this but we can't post it online! What a joke
Images that can't be displayed without Javascript. Incredible.
And also, JavaScript should always be enabled. Very very few people disable it and they are used to have a broken web experience anyway so it’s not an issue to ignore them. Worst case they don’t see pictures until they eventually enable JavaScript.
Executing third party code in a sandbox is a security risk. You need to allow a level of risks when you use your computer on internet, and by disabling third party code you are safer but you also have a lot less useful computer.
Why? Most pages are static text and images, most pages don't need JS. So why should JS be always enabled?
I know the folks who advocate turning off JavaScript think that such reduced functionality is a worthwhile tradeoff, but they don't know what they're missing in a very literal sense. And I can't help but suspect the main benefit they're getting is not improved security; it's a warm, fuzzy feeling of smugness. Many of them probably also use Emacs.
https://en.m.wikipedia.org/wiki/List_of_most_visited_website...
Because you're immediately excluding people on old devices, on underpowered devices, on devices on bad networks, on devices with weird/incomplete/glitchy/limited support for what you need, sites where JS just errors out (and dies, because there are no recovery options if there's a global JS error)... And the list just goes on, and on, and on.
The inability of developers to look beyond their latest-and-greatest dev machines with unlimited power and everything under the sun enabled is just mind boggling.
AVIF is an ad hoc agreement from an industry coalition interested in web media delivery. There are literally no individuals or governments participating, only big internet media corporations and companies producing solutions for internet media needs.
JPEG XL is an international standard related to a larger field of interests (photography, print, industrial quality assurance imaging, multi-spectral imaging, space technology, heat cameras, mastering, raw-like imaging, medical imaging, storage, archiving, media delivery, government needs, ...). Participation fee is moderage and individuals can participate.
https://jpeg.org/jpegxl/documentation.html
All we have is a whitepaper.
[1] Previously on HN: https://news.ycombinator.com/item?id=32885509
Besides from that technicality though, do you really think that publicly available standards would have changed the situation? I don't think so---Chrome (and to be clear, most other browsers) has supported tons of closed standards anyway.
No. A closed standard is not a standard.
> Besides from that technicality though, do you really think that publicly available standards would have changed the situation? I don't think so---Chrome (and to be clear, most other browsers) has supported tons of closed standards anyway.
I think it might have helped, yes.
Please elaborate.
But I wouldn't say it's a "closed" standard. Not any more closed than, say, the C++ standard or the Unicode standard. What makes a standard open is not the price the publisher puts on the copies, imo, but how transparent and open the process is to design and change the standard, and whether it is possible or not to implement and use the standard for free or not. In that regard, I would consider JPEG XL just as open a standard as C++ or Unicode.
The HEVC spec is publicly available without paywall, but you cannot freely implement and use this standard since it's a patent encumbered, very non-royalty-free codec. I consider it a closed standard for that reason, and the spec being available for free (but not implementable without paying royalties) does not make much of a difference imo.
The original JPEG standard is an ISO standard (ISO/IEC 10918) with payed access.
MP3 is also an ISO standard (ISO/IEC 13818-3). Perhaps not as relevant today but was once used by basically everyone.
Access to the standard is only relevant to the implementer. It's of no consequence to users of a piece of software.
Open Standard does not mean Free Standard. As much as I would want the Final Spec 1.0 to be freely available.
https://www.iso.org/standard/77977.html
Anyone interested in doing an independent implementation can use this specification (or a recent draft of the upcoming 2nd edition). Alternatively, you can look at the source code of one of the three JPEG XL implementations currently available: libjxl, J40, and jxlatte. These are all open-source, and in a way that's an executable specification.
Is it simply just one that cost money to access?
If I made a language standard on my own it would not be a open standard from quite a few orgs point of view. It is annoying that you are just throwing around vague use of words without giving a clear definition.
What is a closed standard?
Also the world run on those documents with little to no relevance, no matter how much people dislike how you need to pay to view them. It is a sad state of affairs.
If you actually wanted to make changes you would lobby for it, you are just saying they don't exist which is of little help to change the status quo.
Squoosh – In-browser image converter[42]
Adobe Camera Raw – Adobe Photoshop's import/export for digital camera images[43]
Affinity Photo – raster graphics editor[44]
Chasys Draw IES – raster graphics editor[45]
Darktable – raw photo management application[46]
ExifTool – metadata editor[47]
FFmpeg – multimedia framework, via libjxl[48]
GIMP – raster graphics editor[49]
gThumb – image viewer and photo management application for Linux[50]
ImageMagick – toolkit for raster graphics processing[51]
IrfanView – image viewer and editor for Windows[52]
KaOS – Linux distribution[53]
Krita – raster graphics editor[54][55]
libvips – image processing library[56][57]
vipsdisp – high-performance ultra-high-resolution image viewer for Linux[58]
Qt and KDE apps – via KImageFormats[59]
XnView MP – viewer and editor of raster graphics[60]
Pale Moon – web browser[61]It also support PSDs. Should Chrome support PSDs?
> Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF.
Ah yes, Google, a major contributor to JXL, is "clearly biased towards AVIF".
I'm sure you'll find your saviours at Apple (governing member of AOM, shipped AVIF this year), Mozilla (governing member of AOM, shipped AVIF in June 2020, default-enabled in October 2021), or Microsoft (governing member of AOM).
Why is it surprising to you? Many major companies are contributors to a bunch of standards that they don't end up supporting. Meanwhile Google is forcing device manufacturers to support its codecs in hardware on pain of sanctions and removing support and software. Guess which codec Google wants them to support (hint: AV1)
PSD is a pretty heavy format, and does not have the benefits for serving images to end users (e.g. good compression) that JPEG XL/AVIF have. So probably not. But there are still use cases for serving PSDs on the web in creative communities, so it would be pretty cool to have.
> Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:
> - Experimental flags and code should not remain indefinitely
> - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL > - The new image format does not bring sufficient increm ental benefits over > existing formats to warrant enabling it by default
> - By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome
---
If I were to put on my tinfoil hat, I would imagine the people involved here are desperate to put 'Removed unused code and removed maintenance burden by X%' in there performance reviews for this year
Also AVIF is more performant for most cases. Lossless is not what matters on the web.
However, if the enthusiastic support in the Chromium bugtracker from Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, and Shopify is any indication, it seems baffling to conclude that there would be insufficient ecosystem interest.
That's why I assumed there was demand for JPEG XL.
Unlike AVIF, JPEG XL also has advanced progressive delivery features, which is useful for the web. And if you look at the testing described in the post, JPEG XL also achieved higher subjective quality per compressed bit, despite having a faster encoder.
You can see lossless benchmarks against other formats here:
https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp...
If a new image format doesn’t have a hardware decoder it’s dead. The security surface of new formats is unacceptable if it’s going to be slow and power-hungry too.
Only problem with JPEG is the lack of HDR.
1) transfer JPEG XL,
2) decode the JPEG XL to DCT coefficients,
3) encode a new JPEG1 file
4) decode the new JPEG1 file
5) render pixels
JPEG XL as image format:
1) transfer JPEG XL
2) decode the JPEG XL to DCT coefficients
3) render pixels
Two additional coding steps (3 and 4) are needed in the HTTP Content Encoding approach. If we want to transfer lossless JPEG1s, it is less computation and a faster approach to add JPEG XL as an image codec.
If JPEG XL is too powerful and creates danger for AVIF, then one possibility is to remove features such as adaptive quantization, lossless encoding and larger (non-8x8) DCTs. This effectively makes JPEG XL as JPEG1 recompressor as an image codec.
Also, JPEG XL's reference implementation (libjxl) has a more accurate JPEG1 decoder than any other existing implementation. Asking someone else to paint the pixels leads to worse quality (about 8 % worse).
AVIF fails to deliver a consistent experience at 3+ BPP -- I'd hate to compress my family pictures at AVIF even at high BPP, some part is smudged in a weird way.
libjpeg-turbo and mozjpeg does deliver a consistent experience at 4 BPP
guetzli and jpegli delivers a consistent experience at 3 BPP
JPEG XL delivers a consistent experience at 1.7 BPP
Source? JPEG XL has already shown, over 10,000 sample size and over a wide variety of BPP to be better than AVIF, on latest JPEG And AVIF versions.
AVIF, on the other hand, has yet to shown anything similar.
If you take your approach, nothing new (including the webp standard that Google/Chrome pushed) would be released on the web because nothing is using it.
AVIF is the first one that might be acceptable.
AVIF is a Netflix engineer quick-hacking a video format as an image format -- without actual experience in codec design, image compression or psychovisual research, without consulting such people to get the design right. When size and memory limitations were noticed, a tiled approach was proposed where globally spanning artefacts through the image will emerge. No one has been able to propose a fix for this and other kludges yet.
AVIF doesn't match WebP lossless in density, even given the 10 years more of compression research. AVIF doesn't even beat PNG at lossless, which itself was hacked together in a few months ~25 years earlier (primitive filtering, mixing filter bytes with image data, botched 16 bits compression, layering a primitive 1980's byte-compressor and filtering instead of designing a codec).
(Also EOG and IrfanView are image viewers, not production tools.)
If someone controls something it is the Chromium/AOM/AVIF/AV1 team that controls and decides what multimedia formats go inside Chrome/Chromium thus controlling what is used on the web and ignoring what the web community has to say about it.
From the view of AOM members or supporters, yes they are or at least not clear.
Because I have not seen anyone other than Cloudinary and Google declare to have patents relevant to JPEG XL, and those two parties have explicitly granted royalty-free licenses. So to me the situation is as clear as it gets.
Of course it can always happen with anything less than 20 years old that a patent troll appears and makes claims. This has not happened yet though in the case of JPEG XL.
Sounds complicated. Why not PNG? :-)
This is the answer. You can also build your own application-specific codecs this way.
I've been exploring a variation of jpeg/mpeg that uses arithmetic coding and larger block sizes. Virtually all of the fun patented stuff we couldn't use in the early 00's is in the public domain now.
I have no horse in the JPEG XL race. I am not even necessarily focused on images. I see value in using WASM (and/or JS) for application-specific codecs. That is all.
None of my decisions have any ability to make things "worse" for other browsers, especially when those browser vendors never intended to support my application-specific codec to begin with.
What other browsers? Desktop Firefox users who changed a flag in about:config? That's practically nobody.
It's simply a matter of using <canvas> for progressive rendering.
- Rendering images from a different origin without CORS. This is a fundamental limitation of any JS or WebAssembly solution and can't be fixed. Thankfully this use case is relatively rare.
- Not all approaches can provide a seamless upgrade. For example if you replace all `<img src="foo.jxl">` with a canvas DOM will be changed and anything expecting the element to be HTMLImageElement will break. Likewise, CSS Painting API [1] (a relevant part of CSS Houdini) requires you to explicitly write `paint(foo)` everywhere. The only seamless solution will be therefore a service worker, but it can't introduce any new image format; it can only convert to natively supported formats. And browsers currently don't have a "raw" image format for this purpose. JXL.js [2] for example had to use JPEG as a delivery format because other formats were too slow, as I've been told.
- It is very hard to check if a certain image is visible or not, and react accordingly. This is what I intended to imply by saying that canvas has to unconditionally retain all pixels, because if implementations can't decide if it's safe to unload images, they can't do so and memory will contain invisible images in the form of canvases. Browsers do have a ground truth and so can safely unload currently invisible images from memory when the memory pressure is high.
[1] https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...
You can get around many these compatibility issues by creating a custom element that inherits from HTMLImageElement. This provides API compatibility. For CSS compatibility, the elements you would replace in a MutationObserver would be the same tag name but a different namespace for CSS compatibility.
For the CSS compatibility trick, see https://eligrey.com/demos/hotlink.js/ which replaces images with CSS-compatible (not HTMLImageElement-compatible) iframes.
> - It is very hard to check if a certain image is visible or not, and react accordingly.
You can use Element.checkVisibility()¹ and the contentvisibilityautostatechanged event²𝄒³ to do this. Browser support is currently limited to Chromium-based browsers.
1. https://drafts.csswg.org/cssom-view/#dom-element-checkvisibi...
2. https://github.com/vmpstr/web-proposals/blob/main/explainers...
3. https://caniuse.com/mdn-api_element_contentvisibilityautosta...
Canvases are rectangles. The viewport is a rectangle. Checking if rectangles overlap is easy.
See: https://jsmpeg.com
I think I will continue using it with WASM polyfills, in hopes that Google will change their mind once the rest of the industry has switched to JXL.