Umm, is that the screenshot you intended to upload?

Urgh. No.

Deleted: Screenshot_20171127-101336.png 3.5 MB

	Screenshot_20171127-101336.png 3.5 MB View Download

Would you mind sending me a private message with one picture each (one that is correctly rotated and one that is not)?

Just about to hop on a flight to Bangalore. Will send asap.

If this turns out to be a bug that will affect a large number of images we may want to halt the finch rollout and fix it before rolling back out, but if it turns out to be very rare or limited to specific devices it may be fine to proceed.

Looking forward to hearing what we learn here

The bug reproduces with the image provided (thanks Paul!).

The problem is that the Picker is not respecting the Exif information, which specifies that the picture should be rotated 90 degrees. 

Interestingly, the Downloads UI in Android also does not respect the Exif information.

This bug is limited to the display of the image on screen, once you upload, the picture should appear correctly (assuming the receiving end handles the Exif information correctly).

And finally, the fix is easy, but the API to read the Exif information is only available in Android version N and.

Just to confirm - what was the behavior with the old intent picker for this image? Was it rendered correctly, or also sideways?

Fixing this seems like a total no-brainer, it's just good to know if to users this is effectively a regression or not.

The stock Android picker UI correctly rotates the image (even though the Android downloads UI does not).

Fix in review:
https://chromium-review.googlesource.com/c/chromium/src/+/808504

One correction:

> the API to read the Exif information is only available in Android 
> version N and.

That should have read "N *and up*", obviously. But also: The story for M and below is more complex. There is a support library but it doesn't handle FileDescriptors, which is what we use, and trying to shoehorn that in would probably add both complexity and slowness.

Just to confirm, this means that in the typical case where I take a landscape photo with my device the image will be rendered incorrectly? i.e. this isn't a rare edge case, it's applicable for most landscape photos?

If so, since ~80% of devices are running pre-N I think we will also need a solution for them :/

I'm not an Exif expert, but I don't think that's the typical case, no. For example, it doesn't matter how I rotate my Nexus 6 device, it does not add the Exif rotate directive. Given that I never saw this problem on my 6P I think it is not an issue there either. 

If you want to experiment with your phone, you can look at Exif tags with something like metapicz.com (look for the word Orientation after uploading). There's also an app called Photo Exif Editor on Android that shows you the orientation.

My guess is that Exif orientation is only added on newer models of phones, but like I said -- I'm not an expert.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/86eea866ea298b67dc47bdb84f8a7821a5d12882

commit 86eea866ea298b67dc47bdb84f8a7821a5d12882
Author: Finnur Thorarinsson <finnur@chromium.org>
Date: Tue Dec 05 16:49:00 2017

Android Photo Picker: Respect Exif rotation.

Bug:  789067 ,  656015 
Change-Id: Ie4201d0b9db4add3321917c31b18152b5b441411
Reviewed-on: https://chromium-review.googlesource.com/808504
Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Finnur Thorarinsson <finnur@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521718}
[modify] https://crrev.com/86eea866ea298b67dc47bdb84f8a7821a5d12882/chrome/android/java/src/org/chromium/chrome/browser/photo_picker/BitmapUtils.java

Could we add UMA to rotateAndCropToSquare() to record how often it's got a non-default value? That would allow us to get a good understanding of how severe this problem is as we can probably (and roughly) extrapolate the results to pre-N as well.

Sounds reasonable - if based on our current knowledge we don't think this is a common issue, and we can add UMA for it, then it seems good to land the easy fix for N+ and collect data and then look at more complex solutions in the future if it proves to be more common than we thought.

One misc note is that if we do end up needing to handle it on pre-N it's probably worth having a quick chat with the Android team to learn if there's any easy(ish) solution that we aren't aware of.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ee6c5884d8d5664902fa1e7b97a5544a85af69c

commit 9ee6c5884d8d5664902fa1e7b97a5544a85af69c
Author: Finnur Thorarinsson <finnur@chromium.org>
Date: Mon Dec 11 19:12:58 2017

Android Photo Picker: Add UMA for Exif rotation.

And finish the rest of the permutations, since they're easy
to implement...

Bug:  789067 ,  656015 
Change-Id: I32893ff6ce2ef1d0221abc117a42a09e8ee7b136
Reviewed-on: https://chromium-review.googlesource.com/813916
Reviewed-by: Gayane Petrosyan <gayane@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Finnur Thorarinsson <finnur@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523157}
[modify] https://crrev.com/9ee6c5884d8d5664902fa1e7b97a5544a85af69c/chrome/android/java/src/org/chromium/chrome/browser/photo_picker/BitmapUtils.java
[modify] https://crrev.com/9ee6c5884d8d5664902fa1e7b97a5544a85af69c/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/9ee6c5884d8d5664902fa1e7b97a5544a85af69c/tools/metrics/histograms/histograms.xml

Fixed for N and above. Also added UMA so we can make a determination of whether more is required.