4 ms·
I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even
by doodlesdev 20d ago
I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.
- magicalhippo 20d agoJPEG is a lossy frequency-space compression stage followed by a lossless Huffman coding stage. The second stage is quite generic as such, essentially compressing a stream of bits. So you can relatively easily replace the second stage with something better. And since it's lossless you can easily go back. Dropbox[1] and others have exploited this for reducing storage requirements, converting back on-demand so the client doesn't notice. https://github.com/dropbox/lepton https://github.com/dropbox/lepton
- jbverschoor 20d agobyte-for-byte identical file actually. Not just imagery. You can basically save 30% without loosing ANY bit of the original file
- jaffathecake 20d agoBecause what you save in terms of storage, you pay for in decode time, which is an important consideration on the web.
- doodlesdev 20d agoI guess my surprise is mostly that it hasn't been adopted elsewhere. For instance, it still boggles my mind I can't store my JPEG XL images on Google Photos nor take photos as JPEG XL images directly on my Samsung smartphone, but can use HEIC for some fruity reason.
- jaffathecake 20d agoThe DoS thing would certainly make me worry about handling these images on my server.
- Broiler9437 19d agoGoogle Photo teams wanted JXL too, but had to hold back due to Chromium not supporting them
- spider-mario 20d agoDo you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-threaded with djxl took 300ms.
- jaffathecake 20d agoCool. You're getting different results to everyone else. Do you see the same on https://random-stuff.jakearchibald.com/apps/img-decode-bench/ https://random-stuff.jakearchibald.com/apps/img-decode-bench... (make sure you use a browser that supports JPEG XL)?
- spider-mario 20d agoWell, I said “with djxl”, and Chrome/Firefox use jxl-rs which happens to apparently be currently somewhat slower for that use-case (but libjxl being faster shows it doesn’t have to intrinsically be the case), and Safari uses libjxl but multithreaded (so it’s 800 ms for the JPEG and 137 ms for the JXL).
- jaffathecake 20d agoThat's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result. At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.
- F3nd0 20d agojxl-rs will presumably get much faster in time. The work on it started much later than work on libjxl (because it took years for anyone to say they had vested interest in it), and if my understanding is correct, it hasn’t been production-ready until recently. Once it behaves correctly, speed improvements are next in line, presumably.
- janwas 19d ago
- xigoi 19d agoYou pay for decoding only when you view the image, whereas storage is a persistent cost.