- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 21 Aug 2020 14:23:19 +0200
- To: ietf-http-wg@w3.org
Am 21.08.2020 um 14:00 schrieb Alex Deymo: > Hi, > I'm Alex and I'm working in the JPEG XL project. The transcoding being > discussed for this is indeed the lossless recompression of JPEG files > feature in JXL. > > JXL has many more features as a codec than what the lossless JPEG > recompression can offer, you would get a lot better compression density > for similar visual quality if you don't need to be able to reconstruct > the exact same original JPEG file (or if your original was not a JPEG to > start with but RAW data from a camera), so it makes a lot of sense to > add jxl as an image codec on its own. > > However, on top of that, the lossless recompression of JPEG files allows > you to get this ~20% gain for existing files. When you deploy a new > lossy codec there is the question of what to do with the existing > images. If you have a website with photos and want to convert your > already lossy JPEG files to a new codec to save storage and bandwidth > and you decide to decode them to pixels and encode them back to the new > format you will end up with more artifacts or worse compression density > trying to accurately represent the JPEG artifacts in the new codec, > whatever the codec is. It's impractical to do this lossy transcoding to > a new codec at large scale on existing images, each application would > need to evaluate whether they want to do this for existing images. This > story is different if you start with a large and high quality image > (like a JPEG from a camera) and want to encode in a smaller form for the > web, since there you already have a high quality file. That makes it sound a bit as if a losslessly-re-encoded JPG file is not a valid JXL file. Is that the case? > ... > I think the only shocking thing about a content-encoding for JPEGs is > that it can't encode any arbitrary file only JPEGs, but if you look at > "general purpose" compressors like Brotli they still can't compress to a > smaller file every file; many binary files that are already compressed > like .zip or even a JPEG files (unless they have a large ICC) won't > compress to a smaller file so you just don't do it even if Brotli is > able to compress them to a ~similar size file. > ... That's indeed a concern. For the other currently registered encodings, you *can* apply them, but they do not necessarily help. This one can't be applied to any file type. One way to address this would be to tune the format that it *can* handle any file type (by just adding a tiny wrapper around it and preserving the actual octet stream within). > ... Best regards, Julian
Received on Friday, 21 August 2020 12:23:36 UTC