4 ms·

"My images are all upside down"

38 points by digitalpbk 14y ago

cyriacthomas 14y ago
What is the case when the photos are taken from a vertically up position? What orientation does it take? For eg: https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-ash3/543929_10151252345763985_905957976_n.jpg https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-ash3/54392... Just curious. I'm sure many food photographers will try that position too.
- anonymfus 14y ago
  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".
- micampe 14y ago
  The EXIF orientation tag encodes all orientations: http://www.impulseadventure.com/photo/exif-orientation.html http://www.impulseadventure.com/photo/exif-orientation.html
  - brasic 14y ago
    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.
    - micampe 14y ago
      Well, photographs are two dimensional.
smackfu 14y ago
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.
rem1313 14y ago
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?
- freehunter 14y ago
  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.
- smackfu 14y ago
  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.
micampe 14y ago
“Because your crop and scale function ignores and drops the EXIF orientation tag.”
jstanley 14y ago
What the hell? Why is there an orientation tag at all? Why isn't the picture just rotated by the device that takes it?
- micampe 14y ago
  Because lossless rotation is fairly expensive computationally so digital cameras have been leaving that job to a computer.
  - jonknee 14y ago
    In this case the camera is a computer though. A computer that knows its orientation.
    - CountHackulus 14y ago
      Not to mention that it's rotating by +-90 or 180 degrees, which is a whole lot faster than an arbitrary rotation.
  - jstanley 14y ago
    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.
- gfosco 14y ago
  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.
  - smackfu 14y ago
    OTOH, it has to rotate it for display on the screen, so it can't be that computationally bad.
    - 14y ago
gfosco 14y ago
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. :)
nextstep 14y ago
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.
- vilgax 14y ago
  Showing up correctly on Mobile Safari on iPad.
ianstallings 14y ago
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.
- 5teev 14y ago
  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.
  - ianstallings 14y ago
    It's not that hard actually, it's just tedious. The easiest way to do it is use the CIImageProperties (http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/CGImageProperties_Reference/Reference/reference.html http://developer.apple.com/library/mac/#documentation/Graphi...) The better way though is to use a class like this: https://github.com/gpambrozio/GusUtils/blob/master/GusUtils/NSMutableDictionary+ImageMetadata.m https://github.com/gpambrozio/GusUtils/blob/master/GusUtils/... I see your point though - it's not trivial. I just happen to have a lot of experience in this area. I do a lot of video/imaging on the iphone.
route3 14y ago
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. [0] http://exif.in http://exif.in
- edent 14y ago
  Really useful! Thanks. Have you seen http://regex.info/exif.cgi http://regex.info/exif.cgi
nithinbekal 14y ago
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. [1] http://www.imagemagick.org/script/command-line-options.php#auto-orient http://www.imagemagick.org/script/command-line-options.php#a...
- smackfu 14y ago
  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.
- deleted 14y ago
  [deleted]
Steuard 14y ago
There's a lot of discussion of what's behind this issue in the Mozilla feature request at https://bugzilla.mozilla.org/show_bug.cgi?id=298619 https://bugzilla.mozilla.org/show_bug.cgi?id=298619, and more at the corresponding webkit (https://bugs.webkit.org/show_bug.cgi?id=19688 https://bugs.webkit.org/show_bug.cgi?id=19688) and chromium (http://code.google.com/p/chromium/issues/detail?id=56845 http://code.google.com/p/chromium/issues/detail?id=56845) bug trackers. 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.

38 points by digitalpbk 14y ago

What is the case when the photos are taken from a vertically up position? What orientation does it take? For eg: https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-ash3/543929_10151252345763985_905957976_n.jpg https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-ash3/54392... Just curious. I'm sure many food photographers will try that position too.

anonymfus 14y ago
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".
micampe 14y ago
The EXIF orientation tag encodes all orientations: http://www.impulseadventure.com/photo/exif-orientation.html http://www.impulseadventure.com/photo/exif-orientation.html
- brasic 14y ago
  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.
  - micampe 14y ago
    Well, photographs are two dimensional.

smackfu 14y ago

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.

rem1313 14y ago

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?

freehunter 14y ago
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.
smackfu 14y ago
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.

micampe 14y ago

“Because your crop and scale function ignores and drops the EXIF orientation tag.”

jstanley 14y ago

What the hell? Why is there an orientation tag at all? Why isn't the picture just rotated by the device that takes it?

micampe 14y ago
Because lossless rotation is fairly expensive computationally so digital cameras have been leaving that job to a computer.
- jonknee 14y ago
  In this case the camera is a computer though. A computer that knows its orientation.
  - CountHackulus 14y ago
    Not to mention that it's rotating by +-90 or 180 degrees, which is a whole lot faster than an arbitrary rotation.
- jstanley 14y ago
  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.
gfosco 14y ago
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.
- smackfu 14y ago
  OTOH, it has to rotate it for display on the screen, so it can't be that computationally bad.
  - 14y ago

gfosco 14y ago

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. :)

nextstep 14y ago

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.

vilgax 14y ago
Showing up correctly on Mobile Safari on iPad.

ianstallings 14y ago

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.

5teev 14y ago
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.
- ianstallings 14y ago
  It's not that hard actually, it's just tedious. The easiest way to do it is use the CIImageProperties (http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/CGImageProperties_Reference/Reference/reference.html http://developer.apple.com/library/mac/#documentation/Graphi...) The better way though is to use a class like this: https://github.com/gpambrozio/GusUtils/blob/master/GusUtils/NSMutableDictionary+ImageMetadata.m https://github.com/gpambrozio/GusUtils/blob/master/GusUtils/... I see your point though - it's not trivial. I just happen to have a lot of experience in this area. I do a lot of video/imaging on the iphone.

route3 14y ago

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. [0] http://exif.in http://exif.in

edent 14y ago
Really useful! Thanks. Have you seen http://regex.info/exif.cgi http://regex.info/exif.cgi

nithinbekal 14y ago

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. [1] http://www.imagemagick.org/script/command-line-options.php#auto-orient http://www.imagemagick.org/script/command-line-options.php#a...

smackfu 14y ago
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.
deleted 14y ago
[deleted]

Steuard 14y ago

There's a lot of discussion of what's behind this issue in the Mozilla feature request at https://bugzilla.mozilla.org/show_bug.cgi?id=298619 https://bugzilla.mozilla.org/show_bug.cgi?id=298619, and more at the corresponding webkit (https://bugs.webkit.org/show_bug.cgi?id=19688 https://bugs.webkit.org/show_bug.cgi?id=19688) and chromium (http://code.google.com/p/chromium/issues/detail?id=56845 http://code.google.com/p/chromium/issues/detail?id=56845) bug trackers. 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.