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

211–220 of 283 posts

Re: Google unkills JPEG XL?

#211

Post by stingraycharles »

geokon wrote: post #210
refibrillator wrote: post #202

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…

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?

Isn’t that what the comment you’re replying to is suggesting?

Re: Google unkills JPEG XL?

#212

Post by OneDeuxTriSeiGo »

geokon wrote: post #210
refibrillator wrote: post #202

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…

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.

Re: Google unkills JPEG XL?

#213

Post by jiggawatts »

tkfoss wrote: post #189
jiggawatts wrote: post #185

Earlier quoted context omitted.

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.

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.

Re: Google unkills JPEG XL?

#214

Post by UltraSane »

otabdeveloper4 wrote: post #115
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'…

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

Re: Google unkills JPEG XL?

#215

Post by hxtk »

shmerl wrote: post #204

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

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.

Re: Google unkills JPEG XL?

#216

Post by BenjiWiebe »

Intralexical wrote: post #179
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…

"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

It couldn't have been a wrapper - it understood a tiny tiny fraction of the things that Gnu units does.

Re: Google unkills JPEG XL?

#217

Post by klempner »

PaulHoule wrote: post #109
torben-friis wrote: post #91

Earlier quoted context omitted.

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

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.

Re: Google unkills JPEG XL?

#218

Post by kmeisthax »

jsheard wrote: post #101
scheme271 wrote: post #71

Earlier quoted context omitted.

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.

PDF had Flash support? I thought the Flash Xtra for Shockwave was nuts...

Re: Google unkills JPEG XL?

#219

Post by thayne »

drysart wrote: post #203
goku12 wrote: post #156

Earlier quoted context omitted.

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

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

Re: Google unkills JPEG XL?

#220

Post by flakes »

m348e912 wrote: post #13

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

A selfie at that resolution would be some sort of super-resolution microscopy.
Post reply on HN