jnm
September 2, 2021, 3:36am
20
Of course not.
Thankfully, someone else has opened an issue for this in the appropriate repository (ODK Collect) and even submitted a pull request to fix it:
getodk:master
← abhishekab:4571-fix-exif
opened 10:09PM - 01 Jul 21 UTC
- Remove rotation methods from ImageConvertor
(Don't apply explicit rotation … if EXIF rotation present)
- Copy image after applying EXIF rotation for Annotate Widget
- Remove ImageConvertor rotate tests
- Add FileUtils rotate tests
Closes #4571
<!--
Thank you for contributing to ODK Collect!
Before sending this PR, please read
https://github.com/getodk/collect/blob/master/CONTRIBUTING.md
-->
#### What has been done to verify that this works as intended?
Manual Testing done. And unit tests added
#### Why is this the best possible solution? Were any other approaches considered?
There were two main approaches to solve this:
- Remove the explicit bitmap transformation which rotates the image, and preserve EXIF orientation. And make the ImageView displaying the image in ImageWidget sensitive to EXIF just for presentation.
- Let the explicit bitmap transformation as it is and let it rotate the image, and at the same time remove the orientation from EXIF before saving the transformed image.
Got inclined toward the former one, as using EXIF as it's supposed to be used and not rewriting the image seemed more apt.
#### How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
N/A
#### Do we need any specific form for testing your changes? If so, please attach one.
N/A
#### Does this change require updates to documentation? If so, please file an issue [here]( https://github.com/getodk/docs/issues/new) and include the link below.
N/A
#### Before submitting this PR, please make sure you have:
- [x] run `./gradlew checkAll` and confirmed all checks still pass OR confirm CircleCI build passes and run `./gradlew connectedDebugAndroidTest` locally.
- [x] verified that any code or assets from external sources are properly credited in comments and/or in the [about file](https://github.com/getodk/collect/blob/master/collect_app/src/main/assets/open_source_licenses.html).
- [x] verified that any new UI elements use theme colors. [UI Components Style guidelines](https://github.com/getodk/collect/blob/master/CONTRIBUTING.md#ui-components-style-guidelines)
Once that is merged and included in a release of ODK Collect, hopefully the problem will go away. KoBoCollect is maintained by the same folks as ODK Collect, but its releases sometimes come slightly afterwards. If you are keen to get the fix as quickly as possible, there are no disadvantages to using ODK Collect with KoBoToolbox.
1 Like