LodeMike comments on JPEG-XL Image Support Returns To Latest Chrome / Chromium Code

[+] LodeMike@lemmy.today -19 points 9 months ago (4 children)

So what you're saying is: both formats can encode image data

permalink

fedilink

source

parent

hideshow 4 child comments

[+] reddig33@lemmy.world 8 points 9 months ago* (last edited 3 weeks ago) (3 children)

[deleted]

permalink

fedilink

source

parent

hideshow 3 child comments

[–] logi@lemmy.world 3 points 9 months ago

The difference (claimed by the comment above) is in the words

without loss of quality

So you can convert back and forth without the photo copy of a photo copy problem.

And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule.

permalink

fedilink

source

parent

[–] adespoton@lemmy.ca 3 points 9 months ago

And let’s not forget HEIF and JPEG-2000.

permalink

fedilink

source

parent

[–] The_Decryptor@aussie.zone 2 points 9 months ago

What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed.

Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file.

But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss.

permalink

fedilink

source

parent

[–] rjek@feddit.uk 2 points 9 months ago

No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility.