views:

494

answers:

1

Hi there, Our app uses the gallery pick action to grab an image from the device to upload to a new blog post. We're seeing on the Moto Droid that images taken in portrait are being sent back to the app in landscape orientation so the image is sideways. AFAIK this only occurs on the Droid.

Found this via google, but we need the full size image to be uploaded in the correct orientation so the solution doesn't work for us:

http://groups.google.com/group/android-developers/browse_frm/thread/1246475fd4c3fdb6?pli=1

An easy way to reproduce this is to take a picture in portrait on the Droid, then send it to yourself via Gmail. In the email message, the image will be in landscape (sideways). I've tested on the droid 2.1 update and the issue is still there.

Here's some more info:

I took a peek at the image info in photoshop, and it has this line:

<tiff:Orientation>1</tiff:Orientation>

This spec (http://www.awaresystems.be/imaging/tiff/tifftags/orientation.html) says that the value of 1 is:

1 = The 0th row represents the visual top of the image, and the 0th column represents the visual left-hand side.

In this case, isn't that incorrect? The top of the image in my case is the right side, with the 0th row being the left side, which I think should be a value of '5' for the tiff orientation.

+1  A: 

I think this may be a bug in your server code with EXIF tags. On my Droid with 2.1, I took a picture in portrait mode, as you mentioned, and investigated the saved result (emailed to myself, for example). When opening up the file in Preview (on a Mac), it looks correct.

With the handy exif tool (port install exif on Mac), I was able to print the EXIF info:

$ exif -t Orientation image.jpg 
EXIF entry 'Orientation' (0x112, 'Orientation') exists in IFD '0':
Tag: 0x112 ('Orientation')
  Format: 3 ('Short')
  Components: 1
  Size: 2
  Value: right - top

Now, if you were to erase the EXIF information, which is what might be happening in your server/client communication:

$ exif --ifd=0 --tag=Orientation --set-value= -o image2.jpg image.jpg 
Wrote file 'image2.jpg'.

$ exif -t Orientation image2.jpg 
EXIF entry 'Orientation' (0x112, 'Orientation') exists in IFD '0':
Tag: 0x112 ('Orientation')
  Format: 3 ('Short')
  Components: 1
  Size: 2
  Value: 

The resulting image will be in landscape mode.

So, the bottom line is that I think Droid is storing the bits in the image always in landscape and relying on EXIF metadata to store rotation information (which is perfectly valid), and your app may be discarding this information.

Hope that helps! Feel free to comment or edit the original question to further troubleshoot.

Roman Nurik
thank, added more info above
roundhill
I also just looked at the file info for an image taken in landscape, and it has the same orientation value of '1'. I think that's the issue!
roundhill
I'm seeing the same thing. I have server-side code that auto-rotates the image based on the EXIF Orientation flag, and the problem is that the Bitmap is losing all EXIF data between the point of saving it from the Camera app, and uploading it to the server. Part of that process involves using BitmapFactory to down-sample the image, since I don't need the full image. Just need to find out how to preserve that EXIF data. Will post back if I find something.
Joe