[image_picker] fix getting wrong png data from photo library on iOS 13+

[SDxBacon]

Description

The image_picker plugin using method requestImageDataForAsset to read the data from photo library. But, the data of a png image that retrieved from album, will always starts with byte 0xFF, which is a JPEG format but not PNG, on iOS 13+. So, the original PNG file will be turned into a JPEG image, and all the transparent parts will be lost.

After I do some tests on these code, I found that the image data will be turned into JPEG format if [options] is null or [options.version] is NOT PHImageRequestOptionsVersionOriginal. Once I call requestImageDataForAsset with [options.version] been set to PHImageRequestOptionsVersionOriginal, the image data starts with byte 0x89 as I expected. And, all the transparent parts are where it should be.

This happened on iOS 13+ device only, and will not affect iOS 12 and below. Also, the requestImageDataForAsset has been marked as duplicated on iOS 13+ document, should use requestImageDataAndOrientationForAsset instead.

Related Issues

[image_picker]Fixed losing transparency of PNGs #742

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the [Flutter Style Guide].
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
• I updated CHANGELOG.md to add a description of the change.
• I signed the [CLA].
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[SDxBacon]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to determine that you authored the commits in this PR. Maybe you used a different email address in the git commits than was used to sign the CLA? If someone else authored these commits, then please add them to this pull request and have them confirm that they're okay with them being contributed to Google. If there are co-authors, make sure they're formatted properly.

In order to pass this check, please resolve this problem and then comment@googlebot I fixed it... If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[stuartmorgan-g]

Thanks for the submission! We apologize for the long delay in triaging this PR. We’re in the process of overhauling our PR triage system to respond much more quickly, as well as working through the backlog.

This looks problematic, based on the docs for that constant:

The resulting image is originally captured or imported version of the asset, regardless of any edits made.

If the image asset contains data in multiple formats, the resulting image data uses the highest quality format. For example, for an asset containing both RAW and JPEG data, Photos returns the RAW data.

Bypassing edits, and potentially returning RAW instead of a more generally useful format, are both likely to regress existing functionality in other cases.

Please file a bug clearly describing the issue, and we can discuss and track there, and look for other solutions; I'm going to close this since it's not a change we want to move forward with.