JPEG XL

Ah

For Exif, there's another issue: if you have e.g. a 90 degree oriented JPEG and losslessly transcode it to jxl, then the jxl will have the orientation in the jxl codestream header, but also in the Exif. When decoding to pixels, the Exif is ignored and we use the codestream header to properly orient the image (this allows you to just strip all Exif if you want, without getting a wrongly oriented image).

When djxl writes a lossy transcoded jpeg, it first decodes to pixels, and then encodes those pixels in jpeg

So it does orient the pixels and produces a jpeg that is already oriented (not like the original jpeg that needed exif to be oriented)

That's fine, but if we would now just add the Exif to that jpeg, then viewers would orient the jpeg again, causing it to be rotated 180 degrees instead of 90

One possible solution could be to not orient decoded pixels if we know we're going to write a jpeg and we're going to add Exif

Another solution would be to change the Exif we write to do no orientation.

To be honest, I don't really know why djxl supports writing a lossy jpeg at all. It's not really its job to be a jpeg encoder.

It would be convenient if djxl would let you extract metadata though

Like imagemagick does, you can do `convert foo.jpg foo.exif` to get the embedded exif blob

We could make `djxl` do that too quite easily

made some progress on handling exif in a better way: https://github.com/libjxl/libjxl/pull/544