The links are buried somewhere on Phoronix, I am looking... But what I am saying is Google's rejection of JXL seems to be as bad as it looks.
If AOMedia was profit driven in any way (like MPEGLA sorta is via patent pools) it'd look worse, but in this case I just think it's the case that the pool of people working on codec support in a particular browser probably isn't that large so the overlap is to be expected.
I hate to claim something without a citation, but for the life of me I can't find my Phoronix comment... Only my other comments referencing it.
[0] https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
(Chicken and egg problem here of course which is no one will create the websites until there is wide browser support.)
> We have tested conformance of the jxl-oxide decoder (which is implemented in Rust) and it is a fully conforming alternative implementation of JPEG XL. It correctly decodes all conformance test bitstreams and passes the conformance thresholds described in ISO/IEC 18181-3.
There are other decoders [0] written in a "safe language" (rust) listed as well. So no there are many "safe" implementations
A while back I fuzz tested qemu's handling of various different disk image formats (I know, a different type of "image", but bear with me!) I found many cases where qemu could consume huge amounts of memory or CPU time on some inputs. Often times the inputs were quite small too, allowing nasty amplification attacks. As a result of this standard advice for clouds that allow you to upload untrusted images is to decode in a separate process. That process is protected with ulimits, so it will die, rather than trying to allocate all memory in the machine or consume huge amounts of CPU.
There's the WebAssembly sandboxing trick (https://hacks.mozilla.org/2021/12/webassembly-and-back-again...) which might mitigate that, but an image decoder might fall into the "too performance-sensitive to accept the modest overhead incurred" case.
https://github.com/web-platform-tests/interop/issues/430#iss...
And Microsoft seems to be interested and want to integrate it into Windows : https://news.ycombinator.com/item?id=39163181
They keep harping about JXL's technical superiority (who disagrees btw?) when at this point it is utterly clear that the choice to boot it from browsers have precisely nothing to do with technical concerns.
No lies detected and so painfully obvious.
If you take into account that jxl was and is in large part an effort supported internally by Google teams, and fought against by another, a fairly occam's razor like explanation is that someone at Google with influence is deeply butthurt because another team built a better toaster.
JPEG XL support has officially been removed from Chromium https://news.ycombinator.com/item?id=33933208 (292 points, 378 comments)
Original comment: Ironically, .JXL opens natively on the Mac, but can't open in any browser. It's the exact opposite of .WEBP which can't open on Mac but too many websites seem to use it. https://jpegxl.info/test-page/
I suppose it depends on what version of macOS you're running; on my Mac running Sonoma, WebP files open just like JPEGs, PNGs, etc. and have for the last 2 or 3 macOS versions.
Are you sure? When I click that link Firefox downloads the image file, which then opens correctly in Safari.
Sure… if by "finally" you mean 1,175 days ago—November 16, 2020. That how long ago WebP has been supported in Safari [1].
[1]: https://webkit.org/blog/11340/new-webkit-features-in-safari-...
Some industry leads believe that the tone mapping is part of artistic creativity and belongs to the photographer. I don't share this viewpoint, but I'm looking at this from a purely technical and philosophical viewpoint. I think we should have HDR first world, and SDR is a temporary fallback.
And its done incorrectly way too often.
(I am sitting on no high horse here, I'm guilty of it as well).
There's a reasonable cost/benefit argument against standardizing JPEG XL in browsers. You don't have to agree with it, but JPEG XL proponents shouldn't just ignore it.
The argument is: (1) the cost is large -- implementation and maintenance of a complex image codec takes time, and image codecs are high-risk from a security perspective. (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases.
Now, you don't have to agree with that argument -- e.g. you can argue the cost isn't that high, or that there are valuable advantages to jxl for significant use cases that aren't covered by existing alternative.
But you do need to engage that argument.
Otherwise what else do you have? Popular demand isn't going to work, because you're in a chicken-and-egg situation. I suppose you can try to bribe and/or bully key decision makers for all the major browsers, though I hope that wouldn't work.
their jpeg encoder often barely compress anything
Since they pay their CEO $7MM per year, this is a profoundly infuriating argument.
Clearly a good investment, Firefox market share is lower and lower, and has been steadily declining since Google became Mozilla's main income source.
2 millions millions dollars? that's 10^12 dollars.
https://corporatefinanceinstitute.com/resources/fixed-income...
Completely ignoring the potential of replacing PNG or WEBP, Completely ignoring actually competing against AVIF. The benefits of JXL when it comes to losslessly saving space for pre-existing images is so massively significant, it's hard to believe that this single feature alone doesn't meet the bar of worth.
The old Google that cared deeply about the web would have been all over this. This current regime--not so much.
It's probably no coincidence that many of the folks who were huge advocates for the web are no longer there.
If you look at the history of Google employees created the basis for JPEG XL [1], having it included in beta builds of Chrome and then removing it "for reasons", it's pretty obvious it wasn't pulled for technical or security reasons.
Obviously Apple didn't think there were significant security and implementation issues preventing them from enabling JPEG XL on over 2 billion devices.
The Chrome team has proposed a number of web features and APIs that Apple, Mozilla and sometimes Microsoft don't want to implement due to security and privacy reasons. Usually that doesn't stop Chrome from going ahead and shipping them anyway.
> (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases.
JPEG XL does provide advantages over existing alternatives—The Case for JPEG XL [2]:
In the past, new image formats have been introduced that brought
improvements in some areas while also introducing regressions in
others. For example, PNG was a great improvement over GIF,
except that it did not support animation. WebP brought
compression improvements over JPEG in the low to medium fidelity
range but at the cost of losing progressive decoding and
high-fidelity 4:4:4 encoding. AVIF improved compression further,
but at the cost of both progressive decoding and deployable
encoders.
We looked at six aspects of JPEG XL where it brings significant
benefits over existing image formats:
* Lossless JPEG recompression (20% on average)
* Progressive decoding
* Lossless compression performance
* Lossy compression performance
* Deployable encoder
* Works across the workflow
> Lossless JPEG recompression (20% on average)
Lossless JPEG recompression isn't that valuable because it's a "tweener" solution. If you mainly just care about image size, you can live with some loss and can recompress jpegs using existing formats. Or if you care about size and quality, you can recompress from high-quality sources using existing formats. lossless jpeg recompression kind of fits in the middle somewhere... you care enough about size to go through the trouble to recompress, but you don't care so much that you will use high-quality sources and you care about quality enough that you don't want to lose quality when recompressing, but again not so much that you will use high-quality sources. So it's not nothing, but not great either.
> Progressive decoding
A solution to a vanishing edge case.
> Lossless compression performance
Explains why you might want to use jxl in your workflow but that's not a browser concern.
> Lossy compression performance
This sounds good, but is it enough better over existing formats to justify a new one in the browser? I don't think it's clear cut.
> Deployable encoder
Obviously, existing formats have deployed encoders.
> Works across the workflow
Not a browser concern. Note that even if you use jxl across your entire workflow, you're still going very typically have a publishing step for images where you find and use a level of compression/quality appropriate for your project. There's not really any particular difference if the general image format type has changes at this step or not.
(Disclaimer: I’m a JPEG XL contributor.)
She was recently on the Syntax Podcast, and I thoroughly enjoyed the talk. Can catch a bit here: https://www.threads.net/@syntax_fm/post/C22hyslOABy/
>Pretty much all modern video/audio/image codecs are
The exact opposite is true. The most popular modern codecs are almost all royalty-free. WebP, AVIF, JXL are all royalty-free. VP9/AV1 are royalty-free. Opus is royalty-free.
Why single out JPEG XL?
WebP is one of the most recently added image formats, and it had zero day exploits as recently as 6 months ago.
The current debate is about JPEG XL vs AVIF. Advantages of old image formats are not relevant here.
That not a measure of security.
How many malware exists for MacOS compared to Windows. Does that mean MacOS is safer?
You could easily argue the other way around that WebP and say has more undiscovered exploits.
Hopefully it isn't singled out, and any prospective support for a new image format gets the same scrutiny.
The question is different for any image format that is already supported, because removing it breaks the web to the extent the format is being used. That's really an argument to be particularly careful about adding support for a new format: once it is widely available for a while it is almost impossible to remove. This is a one-way decision (unless it's barely used, in which case there wasn't a good reason to add it in the first place).
Nothing you've said should be an issue. I expect really they just don't want "their" formats to be obsoleted.
For any format you can store an image at multiple resolutions/quality-levels and a responsive app can download the one with the size/quality it wants.
jxl probably saves an incremental amount of storage, which is nice, but storage is not usually the dominant cost of anything. So this is still an edge case.
The point is not needing to store multiple copies of an image. You can simplify the back-end if you serve the same file to all clients.
You’re assuming that the high-quality original is still available. If the JPEG is all you have, then losslessly recompressing it is the smallest file of the highest quality you can get.
That's what I mean by "tweener" solution. You care a little about quality because you don't want to lose any more that you already have lost in your jpg, but not so much that you're keeping track of the high-quality originals. It's not nothing, but it's also not a big deal.
There will always be some new format with some advantage or another, but safely parsing complex user generated content just isn't trivial, so every one of these is both a cost benefit analysis on its own merits but also a chance to reflect on historical implementations, vulnerabilities, and lessons learned.
The image formats past WebP offer very minor improvements but have big potentials for new zero-days. I don't think it's wrong to play it safe and/or just don't implement them.