I'm sure there's very good reasoning but I've never been able to convince myself of it - why does EXIF transform metadata exist? If you're taking a selfie, why doesn't the camera itself perform a simple rotation or mirror of the actual image data rather than using EXIF?
You need to appreciate how little RAM and CPU power those cameras have.
As far as cost:
Applying the right tag: 0
Anything else: not 0
Why not include a faster CPU or more RAM? In an industry where people pick one product over the other because of a $10 price difference, you’re never going to convince management to approve the better CPU when a tag solves the problem.
These are hardware companies. They look at software as a nuisance. “fix it in software” is for the downstream.
I don't know why I should have a preference when it comes to the memory layout of an image. If metadata tells be to orient it this way, I'll orient it this way, if that way, then that way. It seems weird and wasteful to me (and potentially prone to error) to want to reorder the data in order to change the display orientation.
I can only imagine caring when it comes to streaming a very large image serially, and then I still have no idea what preference I would have (other than that I get the metadata first.)
As an analogy, if I have some irreplaceable video that has a bad aspect ratio, I fix it in the metadata, I don't transcode it. The data is a blob, the metadata is what tells me how to display it (even if it's just the mimetype.)
Because there are times when it is useful to be able to quickly and losslessly rotate a photo. For example an image viewer might provide quick options to rotate a photo (in case it did end up rotated the wrong way originally).
Probably this should just have been part of the actual image format rather than metadata, but that isn't how it played out.
> why doesn't the camera itself perform a simple rotation or mirror
There could be various reasons. The simplest is that adjusting the rotation naturally happens later in the pipeline than lossy encoding. You don't want to re-encode for quality and performance reasons so just slap on the metadata. The other could be that it is less expensive to avoid rotating. In many cameras the encoding is handled by specialized hardware, adding a way to rotate the raw pixels is likely more expensive than always having the source pixel map to the same input pixel in the encoder. There is no hard reason it couldn't be done, but in many situations it is cheaper to do it this way.
You can transfer EXIF information, including the rotation info, with either exiftool or ImageMagick into a thumbnail, to let other software know how to display it correctly.
If you want to rotate a jpeg yourself (which is easily done with "magic in.jpg rotate 90 out.jpg" and, of course, other software) but lossless, there's https://jpegclub.org/jpegtran/ which accomplishes it.
When generating rotated thumbnails (without caring for "lossless") the best strategy in my experience is to first rotate the large original image and then generate the thumbnail afterwards, because image resizing will most often hide any rotation artifacts anyways.
The rexif crate supports editing, so you can apply rotation when resizing, and then remove the rotation tag from the EXIF data. Keeping EXIF isn't necessary for small thumbnails, but could be desirable for larger versions of the image.
One good reason to keep the raw data and orientation separate is hardware calibrations. I see some discussion here along the lines of "why not just flip the data before saving it", and one counter-argument is that you should store the flip metadata anyways, as it important to trace which hardware pixel corresponds to which stored pixel. I realize this information is not vital for everyone, but it is super useful in fields where you need to characterize the hardware performance at the pixel level (for example astronomy).
I ran into the same issue when working with image processing in Go using libvips.
By default, libvips ignores EXIF orientation too, so I had to explicitly read and apply the orientation tag before doing any resize or crop. Otherwise users ended up with upside-down processed images from photos.
Glad to see this is getting better in Rust.
11 comments
[ 2.6 ms ] story [ 28.9 ms ] threadAs far as cost:
Applying the right tag: 0
Anything else: not 0
Why not include a faster CPU or more RAM? In an industry where people pick one product over the other because of a $10 price difference, you’re never going to convince management to approve the better CPU when a tag solves the problem.
These are hardware companies. They look at software as a nuisance. “fix it in software” is for the downstream.
I can only imagine caring when it comes to streaming a very large image serially, and then I still have no idea what preference I would have (other than that I get the metadata first.)
As an analogy, if I have some irreplaceable video that has a bad aspect ratio, I fix it in the metadata, I don't transcode it. The data is a blob, the metadata is what tells me how to display it (even if it's just the mimetype.)
> why does EXIF transform metadata exist?
Because there are times when it is useful to be able to quickly and losslessly rotate a photo. For example an image viewer might provide quick options to rotate a photo (in case it did end up rotated the wrong way originally).
Probably this should just have been part of the actual image format rather than metadata, but that isn't how it played out.
> why doesn't the camera itself perform a simple rotation or mirror
There could be various reasons. The simplest is that adjusting the rotation naturally happens later in the pipeline than lossy encoding. You don't want to re-encode for quality and performance reasons so just slap on the metadata. The other could be that it is less expensive to avoid rotating. In many cameras the encoding is handled by specialized hardware, adding a way to rotate the raw pixels is likely more expensive than always having the source pixel map to the same input pixel in the encoder. There is no hard reason it couldn't be done, but in many situations it is cheaper to do it this way.
If you want to rotate a jpeg yourself (which is easily done with "magic in.jpg rotate 90 out.jpg" and, of course, other software) but lossless, there's https://jpegclub.org/jpegtran/ which accomplishes it.
When generating rotated thumbnails (without caring for "lossless") the best strategy in my experience is to first rotate the large original image and then generate the thumbnail afterwards, because image resizing will most often hide any rotation artifacts anyways.