Status Update
Comments
cc...@google.com <cc...@google.com> #2
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.
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
ra...@google.com <ra...@google.com> #3
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.
lo...@gmail.com <lo...@gmail.com> #4
Will anyone please take a look at this bug? It appears on many, very common devices and results in mis-rotated images.
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #5
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.
Description
Component used: Version used: Latest (1.3.0-alpha04) Devices/Android versions reproduced on: all devices
TL;DR
Macrobenchmark tests fails with
IllegalArgumentException: At least one result is necessary
when usingFrameTimingMetric
together with tooling that adds trace sections to the root of the main thread section stacks. See attached screenshot for an example of what that might look like.Details
FrameTimingQuery
(Unfortunately, this assumption is broken when 3rd party code inserts additional sections to the top of the main thread section stack.
For example, the papa library adds a top trace section to every running main thread section ( source ), leveraging the logged name provided through
Looper.getMainLooper().setMessageLogging()
(see screenshot for what that looks like).Side note 1: I'm aware that
Looper.getMainLooper().setMessageLogging()
wasn't exactly designed for this purpose, but having toString() details for all messages that run on the main thread is incredibly useful to help understand perfetto traces. Ideally there would be a dedicated API to help understand what runs on main.Side note2: if anyone using papa runs into this issue, you can disable the additional tracing with a boolean resource override for
R.bool.papa_trace_main_thread
. Unfortunately that will make your perfetto traces a lot less easy to investigate.