[camera] Orientation issues for the camera and the taken file

[AlexV525]

After 0.9.0 there are a lot of orientation issues have been solved, but we still got a few.

Steps to Reproduce

1. Run the example of the camera plugin.
2. Lock the Auto rotate for the device.
3. Take a new photo.
4. (Optional) Run the example of the wechat_camera_picker plugin which is more clear about what happened.

Issues

• Unable to get the orientation during the rotation if the Auto rotate is locked in the system.
• Unable to get the orientation of the captured file.
• Preview is rotated with orientations even if the device is not support for those orientations on iOS.

🔘 Unable to get the orientation during the rotation if the Auto rotate is locked in the system.

We don't have the orientation stream exposed at present. _deviceOrientationSubscription is a private StreamSubscription.

🔘 Unable to get the orientation during the rotation if the Auto rotate is locked in the system.

Below screenshots are all taken with landscape:

Capture with rotated	Capture with rotated	Preview after captured

🔘 Preview is rotated with orientations even if the device is not support for those orientations on iOS

Orientations allowed by default are [portraitUp, landscapeLeft, landscapeRight]. When we trying to make the same behavior of rotations, iOS's preview was rotated even if the orientation (here is portraitDown) is not supported to rotated to. See the video for how they behave differently.

FD063897865DD91E8103EDC1B51949F9.mp4

[AlexV525]

cc @BeMacized

[BeMacized]

cc @BeMacized

I'd love to take a further look into this, but sadly I don't think I have the hours available to do so currently.

[AlexV525]

I don't think I have the hours available to do so currently.

Take your time, there are some alternative solutions like use some other sensor plugin to integrate along with this plugin, but those are not good for nested controls.

[AlexV525]

Added a new issue about the orientation in the top comment, which is related to iOS.

[behlsoft]

camera: 0.9.3

Hey Team am facing issue in iOS only .. where user's phone auto rotation is ON/Unlocked and orientation of camera screen is set to
SystemChrome.setPreferredOrientations([
DeviceOrientation.portraitUp,
]);

in iphone now if user changes phone's orientation to landscape, camera orientation also changes ..nothing else (no other widgets). In addition to this if autorotation is locked all goes well no orientation change. When it comes to android everything seems fine no change in camera or widgets orientation in both cases ..auto-rotation locked or not

[BeMacized]

I've taken a quick look and have some thoughts:

Unable to get the orientation during the rotation if the Auto rotate is locked in the system.

Not 100% sure, but from what I understand this should be correct. Since 0.9.0, the deviceOrientation property is supposed to only reflect the UI orientation, rather than the physical orientation. As such, when auto rotate is locked, deviceOrientation should always show the same UI orientation, regardless of in which way the device is held.

Preview is rotated with orientations even if the device is not support for those orientations on iOS.

There is a bug here. It seems the preview rotation functions correctly when the orientation is locked either using the system lock, or the capture orientation lock, but fails when locking the orientation using SystemChrome.setPreferredOrientations.
From what I gather, the notifications on iOS for UIDeviceOrientationDidChangeNotification, report all orientations when using setPreferredOrientations, which is incorrect. What should happen, is that only the UI orientation is reported, like when the system orientation lock is active.
I am currently not yet sure how to fix this. From what it looks like it's not possible to query SystemChrome for its current configuration, which would maybe be usable to filter the orientations on the dart side. I'll continue to search, but if anyone has a clue, help would be appreciated.

Unable to get the orientation of the captured file.

This indeed looks incorrect. I think captures should always be rotated according to the physical orientation of the device, unless this is overridden by the capture orientation lock. I haven't looked into why this is happening yet, but I'll see if I can produce a fix for this.

[AbhishekDoshi26]

This issue has been already added: #80881 and here's the PR for the same: flutter/plugins#3970 (comment)
Just need someone to write the test cases :)

[AlexV525]

/cc @camsim99 Maybe you can take this issue? This actually makes the camera unavailable in relevant cases.

[stijnie2210]

Any news on this? I've ran into this on a project recently described in the issue above and the fact I cannot get the physical orientation on Android but I can on iOS is pretty blocking at the moment

[hassank1]

Hi! I would also like to know if there are any solutions to this problem. I am also experiencing this problem only on IOS.

[AntoineChauviere]

Any solutions or updates?
Currently I can lock the camera on android but not on iOS....

[hassank1]

You can find more up-to-date information about this issue in #111063. But no solution has been found yet.

[AntoineChauviere]

OK thanks. So currently there is no way to lock the camera to prevent it from turning in landscape mode...?

[camsim99]

/cc @camsim99 Maybe you can take this issue? This actually makes the camera unavailable in relevant cases.

In terms of Android, it seems like you can access the orientation via the CameraValue. Is there another problem with the Android camera plugin concerning this issue?

[AlexV525]

In terms of Android, it seems like you can access the orientation via the CameraValue. Is there another problem with the Android camera plugin concerning this issue?

They are all invalid in the cases I've described above, especially when the orientation lock is locked. The current behavior is not like any real-world cameras.

[camsim99]

This issue should be fixed in the CameraX implementation of the camera plugin, so please try it out!

If you find a similar issue with that implementation (or any other issues), please feel free to file a separate issue.