IssueTracker

Looking at the exiftool data, it reports Orientation = 6, which is rotated 90 degrees counter-clockwise and needs 90 degrees clockwise rotation to appear correct. Of course, it's unusual that a Google format would be correct in exiftool and not in Google's own ExifInterface library. I see it's also not handling the rotation as I would expect in Chrome.

https://sirv.sirv.com/website/exif-orientation-values.jpg?scale.option=fill&scale.width=512&scale.height=252

exiftool -V ~/Downloads/676x380.webp       
  ExifToolVersion = 12.60
  FileName = 676x380.webp               Dog\ Yule\ Log.mp4                      Lil\ Bub\ Video\ Yule\ Log.mp4          android-studio-2022.2.1.19-mac_arm.dmg  gradle.properties                       simpsons_background.png                 
  Directory = /Users/clee/Downloads
  FileSize = 116812
  FileModifyDate = 1683650274
  FileAccessDate = 1683655195
  FileInodeChangeDate = 1683654924
  FilePermissions = 33188
  FileType = WEBP
  FileTypeExtension = WEBP
  MIMEType = image/webp
  FileType [override] = Extended WEBP
  FileTypeExtension [override] = WEBP
RIFF 'VP8X' chunk (10 bytes of data):
  VP8X (SubDirectory) -->
  + [BinaryData directory, 10 bytes]
  | WebP_Flags = 8
  | ImageWidth = 2063598243
  | ImageHeight = 97024
RIFF 'VP8 ' chunk (53444 bytes of data):
  VP8Bitstream (SubDirectory) -->
  + [BinaryData directory, 53444 bytes]
  | VP8Version = 0
  | ImageWidth = 676
  | HorizontalScale = 0
  | ImageHeight = 380
  | VerticalScale = 0
RIFF 'EXIF' chunk (63321 bytes of data):
  Warning = [minor] Improper EXIF header
  EXIF (SubDirectory) -->
  + [TIFF directory]
  | ExifByteOrder = II
  | + [IFD0 directory with 12 entries]
  | | 0)  ImageWidth = 4000
  | | 1)  ImageHeight = 3000
  | | 2)  Make = samsung
  | | 3)  Model = SM-S908U1
  | | 4)  Orientation = 6
  | | 5)  XResolution = 72 (72/1)
  | | 6)  YResolution = 72 (72/1)
  | | 7)  ResolutionUnit = 2
  | | 8)  Software = S908U1UES2CWCC
  | | 9)  ModifyDate = 2023:04:22 09:15:37
  | | 10) YCbCrPositioning = 1
  | | 11) ExifOffset (SubDirectory) -->
  | | + [ExifIFD directory with 30 entries]
  | | | 0)  ExposureTime = 0.03333333333 (1/30)
  | | | 1)  FNumber = 2.2 (220/100)
  | | | 2)  ExposureProgram = 2
  | | | 3)  ISO = 400
  | | | 4)  ExifVersion = 0220
  | | | 5)  DateTimeOriginal = 2023:04:22 09:15:37
  | | | 6)  CreateDate = 2023:04:22 09:15:37
  | | | 7)  OffsetTime = -05:00
  | | | 8)  OffsetTimeOriginal = -05:00
  | | | 9)  ShutterSpeedValue = 0.03333333333 (1/30)
  | | | 10) ApertureValue = 2.27 (227/100)
  | | | 11) BrightnessValue = 0.21 (21/100)
  | | | 12) ExposureCompensation = 0 (0/100)
  | | | 13) MaxApertureValue = 2.27 (227/100)
  | | | 14) MeteringMode = 2
  | | | 15) Flash = 0
  | | | 16) FocalLength = 2.2 (220/100)
  | | | 17) SubSecTime = 960
  | | | 18) SubSecTimeOriginal = 960
  | | | 19) SubSecTimeDigitized = 960
  | | | 20) FlashpixVersion = 0100
  | | | 21) ColorSpace = 1
  | | | 22) ExifImageWidth = 676
  | | | 23) ExifImageHeight = 380
  | | | 24) ExposureMode = 0
  | | | 25) WhiteBalance = 0
  | | | 26) DigitalZoomRatio = 1 (100/100)
  | | | 27) FocalLengthIn35mmFormat = 13
  | | | 28) SceneCaptureType = 0
  | | | 29) ImageUniqueID = DA8XLOD01SM
  | + [IFD1 directory with 8 entries]
  | | 0)  ImageWidth = 512
  | | 1)  ImageHeight = 384
  | | 2)  Compression = 6
  | | 3)  XResolution = 72 (72/1)
  | | 4)  YResolution = 72 (72/1)
  | | 5)  ResolutionUnit = 2
  | | 6)  ThumbnailOffset = 852
  | | 7)  ThumbnailLength = 62463

For context, I found this because I got a bug report about a similar issue with an upside down photo on a Samsung Galaxy S10 and managed to reproduce the problem as a sideways WEBP on an S22 Ultra. I can supply more pictures from different Samsung models exhibiting this same problem if that would be useful.

Will anyone please take a look at this bug? It appears on many, very common devices and results in mis-rotated images.

Hi,

I can confirm there is an issue with the WebP exif reading implementation. I ran into the same issue when retrieving WebP images from the Amazon's Serverless Image Handler. Initially I thought it was a bug in the library I'm using (Coil) but found out it wasn't the case.

I have a bugfix available for the issue and am preparing a PR (that will be submitted via Gerrit).

Validated with my own images (a yellow sticky note captured at all 4 orientations) + the one from the google repo + the one from the topic starter.

Note: The bottom left image is a google webp without exif, the bottom right image is a google webp with exif

Note 2: It's also broken in Chrome & Firefox but works correctly on Safari/Finder on MacOS. I might submit bugfixes for those too.

PR here: https://android-review.googlesource.com/c/platform/frameworks/support/+/2889627

Thanks for the detailed investigation! I've replied on the PR with more details - but I'm not sure this image is a valid WebP.

Hi, since this issue is now fixed in the codebase, is there any timeline on when this will be rolled out via a minor update (e.g v1.3.8)?

Would love to be able to use Exifinterface without having to use local workarounds in my apps.

This will be included in 1.4.0, likely released sometime in Q2 - I'm afraid we won't be doing a 1.3.8 release as the current exifinterface release branch is too old and we need to snap it to a more recent version from androidx-main.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.exifinterface:exifinterface:1.4.0-alpha01

I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.

The solution has been merged in https://android-review.googlesource.com/1545624. Update the status to be fixed.