[HN Gopher] Google unkills JPEG XL?
___________________________________________________________________
Google unkills JPEG XL?
Author : speckx
Score : 212 points
Date : 2025-12-01 15:28 UTC (7 hours ago)
(HTM) web link (tonisagrista.com)
(TXT) w3m dump (tonisagrista.com)
| Finnucane wrote:
| Cool, that means it'll appear in ebook reading systems in five to
| ten years.
| IshKebab wrote:
| That seems optimistic...
| Finnucane wrote:
| Kindle: never.
| PaulHoule wrote:
| 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.
| mubou2 wrote:
| 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.
| majora2007 wrote:
| 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.
| leosanchez wrote:
| 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.
| Zardoz84 wrote:
| EPUB it's a glorified HTML page in a zip file.
| swiftcoder wrote:
| > 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...
| kace91 wrote:
| >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.
| PaulHoule wrote:
| 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.
| kace91 wrote:
| 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.
| NoMoreNicksLeft wrote:
| 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.
| Finnucane wrote:
| 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.
| NoMoreNicksLeft wrote:
| 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.
| PaulHoule wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| bigbuppo wrote:
| 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.
| ryanmcbride wrote:
| honestly hate webp so happy about this
| excusable wrote:
| I don't know much about webp. Just have checked the wiki,
| it looks nice. So for which reason you hate it?
| majora2007 wrote:
| 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.
| ryanmcbride wrote:
| 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.
| lloydatkinson wrote:
| Webp deprecated? According to what?
| lern_too_spel wrote:
| 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.
| bigbuppo wrote:
| It's all arbitrary. WEBP is deprecated, just like GIF is
| deprecated.
| dpark wrote:
| 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?
| LegionMammal978 wrote:
| > 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".
| SquareWheel wrote:
| 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.
| jfindper wrote:
| > _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?
| johncolanduoni wrote:
| Usually it's Mozilla not wanting to implement something
| Google wants to implement, not the other way around.
| jfindper wrote:
| 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.
| mubou2 wrote:
| 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.
| philipallstar wrote:
| They have many millions to spend on engineers. They should
| do that.
| DrewADesign wrote:
| Just come up with some way to make it a huge win for
| Pocket integration or the like.
| jamesnorden wrote:
| Yeah, they need those resources to pay the CEO!
| josefx wrote:
| > 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
| Fileformat wrote:
| 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...
| dralley wrote:
| 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.
| Fileformat wrote:
| 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).
| dralley wrote:
| >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.
| Fileformat wrote:
| 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.
| dpark wrote:
| > 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.
| Fileformat wrote:
| 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.
| dpark wrote:
| 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.
| nilamo wrote:
| 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.
| xg15 wrote:
| And this will land in Chrome how?
| simonw wrote:
| Having key browser implementers not involved in the standards
| processes is what lead us to the W3C wasting several years
| chasing XHTML 2.0.
| ocdtrekkie wrote:
| There are other key browser implementers. Google should not
| have more than an advisory role in any standards
| organization.
| dpark wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| dpark wrote:
| > 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.
| ocdtrekkie wrote:
| 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.
| dpark wrote:
| 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.
| ocdtrekkie wrote:
| 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_.
| moron4hire wrote:
| 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.
| fngjdflmdflg wrote:
| >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/...
| xg15 wrote:
| How about the users and web authors?
| dpark wrote:
| 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.
| aleph_minus_one wrote:
| > 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.
| dpark wrote:
| 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.
| xg15 wrote:
| 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.
| dpark wrote:
| 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.
| magicalist wrote:
| > _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.
| shadowgovt wrote:
| 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.
| jpadkins wrote:
| web users make their choice via choice in browsers.
| xg15 wrote:
| There is a difference between having them "involved" and them
| being the only authority in the entire process.
| dpark wrote:
| 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.
| josefx wrote:
| > 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.
| arccy wrote:
| that's just microsoft not being good. Google Docs exists
| and is pretty good.
| jeffbee wrote:
| Nobody is stopping you from using jpegxl.
| xg15 wrote:
| Then what is this article about?
| jeffbee wrote:
| 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.
| dpark wrote:
| 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.
| jeffbee wrote:
| 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.
| dpark wrote:
| Your statement here amounts to "you can serve JPEG XL to
| other browsers, just not Chrome".
|
| Yeah, that's what I said.
| jeffbee wrote:
| 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.
| dpark wrote:
| 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.
| m-schuetz wrote:
| 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.
| josefx wrote:
| Not everyone is using their browser to mine dogecoin.
| m-schuetz wrote:
| 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.
| m348e912 wrote:
| A full-resolution, maximum-size JPEG XL image (1,073,741,823 x
| 1,073,741,824):
|
| Uncompressed: 3.5-7 exabytes Realistically compressed: Tens to
| hundreds of petabytes
|
| Thats a serious high-res image
| cubefox wrote:
| 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.)
| tyre wrote:
| 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!
| flir wrote:
| An image of earth at very roughly 4cmx4cm resolution? (If I've
| knocked the zero's off correctly)
| yread wrote:
| The only practical way to work with such large images is if
| they are tiled and pyramidal anyway
| Akronymus wrote:
| what does pyramidal mean in this context?
| jjk7 wrote:
| Tiled at different zoom levels
| scheme271 wrote:
| 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.
| shadowgovt wrote:
| 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.
| jjcob wrote:
| 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.
| wang_li wrote:
| We call those mipmaps.
| Magnap wrote:
| 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.
| xnorswap wrote:
| 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.
| fwip wrote:
| Wolfram alpha is the better calculator for that sort of
| thing.
| threeducks wrote:
| > 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.
| Intralexical wrote:
| "Google's magic calculator" was probably just a wrapper to
| GNU Units [0], which produces: $ units
| You have: (1073741823/(600/inch))**2 / A4paper You
| want: Definition: 3.312752e+10
|
| Equivalent tools: Qalc, Numbat
|
| 0: https://news.ycombinator.com/item?id=36994418
| dweekly wrote:
| 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
| ChrisArchitect wrote:
| [dupe]
|
| Main recent discussion:
|
| _Google Revisits JPEG XL in Chromium After Earlier Removal_
|
| https://news.ycombinator.com/item?id=46021179
| ChrisArchitect wrote:
| not to mention this other dupe with lots of discussion also
| from last week: https://news.ycombinator.com/item?id=46033330
| dang wrote:
| 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!
| pornel wrote:
| AV2 is in the works, so I guess we'll have AVIF2 soon, and
| another AVIF2 vs JPEG XL battle.
| dralley wrote:
| 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.
| EMM_386 wrote:
| 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.
| tensegrist wrote:
| 100M+ is a bit more than i would expect for an image format.
| have i not been paying attention
| crooked-v wrote:
| 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.
| furyofantares wrote:
| 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.
| aw1621107 wrote:
| 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
| palmotea wrote:
| >> 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.
| WheatMillington wrote:
| 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.
| mkaic wrote:
| "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."
| qingcharles wrote:
| 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
| dataflow wrote:
| Okay, but this is... not finance? And the article itself
| wrote 100K. Rewriting that as 100M does nobody a favor.
| sealeck wrote:
| 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...
| uselesswords wrote:
| Technically right is the worst kind of right
| jiggawatts wrote:
| 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.
| tkfoss wrote:
| Interesting approach
| GaggiX wrote:
| They wanted to say 100K instead of 100M
| munificent wrote:
| 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.
| JyrkiAlakuijala wrote:
| 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
| dataflow wrote:
| You mean 100K+? A large chunk of which they say is testing
| code?
| ajcp wrote:
| -> 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.
| cornstalks wrote:
| libjxl is is <112,888 lines of code, about 3 orders of
| magnitude less than you're 100M+ claim.
| sunaookami wrote:
| Do people really not know what a hyperbole is?
| cornstalks wrote:
| 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.
| MaxBarraclough wrote:
| > 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.
| dgacmu wrote:
| 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.
| MaxBarraclough wrote:
| 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.
| otabdeveloper4 wrote:
| > ...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.
| theoldgreybeard wrote:
| because memory safety is the only attack vector, as we all know
| UltraSane wrote:
| 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.
| JyrkiAlakuijala wrote:
| 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.
| bmicraft wrote:
| 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.
| binary132 wrote:
| Starting to feel like this whole "standards" thing is a giant
| farce
| criddell wrote:
| Well, there are _de jure_ standards (what the w3c says a
| browser should do) and _de facto_ standards (what Chrome does).
| shadowgovt wrote:
| As it ever was. Standards are a three-edged sword: spec,
| intent of spec, and implementations of spec.
| izacus wrote:
| Which standard requires support of JXL?
| scheme271 wrote:
| The PDF association apparently recently added jpeg xl to the
| pdf spec and indicated that it's the preferred solution for
| HDR content.
| jsheard wrote:
| 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.
| josefx wrote:
| > 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.
| izacus wrote:
| Web standard I meant. The OP didn't talk about PDFs from
| context.
| lgl wrote:
| Obligatory xkcd: https://xkcd.com/927
| MutableLambda wrote:
| 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.
| jsheard wrote:
| 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.
| philistine wrote:
| 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!
| nine_k wrote:
| 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.
| chimeracoder wrote:
| > 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.
| izacus wrote:
| 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.
| usrnm wrote:
| The most popular software in question is also a giant pile
| of C++, btw.
| izacus wrote:
| What are you saying here?
| ux266478 wrote:
| Who is saying Google should ship the reference
| implementation? It's a standard, and Google has the labor
| to write their own implementation.
| izacus wrote:
| That sounds like an even more request for someone to do
| for free, doesn't it?
| ipdashc wrote:
| 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?
| SoKamil wrote:
| > any substantial (non-degenerative)
|
| Why this quality poses security issues?
| spookie wrote:
| 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!
| rootnod3 wrote:
| Do we now need https://unkilledbygoogle.com?
| moffkalast wrote:
| > 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.
| CharlesW wrote:
| 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...
| shevy-java wrote:
| "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.
| senbrow wrote:
| no one asked, but FYI in English it is more commmon to say "for
| several years" instead of "since some years" :)
| phatfish wrote:
| German speakers usually have very good English, but this is
| one of their tells.
| lsecondario wrote:
| 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.
| rottencupcakes wrote:
| 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"
| darrenf wrote:
| 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!
| mpyne wrote:
| 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.
| Grosvenor wrote:
| German speakers usually have very good English, but this is
| already one of their tells.
|
| Fixed that for you.
| rottencupcakes wrote:
| > I am not saying .avif is perfect, but IMO it is much better
| than .jpg or .avif
|
| going crazy reading this sentence
| mrbluecoat wrote:
| recursive logic is recursive logic is
| zorgmonkey wrote:
| 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
| goku12 wrote:
| 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.
| ksec wrote:
| 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.
| bmicraft wrote:
| 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.
| inejge wrote:
| "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?
| bmicraft wrote:
| my fallible memory of roughly the same sources
| IncreasePosts wrote:
| I believe the appropriate term is ununaliving. Please communicate
| with care.
| cpburns2009 wrote:
| That would make more sense than "unkill".
| bmacho wrote:
| Great now unkill xhtml/xml+xstl
| egorfine wrote:
| A little bit related: RAW files from iPhone 17 Pro are compressed
| using JPEG-XL.
| CharlesW wrote:
| 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,193x4,320."_
| -- JXL's theoretical maximum image size is bigger. The author
| cites AVIF's Baseline profile (think embedded devices), but AVIF
| supports 16,384x8,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.
| ballpug wrote:
| 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.
| ragall wrote:
| 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.
| jiggawatts wrote:
| https://en.wikipedia.org/wiki/Conway%27s_law
| qingcharles wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-01 23:01 UTC)