Status Update
Comments
ti...@google.com <ti...@google.com>
ib...@google.com <ib...@google.com> #2
Branch: androidx-main
commit 81120ca77c09c437775232585652b293ed572d45
Author: Clara Fok <clarafok@google.com>
Date: Thu Feb 29 17:29:44 2024
Paging to use common MainThread annotation
Test: ANDROIDX_PROJECTS=INFRAROGUE ./gradlew paging:paging-common:allTest
Bug: 327682438
Change-Id: I78f0d3cf36e3a3a9088e0698c351289cf2dbc1bf
M paging/paging-common/build.gradle
D paging/paging-common/src/commonJvmAndroidMain/kotlin/androidx/paging/MainThread.jvm.kt
D paging/paging-common/src/commonMain/kotlin/androidx/paging/MainThread.kt
M paging/paging-common/src/commonMain/kotlin/androidx/paging/PagingDataPresenter.kt
ma...@gmail.com <ma...@gmail.com> #3
Fixed internally and available in paging-3.3.0-alpha05
ib...@google.com <ib...@google.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.paging:paging-common:3.3.0-alpha05
androidx.paging:paging-common-android:3.3.0-alpha05
androidx.paging:paging-common-iosarm64:3.3.0-alpha05
androidx.paging:paging-common-iossimulatorarm64:3.3.0-alpha05
androidx.paging:paging-common-iosx64:3.3.0-alpha05
androidx.paging:paging-common-jvm:3.3.0-alpha05
androidx.paging:paging-common-linuxx64:3.3.0-alpha05
androidx.paging:paging-common-macosarm64:3.3.0-alpha05
androidx.paging:paging-common-macosx64:3.3.0-alpha05
ma...@gmail.com <ma...@gmail.com> #5
Please also take into account values larger than 1. I think the exposure time might be for example 1,5 second or 15 seconds.
ma...@gmail.com <ma...@gmail.com> #6
ib...@google.com <ib...@google.com> #7
it would be useful to have an API with which one could copy all EXIF data directly from one file to another
This request is tracked by
ib...@google.com <ib...@google.com> #8
There's another curiosity here: Some 'unsigned rational' tags are returned from getAttribute(String)
in the form "x/y"
, e.g. TAG_FOCAL_LENGTH
. I dug a bit into this, and I think the 'automatically convert to floating point' behaviour was originally introduced in the framework version of ExifInterface
(which existed before the AndroidX one was forked from it) as part of
Given the constraint of maintaining this lossy format going forward:
ExifInterface
already has 'different type' getAttributeXXX(...)
'overloads' like getAttributeInt(...)
. Given these already exist, we could consider adding add a @Nullable String getAttributeRational(String)
that returns the "x/y"
format for tags with TYPE = (Unsigned) rational
. People would have to know to use it instead of getAttribute(String)
, but it at least gives 'lossless' access to the actual tag data read from the file - even for rational tags that are converted to lossy decimal/floating-point representations for backwards-compatibility..
ib...@google.com <ib...@google.com>
ap...@google.com <ap...@google.com> #9
Branch: androidx-main
commit e497a91fac8b9826b122ccc1b012c8dd58fc1269
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 02 14:02:28 2024
Tighten floating point assertions in ExifInterfaceTest
As part of addressing
ExifInterface converts floating point strings to rational
representations. In order to add a test for this (that fails without
the fix) I need to first tighten the precision of the existing floating
point assertions in the test.
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Id15b4beebfe504a2e8e6a76725ed871fc41921ac
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExpectedAttributes.java
ap...@google.com <ap...@google.com> #10
Branch: androidx-main
commit 13cb54333c5e3202da0e2cdb566f0810fd217ae1
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:16:37 2024
Accept rationals (x/y) for attrs with legacy handling in ExifInterface
Some attributes declared/documented as type = Rational have special
handling for backwards compatibility that results in their values being
returned as decimals instead. Previous to this change, only decimal
values were accepted too, but we can accept both decimal and rational
forms without breaking backwards compatibility.
See more context about the backwards compat in this internal code review
comment from 2016:
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ie282c1f8a23297f51a31b04c290284124eb870f9
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ap...@google.com <ap...@google.com> #11
Branch: androidx-main
commit c23003716636d5c161e9b8c5d139ebbde0b7c8b5
Author: Ian Baker <ibaker@google.com>
Date: Wed Apr 10 17:03:20 2024
Split GPS_TIMESTAMP handling from the rest of the backwards compat rational tags
This tag has different special handling to the rest in this set, so it
doesn't really make sense to include it here.
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ibec7f06d8cfe2c7cd1edf029e32b002ce8e2e22b
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ap...@google.com <ap...@google.com> #12
Branch: androidx-main
commit 34755e56581a1d2b474c2e556eab6b7c587aa116
Author: Ian Baker <ibaker@google.com>
Date: Wed Apr 03 14:10:27 2024
Improve precision of ExifInterface double -> rational conversion
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Iafd9736aab51fc627a7f25a11b9384b5008fb9bf
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit 67282b9c5804e5b8bb28993e57940b322b963988
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:30:03 2024
Document ExifInterface 'rational' attributes returned as decimals
These specific attributes have special handling, for backwards
compatibility with the implementation of ExifInterface that preceded the
platform android.media.ExifInterface. See more context in this
internal code review comment from 2016:
Also add tests for this handling, including the current behaviour of
rejecting/ignoring the 'correct' rational format when passed to
setAttribute(String, String). A follow-up change adds support for this
format (and updates these tests to reflect this).
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ia09c2956f0f80279108ccf872174eb98214a38a8
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ib...@google.com <ib...@google.com>
na...@google.com <na...@google.com> #14
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-alpha01
Description
Version used: 1.3.6
Devices/Android versions reproduced on: ALL
Steps to reproduce:
1. Create ExifInterface for an image file
2. Set time exposure attribute to value 0.000625 which corresponds to time exposure value of 1/1600
3. Save attributes to image file
Actual outcome:
- When reading exposure time value from that file the value is 0.0006, so it is truncated. This results in exposure time changed from 1/1600 to 1/1666.
Expected outcome:
- The exposure time value should be 0.000625 which corresponds to the expected exposure time value of 1/1600.
Reproducibility:
It seems to occur on all devices and all image files/formats. Likely the problem is that the double value is converted to rational value which has limited precision.