That doesn't seem to apply to images that aren't multiples of 8 in size, does it?

Indeed. Whenever I'm using an image browser/manager application that supports rotating images, I wonder if it's doing JPEG rotation properly (as you describe) or just flipping the dumb flag.

Only if the image width/height is a multiple of 8. See: the manpage of jpegtran, especially the -p flag.

Slight nitpicking, but you can rotate in 90° increments without loss.

> What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.

Performance. Rotation during rendering is often free, whereas the camera would need an intermediate buffer + copy if it's unable to change the way it samples from the sensor itself.

At this point I expect any camera ASICs to be able to incorporate this logic for plenty-fast processing. Or to do it when writing out the image file, after acquiring it to a buffer.

Your raw-image idea is interesting. I'm curious as to how photosites' arrangement would play into this.

Sensors are not read out as JPEG but into intermediate memory. The encoding step can then deal with the needed rotation.

RAW images aren't JPEGs so not relevant to the discussion.

Rotation for speed/efficiency/compression reasons (indeed with PNG's horizontal line filters it can have a compression reason too) should have been a flag part of the compressed image data format and for use by the encoder/decoder only (which does have caveats for renderers to handle partial decoding though... but the point is to have the behavior rigorously specified and encoded in the image format itself and handled by exactly one known place namely the decoder), not part of metadata

It's basically a shame that the exif metadata contains things that affect the rendering

Most modern camera modules have built in hardware codecs like mjpeg, region of interest selection, and frame mirror/flip options.

This is particularly important on smartphones and battery operated devices. However, most smartphone devices simply save the photo the same way regardless of orientation, and simply add a display-rotated flag to the metadata.

It can be super annoying sometimes, as one can't really disable the feature on many devices. =3

the main reason is probably that the chip is already outputting the image in a lossy format, and if you reorder the pixels you must reencode the image which means degrading the image, so it's much better to just change the exif orientation.

Burst mode in cameras means the sensor is readout is buffered in RAM while the encoding and writing to persistent storage catches up. Rotating the buffer would be part of the latter and not affect burst speed - and is an insignificant cost anyway.