djpegli strips EXIF Orientation Tag without applying it

[Traneptora]

Describe the bug
When decoding a JPEG1 image with djpegli that has an EXIF tag that broadcasts an orientation (not equal to 1), djpegli will write the EXIF profile, and it will set the orientation to 1, but it will not autorotate the image, so the end result is that the orientation data is stripped.

To Reproduce
Consider the following JPEG:

Note: One can also obtain the jpeg by running djxl on the following conformance JXL sample, which reconstructs the above JPEG: https://github.com/libjxl/conformance/blob/master/testcases/bench_oriented_brg/input.jxl

Expected behavior
djpegli should either strip the EXIF orientation and write a rotated image, or it should not strip the metadata. Stripping the orientation data it without applying it is not correct.

Logs

leo@gauss ~ :) $ djpegli bench.jpg bench.png
Read 218481 compressed bytes.
500 x 606,  67.385 MP/s [67.38, 67.38], , 1 reps, 1 threads.
leo@gauss ~ :) $ magick identify -format 'width: %w, height: %h, orientation: %[exif:Orientation]\n' bench.jpg
width: 500, height: 606, orientation: 5
leo@gauss ~ :) $ magick identify -format 'width: %w, height: %h, orientation: %[exif:Orientation]\n' bench.png
width: 500, height: 606, orientation: 1
leo@gauss ~ :) $ exiftool -Orientation bench.jpg
Orientation                     : Mirror horizontal and rotate 270 CW
leo@gauss ~ :) $ exiftool -Orientation bench.png
Orientation                     : Horizontal (normal)

The width and height should be exchanged if it were baked in, because this orientation (5) requires a 90-degree rotation.

Environment

• OS: Arch Linux x86_64
• Compiler version: GCC 14.2.1
• cjxl/djxl version string: (reported by djxl) JPEG XL decoder v0.12.0 798512a9 [_AVX2_]

Additional context
jpegli built from https://github.com/libjxl/libjxl/

[Traneptora]

If I had to guess, the tag is ignored/stripped/set-to-1 because this is correct behavior when decoding a JPEG XL file, as the JPEG XL specification says the codestream's orientation tag always takes priority. However, since this decode is not coming from a JPEG XL codestream, but rather a JPEG1 file, this should not be the case.