3 ms·
>You can go back from XL to jpeg losslessly as well I don't think so, but I don't quite see the point unless you are thinking of using it as a way to archive j
by BurningCycles 7y ago
>You can go back from XL to jpeg losslessly as well
I don't think so, but I don't quite see the point unless you are thinking of using it as a way to archive jpeg's, but in that case there are programs specifically for that, like PackJPG, Lepton etc.
- QasimK 7y agoHow is it possible to have one-way only lossless compression?
- Dylan16807 7y agoDecompressing and recompressing a zip gives a lossless copy of the actual data, but there's no way to reconstruct the same exact zip you started with. The same thing can be done with image data. For something like jpeg you can keep the coefficients but store them in a more compact form. For what it's worth JPEG XL claims that it's 'reversible', but I'm not sure if that means you get your original jpeg back, byte for byte, or you get an equivalent jpeg back.
- account42 7y ago> Decompressing and recompressing a zip gives a lossless copy of the actual data, but there's no way to reconstruct the same exact zip you started with. I don't think getting the same JPEG is the goal here but getting a JPEG that decodes to the same image data.
- eru 7y agoIf you can get all the pixels back exactly, getting the original jpeg back would only require a very small amount of extra data. But it might be more hassle than it's worth it to create the code and algorithms to do so.
- janwas 7y agoHi, we indeed support byte for byte reconstruction of the original JPEG codestream.
- eru 7y agoInteresting! Btw, if memory serves right, Google Photos deliberately gives you back the same pixels but not the same JPEG codestream bits under some circumstances. That's too make it harder to exploit vulnerabilities with carefully crafted files.
- ubercow13 7y agoIs it possible to get a JPEG back without any loss when recompressing a JPEG to another JPEG (after discarding the original, ie JPEG -> bitmap -> JPEG)?
- spider-mario 7y agoJPEG XL integrates https://github.com/google/brunsli https://github.com/google/brunsli , and when used in that mode, you can go back to the original JPEG file in a bit-exact way. There is also a mode that only preserves the JPEG image data.
- setr 7y agoIf you can go both directions, you can store the more efficient jpegXL format but still have perfectly transparent support for clients that don't support jpegXL. If you can't produce the exact same original jpeg, then you can still have some issues during the global upgrade process -- eg your webserver database of image hashes for deduplication has to be reconstructed. A relatively minor problem to be sure, but afaict if jpegXL does support this (which apparently it does), the upgrade process is really as pain-free as I could imagine. I can't really think of anything more you could ask for out of a new format. Better & backwards+forward compatibility