One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched.
Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.
Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.
Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.
Didn't have time to test GCP DICOM store back in the day (not that I'm going to use it, as I've always been working in-house...), but, how is it? Is it a full fledged PACS? a WADO implementation? just a custom API?
You can do that and that's one of the big appeals. You can serve bost JXL and JPEG from the same source and you8 can actually serve downscaled versions of the JXL image from the original bytestream.
Also OP did say "transcode on the fly" to serve JPEG, not actually storing as JPEG.
This is for when you receive JPEG encoded DICOMs. You transcode them to JPEG XL (saving that 20% of storage) and then, if a modality/viewer/whatever that needs JPEG requests them, they're transcoded on the flight to JPEG losslessly.
Losslessly meaning, with the same quality than the original JPEG received by the storage.
JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere.
That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.
To address selected claims made in the post:
• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).
• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.
• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).
So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.
Yes AVIF is better at compressing than jpeg and even webp, that should be taken for granted given its a newer format. But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use. Real world usage paints a very different picture.
JXL not only has better compression rates at equivalent qualities for sane settings, it does so with faster encoding and decoding, while also supporting progressive decoding leveraging image saliency.
AV2 might bring it closer on par with JXL in compression but to suggest they're at all equal is a joke.
> But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use.
At 1080p, a 100k AVIF image is good enough to serve on a webpage. The same image as a 100k JXL will (probably) look unacceptible.
Source: every year or so, I play around with encoding my blog's images with AVIF and JXL. Smaller AVIF images look ok, but the equivalently sized JXL images look way worse. (And before you accuse me of re-encoding lossy to lossy images, most images I test with are game screenshots stored as PNGs.)
I seem to recall that a large part of the stated rationale at the time the Chrome Team decided to deprecate support for JXL was that they had support for both AVIF and JXL, and AVIF was good enough.
This might be the origin of the "competition" in the context of this Google decision/reversal.
This is all fine and good until you actually try encoding such an image with libjxl. What an absolute garbage codebase. I'm sure it's gotten better since I've last used it, but it's impressive how unoptimized, memory hungry, and of course wildly unsafe/crashy it was. Many of the options just completely didn't work, either due to exponential performance, crashes, or weird special-casing that breaks the moment you encode anything that's dissimilar from the sample images used in the sham benchmark made by the libjxl creators. I don't even think a high resolution image had ever been successfully encoded on higher effort levels, since I doubt that anyone trying to do so had the terabytes of RAM required.
I was genuinely flabbergasted when there was mass support for reviving it a couple years ago. I don't think anyone advocating for it has actually used libjxl at all and were just internet hypemen. That seems to happen all too often nowadays.
This all being said, I'm mildly optimistic for a retry with jxl-rs. However, seeing much of the same contributors from libjxl on jxl-rs does make me quite cautious.
It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence).
That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are.
PS: I'm a bit too sleepy to search for the original discussion. Apologies for not linking it here.
> The only thing I'm not sure about is why they decided to reopen it.
It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.
That would make sense, since they would then need support for JXL for the embedded PDF viewer anyway. Unless they want it to choke on valid PDFs that include JXL images.
I see! Thanks for pointing out this very interesting correlation. So we got something better only because someone else equally influential forced their hand. Otherwise the users be damned, for all they care, it seems.
I have been relentlessly shilling JPEG-XL's technological superiority especially against their joke of an alternative and a stain on the Internet they call WebP
"Code frequency" for jxl-rs shows no activity from Aug 2021 to Aug 2024, then steady work with a couple of spurts. That's both a longer hiatus and a longer period of subsequent activity (a year+ ago isn't "recently" in my book.) What data have you based your observation on?
Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!
This actually seems to use the encoder/decoder from the Rust image crate (1), which would bring the opportunity for more memory safe formats once BMP would be accepted.
> Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.
Well, the first public implementation dates to 2020. And, the Cpp choice is obvious, simpler integration with the majority of existing image processing libs, tools and utilities. Not to mention GUI toolkits.
Nonetheless, we should really bear in mind how entrenched Cpp is. If you normalize CVEs by language popularity Java looks downright dangerous!
No new code goes in that violates the rule, and ideally no code at all goes in that is both unsafe and parses untrusted data (regardless of sandboxing) and old code doing both gets replaced.
A giant pile of C++ can be used for rendering, not parsing untrusted data. A giant pile of C++ can sit behind a validator: a memory-safe JSON validator can vet a stream, before an C++ library deserializes it. Etc.
Mozilla's position for some time now has been, "we aren't opposed to shipping JXL support, but we'd want to ship a decent implementation in a memory safe language, not the reference C++ implementation". That position hasn't been met with very much criticism.
Google's position, on the other hand, has been a flat-out "no, we will not ship JXL". That's what has been met with criticism. Not an imagined reluctance to shipping a C++ JXL implementation.
It's Google, it's one of the biggest tech companies in the world making boatloads of money, in part off their browser. They're currently best known as one of the companies trying to create AI God. They really can't write an... image format parser?
At 600DPI that's over a marathon in each dimension.
I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.
I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash:
Number of A4 pages=0.0625 square meters per A4 page * 784 square miles =13,200 A4 pages.
No Gemini, you can't equate meters and miles, even if they do both abbreviate to 'm' sometimes.
> I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.
You can already DOS with SVG images. Usually, the browser tab crashes before worse things happen. Most sites therefore do not allow SVG uploads, except GitHub for some reason.
svg is also just kind of annoying to deal with, because the image may or may not even have a size, and if it does, it can be specified in a bunch of different units, so it's a lot harder to get this if you want to store the size of the image or use it anywhere in your code
Which JXL supports, by the way. Tiling is mandatory for images bigger than 2048x2048, and you can construct images based on an 8x downscaled version, recursing that up to 4 times for up to 4096x downscaling.
That is awesome. In my domain, images (TIFFs usually) are up to 1m x 1m pixels and scaling usually goes 4x so that if you need 2x scaling you can just read 4 times as many tiles from the higher resolution level and downscale. With 8x scaling you need to go a level further - reading 16 pixels from the image to create 1 pixel of output. Not great but it would work and 4096 scaling would make the lowest resolution image 256 x 256 which is just what you need.
Probably, multiple resolutions of the same thing. E.g. a lower res image of the entire scene and then higher resolution versions of sections. As you zoom in, the higher resolution versions get used so that you can see more detail while limiting memory consumption.
JPEG and friends transforms the image data into the frequency domain. Regular old JPEG uses the discrete cosine transformation[1] for this on 8x8 blocks of pixels. This is why with heavily compressed JPEG images you can see blocky artifacts[2]. JPEG XL uses variable block size DCT.
Lets stick to old JPEG as it's easier to explain. The DCT takes the 8x8 pixels of a block and transforms it to 8x8 magnitudes of different frequency components. In one corner you have the DC component, ie zero frequency, which represents the average of all 8x8 pixels. Around it you have the lowest non-zero frequency components. You have three of those, one which has a non-zero x frequency, one with a non-zero y frequency, and one where both x and y are non-zero. The elements next to those are the next-higher frequency components.
To reconstruct the 8x8 pixels, you run the inverse discrete cosine transformation, which is lossless (to within rounding errors).
However, due to Nyquist[3], you don't need those higher-frequency components if you want a lower-resolution image. So if you instead strip away the highest-frequency components so you're left with a 7x7 block, you can run the inverse transform on that to get a 7x7 block of pixels which perfectly represents a 7/8 = 87.5% sized version of the original 8x8 block. And you can do this for each block in the image to get a 87.5% sized image.
Now, the pyramidal scheme takes advantage of this by rearranging how the elements in each transformed block is stored. First it stores the DC components of all the blocks the image. If you just used those, you'd get an image which perfectly represents a 1/8th-sized image.
Next it stores all the lowest-frequency components for all the blocks. Using the DC and those you have effectively 2x2 blocks, and can perfectly reconstruct a quarter-sized image.
Now, if the decoder knows the target size the image will be displayed at, it can then just stop reading when it has sufficiently large blocks to reconstruct the image near the target size.
Note that most good old JPEG decoders supports this already, however since the blocks are stored one after another it still requires reading the entire file from disk. If you have a fast disk and not too large images it can often be a win regardless. But if you have huge images which are often not used in their full resolution, then the pyramidal scheme is better.
Replicated at different resolutions depending on your zoom level.
One patch at low resolution is backed by four higher-resolution images, each of which is backed by four higher-resolution images, and so on... All on top of an index to fetch the right images for your zoom level and camera position.
Each pixel would represent roughly 16cm^2 using a cylindrical equal-area projection. They would only be square at the equator though (representing less distance E-W and more distance N-S as you move away from the equator).
No projection of a sphere on a rectangle can preserve both direction and area.
Yes, but unlike AVIF, JPEG XL supports progressive decoding, so you can see the picture in lower quality long before the download has finished. (Ordinary JPEG also supports progressive decoding, but in a much less efficient manner, which means you have to wait longer for previews with lower quality.)
I don’t think the issue with the exabyte image is progressive decoding, though it would at least get you an image of what is bringing down your machine while you wait for the inevitable!
Quick reminder that it's not "Google" that killed JXL before, it was the Chrome team. Jpeg XL was designed by a Google engineer (JyrkiAlakuijala here) who is not part of the Chrome team, but in Google Research in the Zurich office while the Chrome team, although it has offices all around the world, at its core is very insular and lives in the Mountain View bubble.
Jyrki is highly talented. Also the author of the incredible Jpegli, which seemed to be a reaction to Google deep-sixing JpegXL, and also Brotli, WebP lossless and WOFF2 among other things.
I am using .avif since some years; all my old .jpg
and .png files have been pretty much replaced by
.avif, in particular fotos. I am not saying .avif is
perfect, but IMO it is much better than .jpg or
.avif.
I could have gone .webp or perhaps jpeg-xl but at the
end of the day, I am quite happy with .avif as it is.
As for JPEG XL - I think the problem here is ... Google.
Google dictates de-facto web-standards onto us. This is
really bad. I don't want a commercial entity control my
digital life.
For making compact high-quality jpeg files, consider trying jpegli[1], it does an impressive job.
More specifically, if I try a bunch of AVIF quantization options and manually pick the one that appears visually lossless, it beats jpegli, but if I select a quantization option that always looks visually lossless with AVIF, jpegli will win the average size, because I need to use some headroom for images that AVIF does less well on.
Another one I've noticed is using "I've" as a contraction in e.g. "I've a meeting to attend". Seems totally reasonable but for some reason native speakers just don't use it that way.
Wait, what? Englishman in my 50s here and I use phrases like that all the time — “I’ll be missing standup cos I’ve a GP appointment”, “leaving at lunchtime as I’ve a train to catch”, “gotta dash, I’ve chores to do”. No one’s ever said I sound German!
Could also be French speakers. They would say "J'utilise le format .avif depuis quelques années." I think the "depuis" throws off the French speakers when they translate that literally as "since some years" instead of "for some years".
Another common tell: I wake up in the morning in the US/Pacific time zone, and see the European writers on HN using "I have ran" instead of "I have run".
Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface?
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.
According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header".
So at least if GP was talking about libjxl "100K+" would be more accurate.
One of the best ways to measure code complexity is to zip up the source code. This eliminates a lot of the redundancies and is a more direct measure of entropy/complexity than almost anything else.
By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.
It comes from the "intelligence is a form of compression" hypothesis that has been floating around in the ML space. Also, with a good compression algorithm it is a fairly direct measure of entropy, which is quite well correlated with what a developer might consider code size and/or complexity.
> A. You’ve identified two commonly used conventions in finance, one derived from Greek and the other from Latin, but neither one is standard.
Starting with the second convention, M is used for amounts in the thousands and MM for amounts in the millions (usually without a space between the number and the abbreviation—e.g., $150M for $150,000 and $150MM for $150 million). This convention overlaps with the conventions for writing roman numerals, according to which a thousand is represented by M (from mille, the Latin word for “thousand”). Any similarity with roman numerals ends there, however, because MM in roman numerals means two thousand, not a thousand thousands, or one million, as in financial contexts...
I assume this is regional... I work in accounting and finance in New Zealand (generally following ordinary Western/Commonwealth standards) and I've never heard of using M for thousands. If I used that I would confuse the hell out of everyone around me.
The article says 100K, not 100M. I'm guessing that's what the parent comment meant.
100MLOC for an image format would be bananas. You could fit the entire codebases of a couple of modern operating systems, a handful of AAA videogames, and still have room for several web apps and command line utilities in 100MLOC.
It's a container format that does about a bajillion things - lossy, lossless, multiple modes optimized for different image types (photography vs digital design), modern encode/decode algorithms, perceptual color space, adaptive quantization, efficient ultra-high-resolution decoding and display, partial and complete animation, tile handling, everything JPEG does, and a bunch more.
The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.
It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.
-> They were concerned about the increased attack surface resulting from including the current 100K+ lines C++ libjxl reference decoder, even though most of those lines are testing code.
Seems like Google has created a memory-safe decoder for it in Rust or something.
It is a very big one and eliminating it is a huge improvement in security. You can then spend more time fixing all the other sources of security problems.
99% safe with 1% unsafe mixed in is far, far better than 100k loc of c++ -- look at Google's experience with rust in Android. It's not perfect and they had one "almost vulnerability" but the rate of vulnerabilities is much, much lower even with a bit of unsafe mixed in.
Agreed, and Google developers can probably be trusted to 'act responsibly', but too often people forget the distinction. Some Rust codebases are wildly unsafe, and too often people see written in Rust and falsely conclude it's a memory-safe codebase.
Then again PDF also technically supports embedded audio, video, 3D graphics, and arbitrary Javascript. If Flash hadn't died it would probably still support that too. It's a clown car format where everyone besides Adobe just tacitly agrees to ignore huge chunks of the spec.
The biggest "win" for JPEG XL so far was last year's adoption by Apple for ProRAW, and prosumer photography is will likely be JPEG XL's primary mainstream use case. Pros will continue to shoot in "actual RAW", and consumers will (and this is not an insult) continue to have no interest in the technical details of the compressed media formats being used.
It'll be in PDF sooner, and my experience is that PDF >> any other system for ebooks. I liked the idea of EPUB but when I recently installed an EPUB reader to read some files I was shocked at how awful it looked whereas for 15 years I've been reading PDF files on tablets with relish.
Have you ever tried reading a PDF ebook on a phone? Small font size, doesn't fill the entire screen (phones are taller), margins make it appear even smaller... even if you have good eyesight it's a pain. The whole point of PDF is to preserve a page layout as authored. EPUB is meant to adapt to your device.
I am mostly reading on a tablet, not a phone. I think if you are reading on a phone you are already screwed —- if people are “reading” on phones I think 80% of it is that you just read less.
That’s a pretty judgemental statement out of nowhere - and completely ignored the ebook readers part, which are devices literally created for this purpose.
As for phones, screens nowadays are almost the same size as readers and with more resolution. E-ink is more comfortable for longer sessions, but if you find such a size unusable you might just have poor eyesight.
As someone who is super nearsighted, the smaller screen on a phone is great for reading, especially in contexts like bedtime reading where I want to have my glasses off.
I have read many hundreds of books this way.
The problem with a tablet is that most tablets, especially the sort that are good for seeing entire as-printed pages at once, are too big for me to keep the entire screen in focus without wearing glasses. (with that said, foldables improve things here, since the aspect ratio bottleneck is typically width so being able to double the width on the fly makes such things more readable.
The worst epubs are bad because some jackass took some poorly OCRed text and dumped it into the format. The best (retail) epubs are on par with the best PDFs except you don't have to pan-and-scan to read a fucking page. It just reflows.
For novels I want and prefer epubs, but also non-novels if they were released in the last 5 years or so. PDF isn't magic, and there are bad pdfs out there too, scans of photo-copied books and other nonsense.
There is a mode for PDF files that reflows and is logically similar to EPUB in that there is an HTML-derived data model and you have images embedded in the PDF much as they are embedded in the EPUB. Of course if you hate how complex PDF is it is more to hate.
That's interesting, I absolutely hate PDF. Lack of metadata for collecting, format is difficult to support, doesn't layout well on mobile, and very limited customization (like dark mode, changing text size, etc).
Only benefit is browsers have built-in support for the format.
One thing I like about PDF is the annotations (notes & highlights) are embedded in the PDF itself. That is not the case for EPUB files, each EPUB reader stores annotations in its own proprietary format.
PDFs have pretty excellent support for metadata. If the collection software doesn't support at least Dublin Core, that may be kind of their own fault...
Good, but mass adoption is a lot slower in sites than in browsers it seems. It's like pulling teeth making sites to actually support even AVIF which is already widely supported in browsers. A ton of inertia even on sites like GitHub and GitLab. Try using AVIF on Wikipedia? Tough luck.
Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet.
Side note - comparing JPEG XL and AVIF features wise is sort of pointless if AVIF will continue to evolve based on AV2 and etc.
There’s also the issue of non-browser support. I recently advocated for replacing some GIFs with WEBM because WEBM was faster to encode and took up 3% as much space. Technically it sounded great. Then we talked to users.
It turns out some users wanted to embed moving pictures in Word documents, which you can only do with a GIF because it’s an image format that happens to move, so Word treats it as an image (by rendering it to the page). If it’s a video format, Word treats it as an attachment that you have to click on so it’ll open Media Player and show you.
There's no particular reason for an image format based on video codec keyframes to ever support a lot of the advanced features that JPEG XL supports. It might compress better than AVIF 1, but I doubt it would resolve the other issues.
As a monopoly, Google should be barred from having standards positions and be legally required to build and support the web standards as determined by other parties.
The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
I kind of liked xhtml, though clearly it was not necessary for the web to be successful. I think the bigger issue is that W3C pursued this to the detriment of more important investments.
Reading over the minutes for the last W3C WG session before WHATWG was announced, the end result seems obvious. The eventual WHATWG folks were pushing for investment in web-as-an-app-platform and everyone else was focused on in retrospect very unimportant stuff.
“Hey, we need to be able to build applications.”
“Ok, but first we need compound documents.”
There was one group who thought they needed to build the web as Microsoft Word and another that wanted to create the platform on which Microsoft Word could be built.
> and another that wanted to create the platform on which Microsoft Word could be built.
Apparently they failed. The web version of Word is still far from having feature parity. Of course doc is one of those everything and the kitchen sink formats, so implementing it on top of a platform that was originally intended to share static documents is kind of a tall order.
The other key browser implementers are also part of WHATWG.
Who do you suppose should be in charge of web standards? I can’t imagine the train wreck of incompetence if standards were driven by bureaucrats instead of stakeholders.
Saying web users should define web standards is like saying laptop users should design CPUs. They lack the expertise to do this meaningfully.
Web authors? Maybe. WHATWG was created specifically because W3C wasn’t really listening to web authors though.
I don’t think there are a lot of scenarios where standards aren’t driven by implementers, though. USB, DRAM, WiFi, all this stuff is defined by implementers.
> WHATWG was created specifically because W3C wasn’t really listening to web authors though.
Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.
They only paid the salary of its chief editor (Ian Hickson) for a significant amount of time...
But that's not very relevant actually. The WHATWG is more like a private arbitrator, not like a court or parliament.
Their mission is to document browser features and coordinate them in such a way that implementation between browsers doesn't diverge too much. It's NOT their mission to decide which features will or will not be implemented or even to design new features. That's left to the browser vendors.
This is such a bizarre response to me saying Google was not part of the founding WHATWG group. It’s like you want to have an argument but don’t have anything to argue about.
“Oh, yeah? Well they paid Hickson’s salary. And the WHATWG doesn’t matter anyway. And also Google is really powerful.”
Um, ok.
WHATWG was founded in 2004 by Mozilla, Opera, and Apple. Google had no browser at that point and didn’t hire Ian Hickson until 2005.
Google is currently a WHATWG member and clearly wields a great deal of influence there. And yeah, the 4 trillion dollar internet giant is powerful. No argument there.
> Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.
Mozilla, Opera and Apple. Google didn't have a browser then, hadn't even made the main hires who would start developing Chrome yet and hixie was still at Opera.
Ask users what they want and they say "faster horses," not cars.
Users are a key information source but they don't know how to build a web engine, they don't know networks, and they don't know security; and therefore can't dictate the feature set.
And those implementers should make decisions, Google should be bound by the FTC to supporting their recommendations.
Honestly, what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform. I really think anyone who has any sort of confusion about what I commented here to take a long, hard look at their worldview.
> And those implementers should make decisions, Google should be bound by the FTC to supporting their recommendations.
Is your proposal essentially that Mozilla defines web standards Google is legally bound to implement them?
> what's really funny here is how absolutely horrified people are by the suggestion
Not horrified, but asking what the alternative is. I don’t think you’ve actually got a sensible proposal.
Cooperation in the WHATWG is voluntary. Even if there were some workable proposal for how to drive web standards without Google having any decision making power, they could (and presumably would) decline to participate in any structure that mandated what they have to build in Chrome. Absent legal force, no one can make Google cede their investment in web standards.
We have the legal force to do this. Google has already been determined to be abusing their illegal monopoly they have with Chrome. The penalty phase is ongoing, but consider that even forcing Google to sell Chrome was originally considered as a possible penalty.
Requiring Google implement the standards as agreed by Apple, Mozilla, and Microsoft is not remotely outside the realm of the legal force that could be applied.
There’s something not quite right about saying one member of an oligopoly should be forced to follow the dictates of the other members of an oligopoly. I don’t feel like this actually solves anything.
I feel like Mozilla would end up being a Google proxy in this case as they fear losing their funding and Apple and Microsoft would be incentivized to abuse their position to force Google not to do the best thing for the public but the best thing for Apple and Microsoft.
Yeah, that feels like State-sponsored formalizing of oligopolies into a cartels. We'd like it if they went in the complete opposite direction of less power, not more.
I agree there's already a significant proxy risk with Mozilla (though Mozilla does consider many Google web proposals harmful today), but that is also no less true today, and in fact, today that means Google holds two votes not one.
I would again agree Microsoft and Apple will heavily endorse their own interests, Microsoft much more so in terms of enterprise requirements and Apple much more so in terms of privacy-concerned consumers. The advertising firm influence will be significantly dimished and that is a darn shame.
>what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform
They don't. In general browser specs are defined via various standards groups like WHATWG. As far as I know there is no standard for what image formats must be supported on a web browser,[0] which is why in this one case any browser can decide to support an image format or not.
Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's. They don't want to create a maintenance burden for features that offer little benefit over existing options.
Didn't Mozilla basically say they would support it if Google does? Mozilla doesn't have the resources to maintain a feature that no one can actually use; they're barely managing to keep up with the latest standards as it is.
> maintain a feature that no one can actually use;
If only there was a way to detect which features a browser supports. Something maybe in the html, the css, javascript or the user agent. If only there was a way to do that, we would not be stuck in a world pretending that everything runs on IE6. /s
I made no such implication. Mozilla is certainly an other party, and their positions on standards hold water. They successfully argued for Web Assembly over Native Client, and have blocked other proposals such as HTML Import in the Web Components API. They are still a key member of the WHATWG.
The fact that Mozilla aligns with Google on both of these deprecations suggests the reasons are valid.
I personally see no reason for XSLT today. Outside of the novelty of theming RSS feeds, it sees very little use. And JPEG XL carries a large security surface area which neither company was comfortable including in its current shape. That may change based on adoption and availability of memory-safe decoders.
Which is why Firefox is steadily losing market share.
If Mozilla wanted Firefox to succeed, they would stop playing "copy Chrome" and support all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.
With all due respect, this is a completely HN-brained take.
No significant number of users chooses their browser based on support for image codecs. Especially not when no relevant website will ever use them until Safari and Chrome support them.
And websites which already do not bother supporting Firefox very much will bother even less if said browser by-default refuses to allow them to make revenue. They may in fact go even further and put more effort into trying to block said users unless they use a different browser.
Despite whatever HN thinks, Firefox lost marketshare on the basis of:
A) heavy marketing campaigns by Google including backdoor auto-installations via. crapware installers like free antivirus, Java and Adobe, and targeted popups on the largest websites on the planet (which are primarily google properties). The Chrome marketing budget alone nearly surpasses Mozilla's entire budget and that's not even accounting for the value of the aforementioned self-advertising.
B) being a slower, heavier browser at the time, largely because the extension model that HN loved so much and fought the removal of was an architectural anchor, and beyond that, XUL/XPCOM extensions were frequently the cause of the most egregious examples of bad performance, bloat and brokenness in the first place.
C) being "what their cellphone uses" and Google being otherwise synonymous with the internet, like IE was in the late 1990s and early 2000s. Their competitors (Apple, Microsoft, Google) all own their own OS platforms and can squeeze alternative browsers out by merely being good enough or integrated enough not to switch for the average person.
I don't disagree with you, but given (A) how will Firefox ever compete?
One possible way is doing things that Google and Chrome don't (can't).
Catering to niche audiences (and winning those niches) gives people a reason to use it. Maybe one of the niches takes off. Catering to advanced users not necessarily a bad way to compete.
Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).
>Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).
Good thing they aren't? Firefox's detached video player feature is far superior to anything Chrome has that I'm aware of. Likewise for container tabs, Manifest V2 and anti-fingerprinting mode. And there are AI integrations that do make sense, like local-only AI translation & summaries, which could be a "niche feature" that people care about. But people complain about that stuff too.
And these aren't niche/advanced features? I'm using Firefox now, and did not know about them. If I'm using them, it is only accidentally or because they are the defaults.
But I'm agreeing with you! These features are important to you, an advanced user. The more advanced users for Firefox, the better.
For Firefox to win back significant share, they need to do more than embrace fringe scenarios that normal people don’t care about. They need some compelling reason to switch.
IE lost the lead to Firefox when IE basically just stopped development and stagnated. Firefox lost to Chrome when Firefox became too bloated and slow. Firefox simply will not win back that market until either Chrome screws up majorly or Firefox delivers some significant value that Google cannot immediately copy.
Nah, google paved the way forward with vital developments like WebGPU und import maps. I stopped using and supporting Firefox because they refused to improve the internet.
I'm using mine to develop 3D apps, which became way to cumbersome and eventually impossible since Firefox dragged its feet on inplementing important stuff.
Barred by who? There is no governing body who can do such a thing, currently. As it is, nothing stops any random person or organization from creating any new format.
This is a vacuous statement. No one is stopping me from using JPEG XL in the same sense that no one is stopping me from using DIMG10K, a format I just invented. But if I attempt to use either of these in my website today, Chrome will not render them.
In a very real sense Google is currently stopping web authors from using JPEG XL.
It's a meta-commentary about the death of critical thinking and the ease with which mindless mobs can be whipped.
From the jump, the article commits a logical error, suggesting that Google killed jpegxl because it favors avif, which is "homegrown". jpegxl, of course, was also written by Google, so this sentence isn't even internally consistent.
VP8 is in all major browsers due to WebRTC, and webp uses little more code than the VP8 keyframe decoder, so it also has baseline support and is unlikely to be deprecated any time soon. https://caniuse.com/?search=vp8
Similarly, AVIF uses little more code than the AV1 keyframe decoder, so since every browser supports AV1, every browser also supports AVIF.
I don't know much about webp other than you get about 50% savings in compression vs png/jpeg, but it does have some hard limits on sizes of images. It doesn't do well with webtoon reading formats (long strip format).
Otherwise, I love webp and use it for all my comics/manga.
Even nowadays, webp seems to be good specifically for its lossless mode. It seems to create files that are substantially more efficient even when compared with advanced png encoders. For comics, png should probably be used over jpeg, so webp is likely indeed an upgrade, aside from compatibility.
For photographs, jpeg has really been optimized without reducing compatibility, and also in another less compatible way (incompatible viewers can display it without erroring out, but the colors are wrong) and there's such an encoder in the JPEG XL repo.
It was mostly about compatibility but looks like photoshop supports it now so I guess I can now officially say I don't really care one way or the other.
One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched.
Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.
Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.
Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.
Compared to an average jpeg encoder, or something like mozjpeg?
Didn't have time to test GCP DICOM store back in the day (not that I'm going to use it, as I've always been working in-house...), but, how is it? Is it a full fledged PACS? a WADO implementation? just a custom API?
If it's reversible, why not just store as JPEG XL and then convert back when it's served? Does it take a lot of processing time?
You can do that and that's one of the big appeals. You can serve bost JXL and JPEG from the same source and you8 can actually serve downscaled versions of the JXL image from the original bytestream.
Also OP did say "transcode on the fly" to serve JPEG, not actually storing as JPEG.
Isn’t that what the comment you’re replying to is suggesting?
What's the point of transcoding? You still have to store the original DICOM right? That's probably the bulk of the cost
This is for when you receive JPEG encoded DICOMs. You transcode them to JPEG XL (saving that 20% of storage) and then, if a modality/viewer/whatever that needs JPEG requests them, they're transcoded on the flight to JPEG losslessly.
Losslessly meaning, with the same quality than the original JPEG received by the storage.
JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere.
That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.
To address selected claims made in the post:
• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).
• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.
• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).
So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.
Yes AVIF is better at compressing than jpeg and even webp, that should be taken for granted given its a newer format. But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use. Real world usage paints a very different picture.
JXL not only has better compression rates at equivalent qualities for sane settings, it does so with faster encoding and decoding, while also supporting progressive decoding leveraging image saliency.
AV2 might bring it closer on par with JXL in compression but to suggest they're at all equal is a joke.
> But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use.
At 1080p, a 100k AVIF image is good enough to serve on a webpage. The same image as a 100k JXL will (probably) look unacceptible.
Source: every year or so, I play around with encoding my blog's images with AVIF and JXL. Smaller AVIF images look ok, but the equivalently sized JXL images look way worse. (And before you accuse me of re-encoding lossy to lossy images, most images I test with are game screenshots stored as PNGs.)
> is enshrined as an Apple image default
What? iPhones and other Apple devices take HEIF photos, where does Apple claim AVIF as its image default?
I seem to recall that a large part of the stated rationale at the time the Chrome Team decided to deprecate support for JXL was that they had support for both AVIF and JXL, and AVIF was good enough.
This might be the origin of the "competition" in the context of this Google decision/reversal.
> JXL's theoretical maximum image size is bigger.
This is all fine and good until you actually try encoding such an image with libjxl. What an absolute garbage codebase. I'm sure it's gotten better since I've last used it, but it's impressive how unoptimized, memory hungry, and of course wildly unsafe/crashy it was. Many of the options just completely didn't work, either due to exponential performance, crashes, or weird special-casing that breaks the moment you encode anything that's dissimilar from the sample images used in the sham benchmark made by the libjxl creators. I don't even think a high resolution image had ever been successfully encoded on higher effort levels, since I doubt that anyone trying to do so had the terabytes of RAM required.
I was genuinely flabbergasted when there was mass support for reviving it a couple years ago. I don't think anyone advocating for it has actually used libjxl at all and were just internet hypemen. That seems to happen all too often nowadays.
This all being said, I'm mildly optimistic for a retry with jxl-rs. However, seeing much of the same contributors from libjxl on jxl-rs does make me quite cautious.
I have no idea what you are talking about. I archive petabytes of space imagery with libjxl on maximum compression, effortlessly.
It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence).
[0] https://issues.chromium.org/issues/40168998#comment507
That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are.
PS: I'm a bit too sleepy to search for the original discussion. Apologies for not linking it here.
> The only thing I'm not sure about is why they decided to reopen it.
It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.
That would make sense, since they would then need support for JXL for the embedded PDF viewer anyway. Unless they want it to choke on valid PDFs that include JXL images.
I see! Thanks for pointing out this very interesting correlation. So we got something better only because someone else equally influential forced their hand. Otherwise the users be damned, for all they care, it seems.
I have been relentlessly shilling JPEG-XL's technological superiority especially against their joke of an alternative and a stain on the Internet they call WebP
https://www.reddit.com/r/DataHoarder/comments/1b30f8h/image_...
https://youtu.be/w7UDJUCMTng
It wasn't just a blatant lie for lack of interest, they also went out their way to benchmark it and somehow present it as inferior to AVIF.
IIRC they benchmarked it as "not much better" than AVIF, not inferior.
That library had a hiatus with zero commits of over 1.5 years until recently iirc.
That this is working out is a combination of wishful thinking and getting lucky.
"Code frequency" for jxl-rs shows no activity from Aug 2021 to Aug 2024, then steady work with a couple of spurts. That's both a longer hiatus and a longer period of subsequent activity (a year+ ago isn't "recently" in my book.) What data have you based your observation on?
my fallible memory of roughly the same sources
Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
That's why both Mozilla and Google have predicated their JXL support on a memory-safe implementation. There's a Rust one in the works.
I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.
If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!
BMP decoding may seem easy and fun (I wrote a toy decoder back in the day), but the vulnerabilities are real: https://nvd.nist.gov/vuln/detail/CVE-2025-32468
It's not the format, it's the C / C++ unfortunate baggage.
Happy to report the BMP work is actually being done by our friends on the Edge team at Microsoft! https://chromium-review.googlesource.com/c/chromium/src/+/72...
This actually seems to use the encoder/decoder from the Rust image crate (1), which would bring the opportunity for more memory safe formats once BMP would be accepted.
(1) https://crates.io/crates/image
> Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.
Well, the first public implementation dates to 2020. And, the Cpp choice is obvious, simpler integration with the majority of existing image processing libs, tools and utilities. Not to mention GUI toolkits.
Nonetheless, we should really bear in mind how entrenched Cpp is. If you normalize CVEs by language popularity Java looks downright dangerous!
> any substantial (non-degenerative)
Why this quality poses security issues?
And yet whole of HN is VERY VERY angry because Google won't ship that pile of C++ into most popular software (and app framework) in the world.
The most popular software in question is also a giant pile of C++, btw.
Are you familiar with the rule of two?
https://chromium.googlesource.com/chromium/src/+/main/docs/s...
No new code goes in that violates the rule, and ideally no code at all goes in that is both unsafe and parses untrusted data (regardless of sandboxing) and old code doing both gets replaced.
A giant pile of C++ can be used for rendering, not parsing untrusted data. A giant pile of C++ can sit behind a validator: a memory-safe JSON validator can vet a stream, before an C++ library deserializes it. Etc.
What are you saying here?
https://chromium.googlesource.com/chromium/src/+/refs/heads/...
Communicate. What are you trying to say with these links and insinuations?
Mozilla's position for some time now has been, "we aren't opposed to shipping JXL support, but we'd want to ship a decent implementation in a memory safe language, not the reference C++ implementation". That position hasn't been met with very much criticism.
Google's position, on the other hand, has been a flat-out "no, we will not ship JXL". That's what has been met with criticism. Not an imagined reluctance to shipping a C++ JXL implementation.
Who is saying Google should ship the reference implementation? It's a standard, and Google has the labor to write their own implementation.
Google did write one. They wrote the bad one that we're discussing.
they wrote both AFAIK
That sounds like an even more request for someone to do for free, doesn't it?
It's Google, it's one of the biggest tech companies in the world making boatloads of money, in part off their browser. They're currently best known as one of the companies trying to create AI God. They really can't write an... image format parser?
Cool, but why does that mean they need to write a codec for you for free?
They don't need to, they're free to become IE6.
I don't think it's irrational to be upset when a (near-)monopoly browser holds back useful features. Even if said browser is provided for free.
They are IE6. They have near total market dominance, and dictate web standards. It's a very comparable situation to IE6 days.
A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824):
Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes
Thats a serious high-res image
At 600DPI that's over a marathon in each dimension.
I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.
I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash:
No Gemini, you can't equate meters and miles, even if they do both abbreviate to 'm' sometimes.> I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.
You can already DOS with SVG images. Usually, the browser tab crashes before worse things happen. Most sites therefore do not allow SVG uploads, except GitHub for some reason.
svg is also just kind of annoying to deal with, because the image may or may not even have a size, and if it does, it can be specified in a bunch of different units, so it's a lot harder to get this if you want to store the size of the image or use it anywhere in your code
"Google's magic calculator" was probably just a wrapper to GNU Units [0], which produces:
Equivalent tools: Qalc, Numbat0: https://news.ycombinator.com/item?id=36994418
It couldn't have been a wrapper - it understood a tiny tiny fraction of the things that Gnu units does.
Wolfram alpha is the better calculator for that sort of thing.
A better Gemini also works. Google Search seems to use the most minimal of Geminis, giving it a bad rep.
Prompt: “How many A4 pages would a 1073741823×1073741824 image printed at 600dpi be?”
Gemini Pro: “It would require approximately 33.1 billion (33,127,520,230) A4 pages to print that image.
To put that into perspective, the image would cover an area of 2,066 square kilometers […].
The Math
1. Image Dimensions: 1,073,741,823 × 1,073,741,824 pixels.
2. Physical Size: At 600 DPI, the image measures roughly 45.45 km wide by 45.45 km tall.
3. A4 Area: A single sheet of A4 paper (210 mm * 297 mm) covers approximately 0.06237 m².
4. Result: 2,066,163,436 m² / 0.06237 m² ≈ 33,127,520,230 pages.”
Alternatively, rink (https://rinkcalc.app/) :
> (1073741823 / (600/inch))**2 / A4paper
approx. 3.312752e10 (dimensionless)
The only practical way to work with such large images is if they are tiled and pyramidal anyway
Which JXL supports, by the way. Tiling is mandatory for images bigger than 2048x2048, and you can construct images based on an 8x downscaled version, recursing that up to 4 times for up to 4096x downscaling.
That is awesome. In my domain, images (TIFFs usually) are up to 1m x 1m pixels and scaling usually goes 4x so that if you need 2x scaling you can just read 4 times as many tiles from the higher resolution level and downscale. With 8x scaling you need to go a level further - reading 16 pixels from the image to create 1 pixel of output. Not great but it would work and 4096 scaling would make the lowest resolution image 256 x 256 which is just what you need.
what does pyramidal mean in this context?
Probably, multiple resolutions of the same thing. E.g. a lower res image of the entire scene and then higher resolution versions of sections. As you zoom in, the higher resolution versions get used so that you can see more detail while limiting memory consumption.
JPEG and friends transforms the image data into the frequency domain. Regular old JPEG uses the discrete cosine transformation[1] for this on 8x8 blocks of pixels. This is why with heavily compressed JPEG images you can see blocky artifacts[2]. JPEG XL uses variable block size DCT.
Lets stick to old JPEG as it's easier to explain. The DCT takes the 8x8 pixels of a block and transforms it to 8x8 magnitudes of different frequency components. In one corner you have the DC component, ie zero frequency, which represents the average of all 8x8 pixels. Around it you have the lowest non-zero frequency components. You have three of those, one which has a non-zero x frequency, one with a non-zero y frequency, and one where both x and y are non-zero. The elements next to those are the next-higher frequency components.
To reconstruct the 8x8 pixels, you run the inverse discrete cosine transformation, which is lossless (to within rounding errors).
However, due to Nyquist[3], you don't need those higher-frequency components if you want a lower-resolution image. So if you instead strip away the highest-frequency components so you're left with a 7x7 block, you can run the inverse transform on that to get a 7x7 block of pixels which perfectly represents a 7/8 = 87.5% sized version of the original 8x8 block. And you can do this for each block in the image to get a 87.5% sized image.
Now, the pyramidal scheme takes advantage of this by rearranging how the elements in each transformed block is stored. First it stores the DC components of all the blocks the image. If you just used those, you'd get an image which perfectly represents a 1/8th-sized image.
Next it stores all the lowest-frequency components for all the blocks. Using the DC and those you have effectively 2x2 blocks, and can perfectly reconstruct a quarter-sized image.
Now, if the decoder knows the target size the image will be displayed at, it can then just stop reading when it has sufficiently large blocks to reconstruct the image near the target size.
Note that most good old JPEG decoders supports this already, however since the blocks are stored one after another it still requires reading the entire file from disk. If you have a fast disk and not too large images it can often be a win regardless. But if you have huge images which are often not used in their full resolution, then the pyramidal scheme is better.
[1]: https://en.wikipedia.org/wiki/Discrete_cosine_transform
[2]: https://eyy.co/tools/artifact-generator/ (artifact intensity 80 or above)
[3]: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...
I think it means encoded in such a way that you first have low res version, then higher res versions, then even higher res versions etc.
Replicated at different resolutions depending on your zoom level.
One patch at low resolution is backed by four higher-resolution images, each of which is backed by four higher-resolution images, and so on... All on top of an index to fetch the right images for your zoom level and camera position.
Except in the case of a format like JPEG, there is no duplication - higher layers are used to "fill in the gaps" in the data from lower layers.
Tiled at different zoom levels
We call those mipmaps.
An image of earth at very roughly 4cmx4cm resolution? (If I've knocked the zero's off correctly)
Each pixel would represent roughly 16cm^2 using a cylindrical equal-area projection. They would only be square at the equator though (representing less distance E-W and more distance N-S as you move away from the equator).
No projection of a sphere on a rectangle can preserve both direction and area.
I admit it, I was applying Cunningham’s Law. Disappointingly(?), you came to the same answer.
A selfie at that resolution would be some sort of super-resolution microscopy.
Yes, but unlike AVIF, JPEG XL supports progressive decoding, so you can see the picture in lower quality long before the download has finished. (Ordinary JPEG also supports progressive decoding, but in a much less efficient manner, which means you have to wait longer for previews with lower quality.)
I don’t think the issue with the exabyte image is progressive decoding, though it would at least get you an image of what is bringing down your machine while you wait for the inevitable!
[flagged]
They still down voted anyway lol
At least I didn't give Dang extra work.
Lol yeah Dang has a lot of flame wars to deal with
Prior HN posts/discussions:
Chromium Team Re-Opens JPEG XL Feature Ticket https://news.ycombinator.com/item?id=46018994
FSF Slams Google over Dropping JPEG-XL in Chrome https://news.ycombinator.com/item?id=35589179
Google set to deprecate JPEG XL support in Chrome 110 https://news.ycombinator.com/item?id=33399940
Chromium jpegxl issue closed as won't fix https://news.ycombinator.com/item?id=40407475
Lots more at https://news.ycombinator.com/item?id=36214955 and the links back from there, and I'm sure there are others between then and now. Too many to list!
[dupe]
Main recent discussion:
Google Revisits JPEG XL in Chromium After Earlier Removal
https://news.ycombinator.com/item?id=46021179
not to mention this other dupe with lots of discussion also from last week: https://news.ycombinator.com/item?id=46033330
Quick reminder that it's not "Google" that killed JXL before, it was the Chrome team. Jpeg XL was designed by a Google engineer (JyrkiAlakuijala here) who is not part of the Chrome team, but in Google Research in the Zurich office while the Chrome team, although it has offices all around the world, at its core is very insular and lives in the Mountain View bubble.
Jyrki is highly talented. Also the author of the incredible Jpegli, which seemed to be a reaction to Google deep-sixing JpegXL, and also Brotli, WebP lossless and WOFF2 among other things.
https://en.wikipedia.org/wiki/Conway%27s_law
"in favor of the homegrown and inferior AVIF"
I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif.
I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is.
As for JPEG XL - I think the problem here is ... Google. Google dictates de-facto web-standards onto us. This is really bad. I don't want a commercial entity control my digital life.
> I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif
going crazy reading this sentence
recursive logic is recursive logic is
For making compact high-quality jpeg files, consider trying jpegli[1], it does an impressive job.
More specifically, if I try a bunch of AVIF quantization options and manually pick the one that appears visually lossless, it beats jpegli, but if I select a quantization option that always looks visually lossless with AVIF, jpegli will win the average size, because I need to use some headroom for images that AVIF does less well on.
1: https://github.com/google/jpegli
no one asked, but FYI in English it is more commmon to say "for several years" instead of "since some years" :)
German speakers usually have very good English, but this is one of their tells.
Another one I've noticed is using "I've" as a contraction in e.g. "I've a meeting to attend". Seems totally reasonable but for some reason native speakers just don't use it that way.
I’ve is only used when there is a verb to follow and the have is part of the verb’s construction.
As in “I’ve done it” or “I’ve seen it”
It would not be used before a noun, in the context of ownership, as in “I have a meeting”
Wait, what? Englishman in my 50s here and I use phrases like that all the time — “I’ll be missing standup cos I’ve a GP appointment”, “leaving at lunchtime as I’ve a train to catch”, “gotta dash, I’ve chores to do”. No one’s ever said I sound German!
I think it's more fair to call it a distinguisher of American English vs. British English.
Even just reading "I've a train to catch" gives a British accent in my mind.
A particular part of Britain as well. I have never used “I’ve” in that way ( I speak more RP than with an accent)
Nah that’s just Americans. Brits and Aussies say it all the time. Not sure about Canadians.
Could also be French speakers. They would say "J'utilise le format .avif depuis quelques années." I think the "depuis" throws off the French speakers when they translate that literally as "since some years" instead of "for some years".
Another common tell: I wake up in the morning in the US/Pacific time zone, and see the European writers on HN using "I have ran" instead of "I have run".
German speakers usually have very good English, but this is already one of their tells.
Fixed that for you.
jpeg-xl seems to do the best being successively re-saved, which is important on the web
https://www.youtube.com/watch?v=w7UDJUCMTng
A little bit related: RAW files from iPhone 17 Pro are compressed using JPEG-XL.
Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface?
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.
100M+ is a bit more than i would expect for an image format. have i not been paying attention
According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header".
So at least if GP was talking about libjxl "100K+" would be more accurate.
[0]: https://github.com/libjxl/libjxl
One of the best ways to measure code complexity is to zip up the source code. This eliminates a lot of the redundancies and is a more direct measure of entropy/complexity than almost anything else.
By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.
Your method would still judge well-documented code with lots of intermediate variables as more complex than undocumented code golf soup.
Interesting approach
It comes from the "intelligence is a form of compression" hypothesis that has been floating around in the ML space. Also, with a good compression algorithm it is a fairly direct measure of entropy, which is quite well correlated with what a developer might consider code size and/or complexity.
>> 100M+ is a bit more than i would expect for an image format. have i not been paying attention
> So at least if GP was talking about libjxl "100K+" would be more accurate.
M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A...:
> A. You’ve identified two commonly used conventions in finance, one derived from Greek and the other from Latin, but neither one is standard.
Starting with the second convention, M is used for amounts in the thousands and MM for amounts in the millions (usually without a space between the number and the abbreviation—e.g., $150M for $150,000 and $150MM for $150 million). This convention overlaps with the conventions for writing roman numerals, according to which a thousand is represented by M (from mille, the Latin word for “thousand”). Any similarity with roman numerals ends there, however, because MM in roman numerals means two thousand, not a thousand thousands, or one million, as in financial contexts...
https://www.accountingcoach.com/blog/what-does-m-and-mm-stan...:
> An expense of $60,000 could be written as $60M. Internet advertisers are familiar with CPM which is the cost per thousand impressions.
> The letter k is also used represent one thousand. For example, an annual salary of $60,000 might appear as $60k instead of $60M.
I assume this is regional... I work in accounting and finance in New Zealand (generally following ordinary Western/Commonwealth standards) and I've never heard of using M for thousands. If I used that I would confuse the hell out of everyone around me.
"It's... a regional dialect."
"What region?"
"Er, upstate New York."
"Really. Well, I'm from Utica and I've never heard anyone use the phrase '100M' to mean '100 thousand'"
"Oh, no, not in Utica. It's an Albany expression."
In some areas M is mille as in the Latin/French/Italian word for thousand, e.g.
https://en.wikipedia.org/wiki/Cost_per_mille
Okay, but this is... not finance? And the article itself wrote 100K. Rewriting that as 100M does nobody a favor.
I don't think many (if any) programmers would imagine 100M lines of code to mean 100,000 lines of code and not 1,000,000...
Technically right is the worst kind of right
I'm surprised at the negative reaction to having it pointed out that the OP may not be wrong, just using a dialect.
The article says 100K, not 100M. I'm guessing that's what the parent comment meant.
100MLOC for an image format would be bananas. You could fit the entire codebases of a couple of modern operating systems, a handful of AAA videogames, and still have room for several web apps and command line utilities in 100MLOC.
the article includes test code and encoder code, that is not the way how we compute the decoder size
the decoder is something around 30 kloc
It's a container format that does about a bajillion things - lossy, lossless, multiple modes optimized for different image types (photography vs digital design), modern encode/decode algorithms, perceptual color space, adaptive quantization, efficient ultra-high-resolution decoding and display, partial and complete animation, tile handling, everything JPEG does, and a bunch more.
The Linux kernel is 40M lines of code after 34 years of development.
OP might have well have said "infinite lines of code" for JPEGXL and wouldn't have been much less accurate. Although I'm guessing they meant 100k.
They wanted to say 100K instead of 100M
This is some strange misinformation.
The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.
It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.
>The compiled compressed binary for an APK
This doesn't undermine your argument at all, but we should not be compressing native libs in APKs.
https://developer.android.com/guide/topics/manifest/applicat...
Google is one of the parties involved in the creating of jxl. If it's their own fault they didn't write a decoder in a memory safe language sooner.
You mean 100K+? A large chunk of which they say is testing code?
libjxl is is <112,888 lines of code, about 3 orders of magnitude less than you're 100M+ claim.
Do people really not know what a hyperbole is?
100M+ lines of code isn't a hyperbole for some codebases, though. google3 is estimated at about 2 billion lines of code, for example.
Maybe it was hyperbole. But if it was it wasn't obvious to me, unfortunately.
-> They were concerned about the increased attack surface resulting from including the current 100K+ lines C++ libjxl reference decoder, even though most of those lines are testing code.
Seems like Google has created a memory-safe decoder for it in Rust or something.
because memory safety is the only attack vector, as we all know
It is a very big one and eliminating it is a huge improvement in security. You can then spend more time fixing all the other sources of security problems.
https://lwn.net/Articles/1048446/
> I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
99% safe with 1% unsafe mixed in is far, far better than 100k loc of c++ -- look at Google's experience with rust in Android. It's not perfect and they had one "almost vulnerability" but the rate of vulnerabilities is much, much lower even with a bit of unsafe mixed in.
Agreed, and Google developers can probably be trusted to 'act responsibly', but too often people forget the distinction. Some Rust codebases are wildly unsafe, and too often people see written in Rust and falsely conclude it's a memory-safe codebase.
> ...but now in le Rust!!1
I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
Because a language happily letting you try to access an array index far past its end isn't stupid at all.
If this was a real problem then you could have just `s/[]/at()/g` across your codebase and called it a day.
But you all don't even bother to do that, so I guess it's not actually a problem in practice.
Starting to feel like this whole "standards" thing is a giant farce
Well, there are de jure standards (what the w3c says a browser should do) and de facto standards (what Chrome does).
As it ever was. Standards are a three-edged sword: spec, intent of spec, and implementations of spec.
Which standard requires support of JXL?
The PDF association apparently recently added jpeg xl to the pdf spec and indicated that it's the preferred solution for HDR content.
Then again PDF also technically supports embedded audio, video, 3D graphics, and arbitrary Javascript. If Flash hadn't died it would probably still support that too. It's a clown car format where everyone besides Adobe just tacitly agrees to ignore huge chunks of the spec.
> It's a clown car format
As is the destiny of any document format in wide spread use, PDF had flash, doc had ActiveX.
Also this text is formatted using a mark down language fully capable of embedding entire applications.
PDF had Flash support? I thought the Flash Xtra for Shockwave was nuts...
Web standard I meant. The OP didn't talk about PDFs from context.
Obligatory xkcd: https://xkcd.com/927
> Yes, right, “not enough interest from the entire ecosystem”. Sure.
Well tbf, the only time I ever hear about JPEG XL is when people complain about Chrome not having it. I think that might be its only actual use case.
The biggest "win" for JPEG XL so far was last year's adoption by Apple for ProRAW, and prosumer photography is will likely be JPEG XL's primary mainstream use case. Pros will continue to shoot in "actual RAW", and consumers will (and this is not an insult) continue to have no interest in the technical details of the compressed media formats being used.
https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-t...
Don’t conflate non-linear and linear image formats.
Cool, that means it'll appear in ebook reading systems in five to ten years.
It'll be in PDF sooner, and my experience is that PDF >> any other system for ebooks. I liked the idea of EPUB but when I recently installed an EPUB reader to read some files I was shocked at how awful it looked whereas for 15 years I've been reading PDF files on tablets with relish.
Have you ever tried reading a PDF ebook on a phone? Small font size, doesn't fill the entire screen (phones are taller), margins make it appear even smaller... even if you have good eyesight it's a pain. The whole point of PDF is to preserve a page layout as authored. EPUB is meant to adapt to your device.
>and my experience is that PDF >> any other system for ebooks.
Are you speaking just about technical books?
Because I can’t imagine anyone trying to read a novel in epub vs pdf on a phone or epub reader and going with the latter.
I am mostly reading on a tablet, not a phone. I think if you are reading on a phone you are already screwed —- if people are “reading” on phones I think 80% of it is that you just read less.
That’s a pretty judgemental statement out of nowhere - and completely ignored the ebook readers part, which are devices literally created for this purpose.
As for phones, screens nowadays are almost the same size as readers and with more resolution. E-ink is more comfortable for longer sessions, but if you find such a size unusable you might just have poor eyesight.
As someone who is super nearsighted, the smaller screen on a phone is great for reading, especially in contexts like bedtime reading where I want to have my glasses off.
I have read many hundreds of books this way.
The problem with a tablet is that most tablets, especially the sort that are good for seeing entire as-printed pages at once, are too big for me to keep the entire screen in focus without wearing glasses. (with that said, foldables improve things here, since the aspect ratio bottleneck is typically width so being able to double the width on the fly makes such things more readable.
Same here! Not to mention having ebooks on my phone means I can read anywhere, anytime. I read more, not less, lol.
The worst epubs are bad because some jackass took some poorly OCRed text and dumped it into the format. The best (retail) epubs are on par with the best PDFs except you don't have to pan-and-scan to read a fucking page. It just reflows.
For novels I want and prefer epubs, but also non-novels if they were released in the last 5 years or so. PDF isn't magic, and there are bad pdfs out there too, scans of photo-copied books and other nonsense.
There is a mode for PDF files that reflows and is logically similar to EPUB in that there is an HTML-derived data model and you have images embedded in the PDF much as they are embedded in the EPUB. Of course if you hate how complex PDF is it is more to hate.
It's also kind of pointless to add that to PDF when HTML already exists and the only real reason for PDF is if you want a fixed layout.
I oversee ebook production for a uni press so I am familiar with how the proverbial sausage is made. Which is why I still mainly prefer print books.
There might be something said for academic texts with their tables of figures and diagrams and so forth. But even then, PDF can be nasty.
That's interesting, I absolutely hate PDF. Lack of metadata for collecting, format is difficult to support, doesn't layout well on mobile, and very limited customization (like dark mode, changing text size, etc).
Only benefit is browsers have built-in support for the format.
One thing I like about PDF is the annotations (notes & highlights) are embedded in the PDF itself. That is not the case for EPUB files, each EPUB reader stores annotations in its own proprietary format.
EPUB it's a glorified HTML page in a zip file.
> Lack of metadata for collecting
PDFs have pretty excellent support for metadata. If the collection software doesn't support at least Dublin Core, that may be kind of their own fault...
That seems optimistic...
Kindle: never.
Good, but mass adoption is a lot slower in sites than in browsers it seems. It's like pulling teeth making sites to actually support even AVIF which is already widely supported in browsers. A ton of inertia even on sites like GitHub and GitLab. Try using AVIF on Wikipedia? Tough luck.
Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet.
Side note - comparing JPEG XL and AVIF features wise is sort of pointless if AVIF will continue to evolve based on AV2 and etc.
There’s also the issue of non-browser support. I recently advocated for replacing some GIFs with WEBM because WEBM was faster to encode and took up 3% as much space. Technically it sounded great. Then we talked to users.
It turns out some users wanted to embed moving pictures in Word documents, which you can only do with a GIF because it’s an image format that happens to move, so Word treats it as an image (by rendering it to the page). If it’s a video format, Word treats it as an attachment that you have to click on so it’ll open Media Player and show you.
Compressing image files from 100k+ lines of C++ in libjxl repository, which contains JPEG XL reference implementation.
Encoding and decoding JPEG XL file is: #djxl input.jxl output.png.
AV2 is in the works, so I guess we'll have AVIF2 soon, and another AVIF2 vs JPEG XL battle.
There's no particular reason for an image format based on video codec keyframes to ever support a lot of the advanced features that JPEG XL supports. It might compress better than AVIF 1, but I doubt it would resolve the other issues.
I believe the appropriate term is ununaliving. Please communicate with care.
That would make more sense than "unkill".
Do we now need https://unkilledbygoogle.com?
As a monopoly, Google should be barred from having standards positions and be legally required to build and support the web standards as determined by other parties.
The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
Having key browser implementers not involved in the standards processes is what lead us to the W3C wasting several years chasing XHTML 2.0.
What you call wasting several years, I call saving us from years of pointless churn.
I kind of liked xhtml, though clearly it was not necessary for the web to be successful. I think the bigger issue is that W3C pursued this to the detriment of more important investments.
Reading over the minutes for the last W3C WG session before WHATWG was announced, the end result seems obvious. The eventual WHATWG folks were pushing for investment in web-as-an-app-platform and everyone else was focused on in retrospect very unimportant stuff.
“Hey, we need to be able to build applications.”
“Ok, but first we need compound documents.”
There was one group who thought they needed to build the web as Microsoft Word and another that wanted to create the platform on which Microsoft Word could be built.
> and another that wanted to create the platform on which Microsoft Word could be built.
Apparently they failed. The web version of Word is still far from having feature parity. Of course doc is one of those everything and the kitchen sink formats, so implementing it on top of a platform that was originally intended to share static documents is kind of a tall order.
that's just microsoft not being good. Google Docs exists and is pretty good.
OnlyOffice is HTML5-based too
There is a difference between having them "involved" and them being the only authority in the entire process.
There are other key browser implementers. Google should not have more than an advisory role in any standards organization.
The other key browser implementers are also part of WHATWG.
Who do you suppose should be in charge of web standards? I can’t imagine the train wreck of incompetence if standards were driven by bureaucrats instead of stakeholders.
How about the users and web authors?
Saying web users should define web standards is like saying laptop users should design CPUs. They lack the expertise to do this meaningfully.
Web authors? Maybe. WHATWG was created specifically because W3C wasn’t really listening to web authors though.
I don’t think there are a lot of scenarios where standards aren’t driven by implementers, though. USB, DRAM, WiFi, all this stuff is defined by implementers.
> WHATWG was created specifically because W3C wasn’t really listening to web authors though.
Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.
Literally the WHATWG founders wanted to focus on web applications, which they said web authors were asking for, and they got voted down.
Google was not involved in the founding of WHATWG, though certainly the WHATWG vision was better aligned with Google than with what the W3C was doing.
They only paid the salary of its chief editor (Ian Hickson) for a significant amount of time...
But that's not very relevant actually. The WHATWG is more like a private arbitrator, not like a court or parliament.
Their mission is to document browser features and coordinate them in such a way that implementation between browsers doesn't diverge too much. It's NOT their mission to decide which features will or will not be implemented or even to design new features. That's left to the browser vendors.
And the most powerful browser vendor is Google.
This is such a bizarre response to me saying Google was not part of the founding WHATWG group. It’s like you want to have an argument but don’t have anything to argue about.
“Oh, yeah? Well they paid Hickson’s salary. And the WHATWG doesn’t matter anyway. And also Google is really powerful.”
Um, ok.
WHATWG was founded in 2004 by Mozilla, Opera, and Apple. Google had no browser at that point and didn’t hire Ian Hickson until 2005.
Google is currently a WHATWG member and clearly wields a great deal of influence there. And yeah, the 4 trillion dollar internet giant is powerful. No argument there.
> Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.
Mozilla, Opera and Apple. Google didn't have a browser then, hadn't even made the main hires who would start developing Chrome yet and hixie was still at Opera.
Ask users what they want and they say "faster horses," not cars.
Users are a key information source but they don't know how to build a web engine, they don't know networks, and they don't know security; and therefore can't dictate the feature set.
web users make their choice via choice in browsers.
And those implementers should make decisions, Google should be bound by the FTC to supporting their recommendations.
Honestly, what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform. I really think anyone who has any sort of confusion about what I commented here to take a long, hard look at their worldview.
> And those implementers should make decisions, Google should be bound by the FTC to supporting their recommendations.
Is your proposal essentially that Mozilla defines web standards Google is legally bound to implement them?
> what's really funny here is how absolutely horrified people are by the suggestion
Not horrified, but asking what the alternative is. I don’t think you’ve actually got a sensible proposal.
Cooperation in the WHATWG is voluntary. Even if there were some workable proposal for how to drive web standards without Google having any decision making power, they could (and presumably would) decline to participate in any structure that mandated what they have to build in Chrome. Absent legal force, no one can make Google cede their investment in web standards.
We have the legal force to do this. Google has already been determined to be abusing their illegal monopoly they have with Chrome. The penalty phase is ongoing, but consider that even forcing Google to sell Chrome was originally considered as a possible penalty.
Requiring Google implement the standards as agreed by Apple, Mozilla, and Microsoft is not remotely outside the realm of the legal force that could be applied.
There’s something not quite right about saying one member of an oligopoly should be forced to follow the dictates of the other members of an oligopoly. I don’t feel like this actually solves anything.
I feel like Mozilla would end up being a Google proxy in this case as they fear losing their funding and Apple and Microsoft would be incentivized to abuse their position to force Google not to do the best thing for the public but the best thing for Apple and Microsoft.
Yeah, that feels like State-sponsored formalizing of oligopolies into a cartels. We'd like it if they went in the complete opposite direction of less power, not more.
I agree there's already a significant proxy risk with Mozilla (though Mozilla does consider many Google web proposals harmful today), but that is also no less true today, and in fact, today that means Google holds two votes not one.
I would again agree Microsoft and Apple will heavily endorse their own interests, Microsoft much more so in terms of enterprise requirements and Apple much more so in terms of privacy-concerned consumers. The advertising firm influence will be significantly dimished and that is a darn shame.
>what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform
They don't. In general browser specs are defined via various standards groups like WHATWG. As far as I know there is no standard for what image formats must be supported on a web browser,[0] which is why in this one case any browser can decide to support an image format or not.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's. They don't want to create a maintenance burden for features that offer little benefit over existing options.
Didn't Mozilla basically say they would support it if Google does? Mozilla doesn't have the resources to maintain a feature that no one can actually use; they're barely managing to keep up with the latest standards as it is.
Yeah, they need those resources to pay the CEO!
They have many millions to spend on engineers. They should do that.
Just come up with some way to make it a huge win for Pocket integration or the like.
> maintain a feature that no one can actually use;
If only there was a way to detect which features a browser supports. Something maybe in the html, the css, javascript or the user agent. If only there was a way to do that, we would not be stuck in a world pretending that everything runs on IE6. /s
>Because Mozilla's stance on JPEG XL and XSLT are identical to Google's.
Okay, and do they align on every other web standard too?
Usually it’s Mozilla not wanting to implement something Google wants to implement, not the other way around.
Indeed, you're making my point.
SquareWheel implied that Mozilla doesn't count as an "other party" because they are aligned with Google on this specific topic.
My comment was pointing out that just because they are aligned on this doesn't mean they are aligned on everything, so Mozilla is an "other party".
And, as you have reinforced, Google and Mozilla are not always in alignment.
I made no such implication. Mozilla is certainly an other party, and their positions on standards hold water. They successfully argued for Web Assembly over Native Client, and have blocked other proposals such as HTML Import in the Web Components API. They are still a key member of the WHATWG.
The fact that Mozilla aligns with Google on both of these deprecations suggests the reasons are valid.
I personally see no reason for XSLT today. Outside of the novelty of theming RSS feeds, it sees very little use. And JPEG XL carries a large security surface area which neither company was comfortable including in its current shape. That may change based on adoption and availability of memory-safe decoders.
Which is why Firefox is steadily losing market share.
If Mozilla wanted Firefox to succeed, they would stop playing "copy Chrome" and support all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.
Not to mention a built-in ad-blocker...
With all due respect, this is a completely HN-brained take.
No significant number of users chooses their browser based on support for image codecs. Especially not when no relevant website will ever use them until Safari and Chrome support them.
And websites which already do not bother supporting Firefox very much will bother even less if said browser by-default refuses to allow them to make revenue. They may in fact go even further and put more effort into trying to block said users unless they use a different browser.
Despite whatever HN thinks, Firefox lost marketshare on the basis of:
A) heavy marketing campaigns by Google including backdoor auto-installations via. crapware installers like free antivirus, Java and Adobe, and targeted popups on the largest websites on the planet (which are primarily google properties). The Chrome marketing budget alone nearly surpasses Mozilla's entire budget and that's not even accounting for the value of the aforementioned self-advertising.
B) being a slower, heavier browser at the time, largely because the extension model that HN loved so much and fought the removal of was an architectural anchor, and beyond that, XUL/XPCOM extensions were frequently the cause of the most egregious examples of bad performance, bloat and brokenness in the first place.
C) being "what their cellphone uses" and Google being otherwise synonymous with the internet, like IE was in the late 1990s and early 2000s. Their competitors (Apple, Microsoft, Google) all own their own OS platforms and can squeeze alternative browsers out by merely being good enough or integrated enough not to switch for the average person.
I don't disagree with you, but given (A) how will Firefox ever compete?
One possible way is doing things that Google and Chrome don't (can't).
Catering to niche audiences (and winning those niches) gives people a reason to use it. Maybe one of the niches takes off. Catering to advanced users not necessarily a bad way to compete.
Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).
>Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).
Good thing they aren't? Firefox's detached video player feature is far superior to anything Chrome has that I'm aware of. Likewise for container tabs, Manifest V2 and anti-fingerprinting mode. And there are AI integrations that do make sense, like local-only AI translation & summaries, which could be a "niche feature" that people care about. But people complain about that stuff too.
And these aren't niche/advanced features? I'm using Firefox now, and did not know about them. If I'm using them, it is only accidentally or because they are the defaults.
But I'm agreeing with you! These features are important to you, an advanced user. The more advanced users for Firefox, the better.
> all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.
What “community” is this? The typical consumer has no idea what any of this is.
I agree with you. But a typical consumer will already be using Chrome, and has no reason to use Firefox.
If one of these advanced/niche technologies takes off, suddenly they will have a reason to use Firefox.
For Firefox to win back significant share, they need to do more than embrace fringe scenarios that normal people don’t care about. They need some compelling reason to switch.
IE lost the lead to Firefox when IE basically just stopped development and stagnated. Firefox lost to Chrome when Firefox became too bloated and slow. Firefox simply will not win back that market until either Chrome screws up majorly or Firefox delivers some significant value that Google cannot immediately copy.
Nah, google paved the way forward with vital developments like WebGPU und import maps. I stopped using and supporting Firefox because they refused to improve the internet.
Not everyone is using their browser to mine dogecoin.
I'm using mine to develop 3D apps, which became way to cumbersome and eventually impossible since Firefox dragged its feet on inplementing important stuff.
Barred by who? There is no governing body who can do such a thing, currently. As it is, nothing stops any random person or organization from creating any new format.
And this will land in Chrome how?
Nobody is stopping you from using jpegxl.
This is a vacuous statement. No one is stopping me from using JPEG XL in the same sense that no one is stopping me from using DIMG10K, a format I just invented. But if I attempt to use either of these in my website today, Chrome will not render them.
In a very real sense Google is currently stopping web authors from using JPEG XL.
The web was designed from the start to solve this problem and you can serve alternate formats to user agents which will select the one they support.
Your statement here amounts to “you can serve JPEG XL to other browsers, just not Chrome”.
Yeah, that’s what I said.
This is the way of web. Sites don't get to dictate what the user agent does. The clue is in the name: user agent.
Okay. So putting it together…
If the user agent does not support JPEG XL, then you cannot use it.
“Nobody is stopping you from using jpegxl” except Google.
Then what is this article about?
It's a meta-commentary about the death of critical thinking and the ease with which mindless mobs can be whipped.
From the jump, the article commits a logical error, suggesting that Google killed jpegxl because it favors avif, which is "homegrown". jpegxl, of course, was also written by Google, so this sentence isn't even internally consistent.
Well, they said they would unkill xslt if someone would rewrite and maintain it so that it's not the abandonware horrorshow it was.
As for JPEG XL, of course they unkilled it. WEBP has been deprecated in favor of JPEG XL.
I don’t think they actually said that about xslt at all. From what I saw they basically said usage is low enough that they do not care about it.
Can you point to somewhere that Google or anyone else indicated that they would support xslt once there’s a secure, supported version?
> Well, they said they would unkill xslt if someone would rewrite and maintain it so that it's not the abandonware horrorshow it was.
Who said this? I was never able to find any support among the browser devs for "keep XSLT with some more secure non-libxslt implementation".
Webp deprecated? According to what?
It's all arbitrary. WEBP is deprecated, just like GIF is deprecated.
VP8 is in all major browsers due to WebRTC, and webp uses little more code than the VP8 keyframe decoder, so it also has baseline support and is unlikely to be deprecated any time soon. https://caniuse.com/?search=vp8
Similarly, AVIF uses little more code than the AV1 keyframe decoder, so since every browser supports AV1, every browser also supports AVIF.
honestly hate webp so happy about this
I don't know much about webp. Just have checked the wiki, it looks nice. So for which reason you hate it?
I don't know much about webp other than you get about 50% savings in compression vs png/jpeg, but it does have some hard limits on sizes of images. It doesn't do well with webtoon reading formats (long strip format).
Otherwise, I love webp and use it for all my comics/manga.
Even nowadays, webp seems to be good specifically for its lossless mode. It seems to create files that are substantially more efficient even when compared with advanced png encoders. For comics, png should probably be used over jpeg, so webp is likely indeed an upgrade, aside from compatibility.
For photographs, jpeg has really been optimized without reducing compatibility, and also in another less compatible way (incompatible viewers can display it without erroring out, but the colors are wrong) and there's such an encoder in the JPEG XL repo.
It was mostly about compatibility but looks like photoshop supports it now so I guess I can now officially say I don't really care one way or the other.
Great now unkill xhtml/xml+xstl
[dead]