Re:H.264 is Magic (2016)
by mkl on Thursday March 17, 2022 @04:44PM
(#30715679)
I think you might have that backwards. JPEG can be losslessly converted to JPEG XL with better compression (~20% smaller), but I haven't seen anything about going the other direction. I'm not sure how it would be possible with JPEG XL's different sized blocks and different available transforms. https://en.wikipedia.org/wiki/JPEG_XL
[ Parent
| on HN ]
The JPEG -> JXL conversion is reversible, so you can encode JPEG -> convert JXL -> convert back to JPEG as needed. You could potentially encode a JPEG-XL directly with the subset that can be converted back to JPEG, but it's not clear to me if libjxl currently implements that.
Either way, it's not that useful for anyone that's already deploying post-JPEG formats; even WebP should save more than 20%. Mostly it's useful for CDNs and SaaS companies like Cloudinary to transparently deploy JPEG-XL for JPEG-only customers.
Do you mean that you would want that to happen on the web server, if they detect a user-agent that doesn't support JXL, they would convert back to JPEG? That seems pointlessly costly in CPU.
Also like mkl said, there doesn't seem to be any evidence that JXL->JPEG can be done losslessly.
Dont know about web servers, but there are people doing it on the backup/storage side. https://dropbox.tech/infrastructure/lepton-image-compression...