10 ms·
Google unkills JPEG XL?
- theturtle 1y ago[dead]
- Finnucane 1y agoCool, that means it'll appear in ebook reading systems in five to ten years.
- IshKebab 1y agoThat seems optimistic...
- Finnucane 1y agoKindle: never.
- PaulHoule 1y agoIt'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.
- _jzlw 1y agoHave 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 1y agoThat'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 1y agoOne 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 1y agoEPUB it's a glorified HTML page in a zip file.
- majora2007 1y agoVery true, I just rolled out annotations for Kavita (a self-hosted book/comic server) and epub doesn't have the ability to store it in the file (although Kavita has a no-modification policy). Although for cases like Kavita, storing in the file would be problematic if multiple users want their own annotations without concerns of data leaking.
- swiftcoder 1y ago> 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...
- majora2007 1y agoI haven't seen this in the real world or the tooling to back it up. Currently, Calibre is the only software that writes metadata that pulls from online sources. I'm sure Adobe Acrobat also supports, but that's not used in the scene.
- swiftcoder 1y agoFeels like a very big gap in the OSS world then. The PDF spec supports multiple standards for metadata, Acrobat has workflows for all of them, and Adobe sells into a bunch of verticals (such as public libraries) that rely on this functionality heavily.
- torben-friis 1y ago>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 1y agoI 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.
- torben-friis 1y agoThat’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.
- klempner 1y agoAs 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.
- _jzlw 1y agoSame here! Not to mention having ebooks on my phone means I can read anywhere, anytime. I read more, not less, lol.
- NoMoreNicksLeft 1y agoThe 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 1y agoI 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 1y agoThere 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 1y agoThere 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.
- account42 1y agoIt'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.
- ocdtrekkie 1y agoAs 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 1y agoWell, 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 1y agohonestly hate webp so happy about this
- excusable 1y agoI don't know much about webp. Just have checked the wiki, it looks nice. So for which reason you hate it?
- majora2007 1y agoI 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.
- objectcode 1y agoEven 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.
- m348e912 1y agoA 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
- cubefox 1y agoYes, 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 1y agoI 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 1y agoAn image of earth at very roughly 4cmx4cm resolution? (If I've knocked the zero's off correctly)
- aidenn0 1y agoEach 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.
- flir 1y agoI admit it, I was applying Cunningham’s Law. Disappointingly(?), you came to the same answer.
- 1y ago
- dweekly 1y agoPrior HN posts/discussions: Chromium Team Re-Opens JPEG XL Feature Ticket https://news.ycombinator.com/item?id=46018994 https://news.ycombinator.com/item?id=46018994 FSF Slams Google over Dropping JPEG-XL in Chrome https://news.ycombinator.com/item?id=35589179 https://news.ycombinator.com/item?id=35589179 Google set to deprecate JPEG XL support in Chrome 110 https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 Chromium jpegxl issue closed as won't fix https://news.ycombinator.com/item?id=40407475 https://news.ycombinator.com/item?id=40407475
- ChrisArchitect 1y ago[dupe] Main recent discussion: Google Revisits JPEG XL in Chromium After Earlier Removal https://news.ycombinator.com/item?id=46021179 https://news.ycombinator.com/item?id=46021179
- ChrisArchitect 1y agonot to mention this other dupe with lots of discussion also from last week: https://news.ycombinator.com/item?id=46033330 https://news.ycombinator.com/item?id=46033330
- dang 1y agoLots more at https://news.ycombinator.com/item?id=36214955 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 1y agoAV2 is in the works, so I guess we'll have AVIF2 soon, and another AVIF2 vs JPEG XL battle.
- dralley 1y agoThere'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 1y agoIsn'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 1y ago100M+ is a bit more than i would expect for an image format. have i not been paying attention
- crooked-v 1y agoIt'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 1y agoThe 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 1y agoAccording 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 https://github.com/libjxl/libjxl
- binary132 1y agoStarting to feel like this whole "standards" thing is a giant farce
- lgl 1y agoObligatory xkcd: https://xkcd.com/927 https://xkcd.com/927
- deleted 1y ago[deleted]
- criddell 1y agoWell, there are de jure standards (what the w3c says a browser should do) and de facto standards (what Chrome does).
- shadowgovt 1y agoAs it ever was. Standards are a three-edged sword: spec, intent of spec, and implementations of spec.
- izacus 1y agoWhich standard requires support of JXL?
- scheme271 1y agoThe PDF association apparently recently added jpeg xl to the pdf spec and indicated that it's the preferred solution for HDR content.
- jsheard 1y agoThen 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.
- MutableLambda 1y agoHave 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 1y agoThat'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 1y agoIf 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 1y agoBMP 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 https://nvd.nist.gov/vuln/detail/CVE-2025-32468 It's not the format, it's the C / C++ unfortunate baggage.
- mdriley 1y agoHappy 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/+/7208236 https://chromium-review.googlesource.com/c/chromium/src/+/72...
- foresterre 1y agoThis 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 https://crates.io/crates/image
- rootnod3 1y agoDo we now need https://unkilledbygoogle.com https://unkilledbygoogle.com?
- deleted 1y ago[deleted]
- moffkalast 1y ago> 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 1y agoThe 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-the-iphone-16-and-what-it-means-for-your-photos/ https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-t...
- hmbfcvib 1y agoDon’t conflate non-linear and linear image formats.
- shevy-java 1y ago"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 1y agono one asked, but FYI in English it is more commmon to say "for several years" instead of "since some years" :)
- phatfish 1y agoGerman speakers usually have very good English, but this is one of their tells.
- lsecondario 1y agoAnother 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 1y agoI’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”
- deleted 1y ago[deleted]
- darrenf 1y agoWait, 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!
- zorgmonkey 1y agoIt 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 https://issues.chromium.org/issues/40168998#comment507
- goku12 1y agoThat 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 1y agoIt 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.
- aidenn0 1y agoIIRC they benchmarked it as "not much better" than AVIF, not inferior.
- drysart 1y ago> 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.
- thayne 1y agoThat 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.
- IncreasePosts 1y ago[flagged]
- cpburns2009 1y agoThat would make more sense than "unkill".
- bmacho 1y agoGreat now unkill xhtml/xml+xstl
- egorfine 1y agoA little bit related: RAW files from iPhone 17 Pro are compressed using JPEG-XL.
- danhau 1y agoHow‘s that possible? JPEG-XL stores image files, right? But RAW files are not images in the same sense. They haven‘t even been demosaiced. Or are Apple RAWs different? Edit: I should have googled. apple‘s ProRAW does this, which isn‘t a RAW file in the classic sense.
- CharlesW 1y agoJXL'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.
- wherenow4 1y agoI 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.
- von_lohengramm 1y ago> 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.
- ballpug 1y agoCompressing 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 1y agoQuick 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 1y agohttps://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- qingcharles 1y agoJyrki 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.
- refibrillator 1y agoOne 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.
- geokon 1y agoIf 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?
- stingraycharles 1y agoIsn’t that what the comment you’re replying to is suggesting?
- bmacho 1y agoI think GP only wants to convert images back for users with legacy browsers, not for everyone. So converting 100% of the images needs more compute money than the amount of storage money it saves, but only converting ~1% of the images on-the-fly would be worth it financially.
- OneDeuxTriSeiGo 1y agoYou 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.
- gonzalohm 1y agoWhat's the point of transcoding? You still have to store the original DICOM right? That's probably the bulk of the cost
- shmerl 1y agoGood, 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.
- hxtk 1y agoThere’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.
- chrismorgan 1y agoAnimated images were such a mistake.
- a3w 1y ago"Google revives JPEG XL" works too, in the English language. Why invent a new word?