Fix QField Camera orientation by adding user-controlled rotation + persisted setting

[kaustuvpokharel]

This PR tackles the inconsistent QtCamera photo orientation (auto-orientation / azimuth-related mismatch) by introducing a simple manual override that the user can set once and keep.

What changed

1. QML: “Phone rotate” control

• Adds a “Phone rotate” button that appears only on mobile and only when the device is not in portrait (landscape / rotated mode).
• Lets users pick the correct orientation (and preview/try alternatives).
• Persists the chosen rotation via Settings, so the app consistently applies the user’s preference on future captures.

2. C++: rotate saved image for consistency

• Applies the same selected rotation to the captured image file (pixels are rotated and orientation tags normalized) so that:

  • QML preview and external viewers match
  • EXIF orientation doesn’t cause double-rotation

Why

QtCamera / platform auto-orientation is unreliable across devices, and I can understand why qt cannot come with a rigid fix for this, as there are thousands of devices with different mechanism within it and for one universal fix. Persisting a user-selected rotation is a pragmatic fallback that prevents repeated wrong-orientation captures without forcing a single hardcoded behavior.

Issue related that could (perhaps) be fixed with this: #7005 #5820 #5224

Demo:

trim.DFE5F7DA-4005-484F-9953-545DF3ACAD8E.MOV

[qfield-fairy]

🍎 MacOS DMG universal builds

Download a MacOS DMG universal build of this PR for testing.
(Built from commit f338caf)

📱 Android builds

Download an Android arm64 build of this PR for testing.
(Built from commit f338caf)

Other Android architectures

• arm-neon
• x64
• x86
• all access arm64
• all access arm-neon
• all access x64
• all access x86

🪟 Windows builds

Download a Windows build of this PR for testing.
(Built from commit f338caf)

🐧 Linux AppImage builds

Download a Linux AppImage build of this PR for testing.
(Built from commit f338caf)

[nirvn]

@kaustuvpokharel , nice one -- can you rebase?

[mohsenD98]

Nice work @kaustuvpokharel 👍 , just 2 comment

[mohsenD98]

Okay, this line caught my attention, so I just did this test — not sure whether it's the correct behavior or not.

• Landscape mode
• I set rotation to 90°
• Preview is fine, then I capture
• The result contains an extra 90° of rotation

mohsen.mp4

[kaustuvpokharel]

This was a problem, because it seems EXIF orientation varies by device. Also, EXIF=1 means different things on different devices, so I thought it could be universal, but it varies from device to device, so now I handled it
by physically rotating the pixels and reset EXIF to 1 so it remains universal.

@mohsenD98 would you please try to build this branch again and see if videoPreview->photoPreview->and captured image are in the same orientation or not, it is good for my device, but just want to cross check just in case! Thanks for your review here.

[mohsenD98]

I’ve just tested it, @kaustuvpokharel

✔️ Photo capture works correctly now - the captured image orientation is consistent with the preview (Good job!) 👍

But Video recording currently has two issues:

1. Rotation is completely ignored. Whether the device is at 90°, 180°, or 270°, the recorded video is always saved without applying any rotation.

Screenrecorder-2026-02-14-17-05-36-319.mp4

2. On the second recording attempt, the result is not displayed at all in a strange way. I’m not fully sure whether the current PR causes this or if it’s an unrelated issue, but I wanted to mention it just in case.

Screenrecorder-2026-02-14-17-06-09-352.mp4

The result is not displayed:

[mohsenD98]

and these 2 icons are so similar, specially in small screens: