During the holiday break I spent some time learning about EXIF data and subsequently released Exif.in[0], a simple HTTP API for viewing EXIF data inside images and requesting EXIF-stripped copies as well.
If you're a developer who needs to occasionally inspect EXIF data from user uploads, please check it out. Contact me if you have additional questions, I'm happy to help.
What puzzles me is that Windows XP up to Windows 7 built-in picture viewer does not support proper orientation of iPhone photos with the original EXIF metadata in place.
Picasa (on Windows) handles that perfectly, as well as (obviously) all apps in OS X.
What the hell Microsoft? Is this a political thing or is there a valid technical reason?
Here's my guess as to why it would work like that. Random software package either supports the EXIF orientation or it doesn't. If it doesn't, Joe User just sees the photo rotated wrong, and they want to fix it. Joe knows he can rotate photos in Windows Picture Viewer. So he opens the file in Windows Picture Viewer and it ignores the EXIF orientation too, so he just hits rotate then goes about his business. If Windows Picture Viewer respected the EXIF orientation, it would be much less useful for this task.
Given that, OS X Preview has a different approach. It respects the EXIF orientation when you open a file, but when you re-save a file, it silently rotates the file and resets the orientation. Not sure if that is better or worse.
I don't think it's either of those things. I had problems with Windows Phones and getting the orientation right in Picture Viewer as well. I don't think it's politics, I don't think it's a valid technical reason, I think it's just an oversight.
There are a lot of sites that throw away the EXIF orientation tag when resizing photos. It's very obvious now that you can upload directly from the iPhone.
The concern is essentially that there may be many images on the web that have EXIF tags that don't match how those images are being used, specifically because the sites were tested in browsers that ignore the tags. So changing browser behavior now could suddenly break lots of sites that previously looked fine. It sounds like nobody has come up with a good solution yet.
It only encodes orientations that result from rotation around the axis perpendicular to the line of sight (in other words, the rotations that can be reversed by display software). Parent was asking about the orientation with camera above the subject pointing directly down. I don't think EXIF can encode that -- there's no reason to, since display software has no way to reverse it.
I don't have iPhone, but almost every phone uses same orientation for photo as for GUI to avoid confusion. Orientation for GUI is usually changed with some hysteresis and other filtering, so probably answer is "The same orientation as it was before rotating in this position".
The theory is that you have the image off the sensor, and then you have metadata about the image in the EXIF fields. The debatable point is whether orientation should be treated as metadata or is inherent to the image data. On early digital cameras, this wasn't so debatable since adding an orientation sensor was a deluxe feature that really did just add another bit of data to the photo.
I was assuming the rotation tag only expressed axis-aligned rotation, in which case lossless rotation is not that expensive compared to taking the photo in the first place.
Why should it rotate, when it can use the standard method for notating the proper rotation? Your camera would be a lot slower if it had to rotate 16MP images between snaps.
I suppose the device wouldn't bother with lossless rotation when displaying on the screen. When it comes to saving the image, it has to be lossless, which would probably take a lot more computation power.
Somebody covered this further up, but in more detail:
It is not the rotation itself that is the problem, but saving the resultant file. If you're working directly with the pixel buffer you only do a lossless JPG rotation if the image height and width are multiples of 8 (or 16, in some situations). This is because once you've performed the rotation you'll need to save the resulting output as a JPG, and unless your dimensions factor into the block size you'll need to recompute. This SO answer covers it in more detail[1].
However, if you're not working with the pixel buffer this doesn't apply. You can use jpegtran (part of libjpeg), for example, which manipulates the JPG file directly and never decodes it. Many basic image viewers and editors (like the Windows Picture Viewer, and probably the iOS Photos app but I'm not sure) don't use this approach though.
Because JPEG files don't store a value for every pixel in the image: the information is encoded very differently. By good fortune, lossless 90 and 180 degree rotations are possible for the JPEG format, but only for certain image dimensions (multiples of 8 or maybe 16, as I understand it). Some notes on what is possible can be found at http://jpegclub.org/ .
I've been looking around to see if ImageMagick could do rotation without degrading quality. (I'd also asked a question about that elsewhere in this thread.) So I assumed that most devices use something similar even for displaying on the screen. It appears I assumed wrong. :)
I saw your other comment about axis-aligned rotation not being too computationally expensive. In that case, why aren't iPhones doing it by default? Wouldn't their computation power be comparable to that of most of the cameras that rotate the images? Or are cameras better equipped to handle such transformations?
Other cameras don't usually rotate the photos (I've had to fix this same bug myself before the iPhone existed). My guess is that they didn't notice it earlier because photos from cameras are more likely to go through some post processing that on the final export saves the image with the data already rotated.
By decoding the jpeg, rotating the pixels and saving the jpeg again. I'm not even sure it makes sense to talk about lossy and losses when displaying images.
But when browsing through already stored pictures, a bit of delay is totally ok. Not so much when quickly showing some information overlaid over the picture you've just taken.
I ran into the exact same problem a few days ago. Luckily, ImageMagick, which I'm using for processing uploaded images, has an auto-orient [1] option that allows you to do this automatically.
Unfortunately, with JPEG this would cause some loss of quality, so we're probably going to have to keep the original quality image as well as the auto-orient'ed image to display on the site. Has anyone here worked on something similar? Any ideas on a better way to handle this would be extremely helpful.
Because of math, the JPEG format does support lossless rotation, as long as the dimensions of the image are multiples of 16 pixels (or 8 depending on the file). But this requires working directly with the JPEG image data, so a package like ImageMagick that reads a formatted file into a pixel buffer, then transforms it and writes it from that buffer to a new formatted file can't support the feature.
Speaking of iPhones, this blog is pretty much unreadable on Mobile Safari. I side scroll to see the text; the paragraph disappears behind the left sidebar.
Had this same issue with a service that consumes pictures from iOS/Android/BlackBerry. They all seem to handle it in different ways. I added a similar EXIF check and a quick rotation when necessary. I should have written a blog post about it. :)
This would be easier to fix in objective-c and a little custom camera wrapper application. I would expect a fix in a new OS release though. But if you need this little app let me know and I'll write it and put it on github.
If your app directly accesses the camera with AVFoundation, saving photos is a lot less automatic than you might expect. It's easy to save the raw image data but you have to generate and add just about any interesting metadata (EXIF, GPS, TIFF, etc.) explicitly. It's hard to do right--as the rather many discussions on StackOverflow suggest--and definitely a steep price to pay for a customized camera interface.
