Snapshot and MJPEG are different orientations
Need an option in occo 4A to rotate the video stream and the snapshot separately, as they get sent to OctoPrint in different orientations and this messes with OctoApp data saver cam as it uses the orientation from OctoPrint to orient the snapshot. I am sure this messes up other plugins and things too, this is just the first I noticed.
Just to illustrate the issue:

A temporary fix for this is to disable auto rotation in android settings.
My fix was disabling the webcam server within Octo4a and installing the IP Webcam app from the Play Store and plugging in the new camera addresses into the Octoprint webcam settings (http://192.168.0.240:8080/video) and octolapse profiles (http://192.168.0.240:8080/photo.jpg).
The web app gives manual control of focus and exposure as well so it helps with the overall quality too.
Hey! I'm the developer of OctoEverywhere, and I'm seeing this bug hit quite a lot due to my use of both the webcam stream and the snapshot. The issue is that the user is setting the rotation, so the stream looks correct in OctoPrint, but then when using the snapshot on my dashboard and such, the image is rotated incorrectly.
I think the fix is actually quite simple, it looks like the rotation gets applied to the stream here: https://github.com/feelfreelinux/octo4a/blob/85ff29b3cc492eaf1706e0ae88c8f9eb71815923/app/app/src/main/java/com/octo4a/camera/CameraService.kt#L252
but not to the snapshot here: https://github.com/feelfreelinux/octo4a/blob/85ff29b3cc492eaf1706e0ae88c8f9eb71815923/app/app/src/main/java/com/octo4a/camera/CameraService.kt#L115
Is there anyway someone could find a minute to take a quick look at this?
Will check on the weekend. If it's really only this line I can make a PR.
@QuinnDamerell you were almost right, but the bytes for the snapshot are already a JPEG, so you need to rotate that differently. There seems to be also some black magic going on with the original JPEG having Exif Metadata set specifying the rotation, this is now also removed as a side effect of re-encoding the JPEG.
@crysxd amazing! Thanks for looking and adding a fix! The byte format was the only thing I didn’t double check, I was wondering if it wasn’t the same format.
This will be an amazing fix for my community and for OctoLapse, since it will face the same issue!
OctoApp wasn't spared :D
@feelfreelinux I’m sure your a really busy, so I would love to know if there’s anything we can do to help you test, merge, and release this bug fix! I think it will be super impactful to your community, since it will help OctoEveywhere, OctoLapse, OctoApp, and I’m sure many other top plug-ins and OctoPrint apps.
If there’s anything we can do, please let us know!
(Or possibly @alufers if you have access to merge and release, same offer!)
Amazing thanks @alufers!