Status Update
Comments
ma...@gmail.com <ma...@gmail.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
ma...@gmail.com <ma...@gmail.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.
br...@gmail.com <br...@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.
br...@gmail.com <br...@gmail.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.
jo...@google.com <jo...@google.com> #6
ex...@gmail.com <ex...@gmail.com> #8
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.
tg...@google.com <tg...@google.com> #9
Branch: androidx-main
commit 161d43d41357f5d34fe7907c82ed9fca0b04d57a
Author: Laurence Muller <laurence.muller@gmail.com>
Date: Fri Dec 22 14:38:22 2023
Fix attribute reader for WebP images with Exif App1 Sections
The current attribute reader for WebP images fails to read the attributes if the Exif metadata contains an Exif App1 Section. The reason is that the byte-order is specified after the Exif App1 Section marker in the Exif payload. This patch will check if the Exif App1 section is present and correct the payload accordingly. This will allow it to read the Exif metadata (such as image orientation) correctly.
Test: Added a new image to cover this use case with a test. Run the instrument test using: ./gradlew :exifinterface:exifinterface:connectedAndroidTest
Fixes:
Change-Id: Idbb14e9fbcb038616ce650da03ed1d7eb9f997a5
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
A exifinterface/exifinterface/src/androidTest/res/raw/invalid_webp_with_jpeg_app1_marker.webp
M exifinterface/exifinterface/src/androidTest/res/values/arrays.xml
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ma...@gmail.com <ma...@gmail.com> #10
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.
uc...@google.com <uc...@google.com>
jo...@google.com <jo...@google.com> #11
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
.
ma...@gmail.com <ma...@gmail.com> #12
Branch: androidx-main
commit fd3fee5a3ef4d40a3a35a869b7bfb2399e63e814
Author: Ian Baker <ibaker@google.com>
Date: Tue Feb 20 18:16:04 2024
Add comment for test added in
Test: ExifInterfaceTest
Bug: 281638358
Change-Id: Ied3650ee5d2bf290556c86ad546c3e28bd2f8d8a
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
ma...@gmail.com <ma...@gmail.com> #13
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-alpha01
an...@supercell.com <an...@supercell.com> #14
In our case, we use separate android module/library to build cpp files. That module is not a subdirectory of the root project, but located ../../xxx/yyy location. cpp files that this module builds, are also located in multiple levels down from module root level. eg ../../xx/yy.
I think there is a bug somewhere where it resolves the paths. I'm quite sure that it would work if I create enough empty dummy directories before android studio directory, so that it would not leak out from there, or a separate empty disk image for project :)
This "scanning files bug" has been there also in 3.3 preview. I reported that here
ex...@gmail.com <ex...@gmail.com> #15
The NDK is in a subfolder of F:\Android
CPP files are in subfolders of the project's src/main/jni folder (F:\Development\AS\USBTester\USBTester\src\main\jni)
I have a zip file with a project I can send to you if you contact me privately.
jo...@google.com <jo...@google.com> #16
ar...@google.com <ar...@google.com>
np...@gmail.com <np...@gmail.com> #17
In the app.iml file, it looks like Android Studio has added C:\ as a sources root. Manually changing that to C:\programs\projectName and restarting Android Studio causes the first round of indexing to complete quickly and behave normally for a few seconds, after which it overwrites the file almost immediately with the same C:\ sources root again, after which it enters the same indexing loop forever.
tg...@google.com <tg...@google.com> #18
np...@gmail.com <np...@gmail.com> #19
There are a couple absolute paths in there. I worried that might have been causing the "C:\" sources root, but even making them relative paths (and importing from scratch again) didn't fix it.
[Deleted User] <[Deleted User]> #20
Scanning files to index was taking hours, so I left it overnight. In the morning I find the Android Studio process had read 185.35 GB from the disk and is now asking for more RAM. It either tries to read my whole disk (which is about 400 GB), or reads the same data over and over again. I'm not going to give this thing more RAM to do more of what it does now.
I never imagined that it can get any worse than Android Studio 3.2, but 3.3 is plain unusable.
an...@supercell.com <an...@supercell.com> #21
But, I discovered that creating a disk image (MacOS with Diskutility), copied project there and opened. Now the scanning phase completed. Tested with two projects that got stuck when working under home direcotry. Both worked this way.
jo...@google.com <jo...@google.com> #22
I don't have a workaround for you but this happens in the case that ndk-build is used and a target builds sources from NDK's android_app_glue along with sources in project folder. In this case, Android Studio incorrectly finds the common ancestor folder, C:\. There may be other ways to hit the bug but that's what's happening in your case.
an...@supercell.com <an...@supercell.com> #23
java.lang.Throwable: The file '/' is not under content entry root '/Applications/Android Studio.app/Contents/bin'
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:126)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertFolderUnderMe(ContentEntryImpl.java:378)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:290)
at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:285)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:209)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:216)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:202)
at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:195)
at com.android.tools.ndk.GradleWorkspace.lambda$updateContentRoots$7(GradleWorkspace.java:399)
at com.intellij.openapi.roots.ModuleRootModificationUtil.updateModel(ModuleRootModificationUtil.java:143)
at com.android.tools.ndk.GradleWorkspace.updateContentRoots(GradleWorkspace.java:374)
at com.android.tools.ndk.GradleWorkspace.lambda$null$0(GradleWorkspace.java:302)
at com.intellij.openapi.roots.impl.ProjectRootManagerImpl.mergeRootsChangesDuring(ProjectRootManagerImpl.java:295)
at com.android.tools.ndk.GradleWorkspace.lambda$null$2(GradleWorkspace.java:301)
at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java:1038)
at com.android.tools.ndk.GradleWorkspace.lambda$updateGradleWorkspace$3(GradleWorkspace.java:297)
at com.intellij.openapi.application.TransactionGuardImpl$2.run(TransactionGuardImpl.java:315)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.doRun(LaterInvocator.java:447)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.runNextEvent(LaterInvocator.java:431)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.run(LaterInvocator.java:415)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:762)
at java.awt.EventQueue.access$500(EventQueue.java:98)
at java.awt.EventQueue$3.run(EventQueue.java:715)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:732)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:817)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:758)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:394)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
74...@gmail.com <74...@gmail.com> #24
Somehow the home directory is being added as a source root:
<component name="NewModuleRootManager" LANGUAGE_LEVEL="JDK_1_7">
<output url="file://$MODULE_DIR$/build/intermediates/javac/debug/compileDebugJavaWithJavac/classes" />
<output-test url="file://$MODULE_DIR$/build/intermediates/javac/debugUnitTest/compileDebugUnitTestJavaWithJavac/classes" />
<exclude-output />
<content url="file://$USER_HOME$">
<sourceFolder url="file://$USER_HOME$" isTestSource="false" /> <------ Bad
....
Which forces the entire contents of the user's home directory to be scanned and indexed. We are using C++ libraries outside of the project's root - namely prebuilt Conan packages located in ~/.conan. Is there any workaround?
qu...@gmail.com <qu...@gmail.com> #25
But that makes that when the indexation "ends", it gets "stuck" (actually looks like is loading something, but never ends), in order to solve that I go to the Gradle pane and refresh the gradle project. When it is finally done, the indexing also ends and Android Studio allows me to build the project.
tg...@google.com <tg...@google.com>
jo...@google.com <jo...@google.com>
ma...@gmail.com <ma...@gmail.com> #26
ar...@google.com <ar...@google.com> #27
Can you provide more context around the scanning and indexing slowness you observed with 3.3.1 compared to 3.2.1?
Is it the same as
Thanks!
ro...@gmail.com <ro...@gmail.com> #28
When opening a project with a large amount of .h files (webrtc library), It takes around 10 mins in the indexing phase (long time but ok). The problem comes in the Building Symbols stage, it eats all the RAM avaiable and ends with a Low memory warning that makes the IDE unusable.
You can see in the attached screenshot where I configured the IDE to use 8Gb of RAM. If you increase the value it doesn't solve anything, it just does not stop consiming RAM until it hits the limit, no matter how high it is.
3.2 works ""ok"" (at least it doesn't freeze, but no code completion, syntax highlighting... )
Is there any workaround that could mitigate the issue?
ar...@google.com <ar...@google.com> #29
And if it's open source, where we can try to repro it ourselves, that would be even better.
[Deleted User] <[Deleted User]> #30
ro...@gmail.com <ro...@gmail.com> #31
Thanks for answering!
Our project has around 60.000 .h/.hpp files.
Unfortunately our project is not open source, however, our biggest dependency is webrtc which is.
I would say that if you create a project that depends on webrtc, you will see the same problem.
tg...@google.com <tg...@google.com> #32
Also, do you by any chance use Android Studio to open the generated gradle file in step
ho...@gmail.com <ho...@gmail.com> #33
ar...@gmail.com <ar...@gmail.com> #34
vi...@gmail.com <vi...@gmail.com> #35
Same behaviour. Same setup. OS X, c++
Found SO question that describes this as well on 4.1.
Description
There was also svn error, that said that my home folder was not in svn. Not sure if it tries to index my whole home folder now..
Everything works fast if I use experimental use active configuration only setting, but then I cant see my cpp files :(
Build: 3.3, AI-182.5107.16.33.5199772, 201812250239,
AI-182.5107.16.33.5199772, JRE 1.8.0_152-release-1248-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.14.1 unknown, screens 2560x1440; Retina
Android Gradle Plugin: 3.3.0
Gradle: 4.10.2
NDK: from local.properties: 18.1.5063045; latest from SDK: 18.1.5063045;
LLDB: LLDB 3.1 (revision: 3.1.4508709)
CMake: from local.properties: (not specified); latest from SDK: 3.6.0-rc2; from PATH: (not found);
Source: user_sentiment_feedback
IMPORTANT: Please read