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.

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.

> 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.

If 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.

Hi, we indeed support byte for byte reconstruction of the original JPEG codestream.

Interesting!

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.

Is 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)?