Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google unkills JPEG XL?

tonisagrista.com

Post reply on HN
Print view View original

221–230 of 283 posts

Re: Google unkills JPEG XL?

#221

Post by charleslmunger »

JyrkiAlakuijala wrote: post #119
EMM_386 wrote: post #37

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'…

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 th…

>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...

Re: Google unkills JPEG XL?

#222

Post by von_lohengramm »

CharlesW wrote: post #130

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 ev…

> 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.

Re: Google unkills JPEG XL?

#223

Post by hmbfcvib »

CharlesW wrote: post #104
moffkalast wrote: post #67

> 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.

Re: Google unkills JPEG XL?

#224

Post by objectcode »

majora2007 wrote: post #34
excusable wrote: post #24

Earlier quoted context omitted.

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.

Re: Google unkills JPEG XL?

#225

Post by timc3 »

mpyne wrote: post #193
darrenf wrote: post #187

Earlier quoted context omitted.

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)

Re: Google unkills JPEG XL?

#226

Post by palmotea »

uselesswords wrote: post #175
palmotea wrote: post #123

Earlier quoted context omitted.

>> 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 der…

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.

Re: Google unkills JPEG XL?

#227

Post by _jzlw »

klempner wrote: post #217
PaulHoule wrote: post #109

Earlier quoted context omitted.

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.

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.…

Same here! Not to mention having ebooks on my phone means I can read anywhere, anytime. I read more, not less, lol.

Re: Google unkills JPEG XL?

#228

Post by mdriley »

philistine wrote: post #146
jsheard wrote: post #48

Earlier quoted context omitted.

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!

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...

Re: Google unkills JPEG XL?

#229

Post by asddubs »

jeffbee wrote: post #196
ux266478 wrote: post #105

Earlier quoted context omitted.

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

Re: Google unkills JPEG XL?

#230

Post by asddubs »

threeducks wrote: post #69
xnorswap wrote: post #51

Earlier quoted context omitted.

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 squ…

> 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
Post reply on HN