Actually the image is rotated by 90 degrees clockwise.
This is an inevitable result of Android "Balkanization", IMO. There are many devices, and they are often different in implementation details.
You should create an Issue to report this, and say exactly what Samsung device you are using.
There are so many Android devices, it is impossible to keep track of the details of all of them. Of course, Zebra should be aware of the details of their own line, and assume that those differences are already accounted-for. And this problem does not exist with iOS, because it is only a small number of different devices, and they work consistently across the line. Those differences that exist are well-documented in a single place (Apple).
The obvious work-around here is to instruct the user to rotate the camera. QR is a square barcode, right? Might be some issues lining-up with other barcodes which are rectangular!
I know that you probably don't want to hear this, but I think your iOS BYOD users will be a lot happier, in general, than your Android BYOD users.
I know that those of us who use iOS only or who want iOS for our BYOD sometimes worry that Zebra/RhoMobile will someday not support iOS, or that they might give it less attention than Android. I think there is no chance of that happening, and for us there is nothing to worry about. The Android consumer device makers have taken care of that, because they cannot agree on things. If you want reliable BYOD, IMO, encourage your users toward iOS. If you distribute company devices that are non-Zebra, and are Android, then pick a specific Android device and test it.
Of course, the whole idea of BYOD is that you can't predict what your users will have in their pocket and they should be able to use what they have. The device makers have to solve this, and the best RhoMobile can do is to deal with the differences when they learn of them.
Here's perhaps some insight as to why Samsung might have done this. Bear in mind, I don't know what device specifically you are talking about, and I make very little use of Android devices.
I'll bet they decided in the interest of good photography to rotate the sensor. Traditionally, photography is done in a "landscape" orientation. And cameras have mostly been rectangular, and we hold them horizontally.
But along comes phones, which are rectangular, and which we naturally hold in our hands in a vertical orientation. I think that early on with camera phones, the makers choose the wrong orientation for the sensor. Most users do not think to rotate the camera when they take a picture, and so now many pictures are taken in "portrait" orientation, even though that is not optimal for most photos.
Witness the number of amateur videos of news events we have been seeing on TV news lately, where they duplicate and blur the left and right sides, in order to present these videos of news events in the best possible way (alas, inadequate) on televisions, which are in landscape orientation. You see this little vertical slit showing the man-on-the-street capture of the event. It's not idea, is it?
An amusing video encouraging consumers to rotate their camera when shooting videos:
I think device makers are coming around to the fact that they will not convince consumers to remember to rotate the camera. It's probably going to change slowly. When (if) Apple changes, it will be a landslide.
This creates quite a conundrum, though. If you rotate the sensor, as Samsung apparently has in this case, consumers will "automatically" take better pictures, because the photo will be in landscape when the device is in portrait. I don't know how they deal, then, with preview, it certainly would seem odd to me, but maybe they throw in enough UI controls outside of the picture area to make it seem not so strange?
Then again, it might not be an issue of real sensor orientation, because I think in most case phone sensors (as opposed to real camera sensors) are generally square, not rectangular. (They mask the image, and e.g. on iPhone now you can choose to take a square picture.)
I don't know if Android APIs have some indication of sensor orientation. That is, just because we know the orientation of the device itself, we may not know the orientation of the sensor. A specific device might have a different sensor orientation. They certainly should have an indication, and if so, then the Rhodes Camera API ought to take that into account. Does anyone know: is there, and does it?
And that's my "deep thought" of the day, LOL.
I could have summed it up like this: it's a mess!
What specific Samsung device? Android version is useful to know as well.
I did some searches, and there seem to be issues unrelated to the above, which is just speculation on my part, and probably wrong. The reliable way to check image orientation is to look at the EXIF data in the image. I don't know if the barcode software in Rhodes does that?
That video is great !
The device was a Samsung S4.
Thank you for these responses. If it was just a case of switching the phone around to scan the barcode that'd be fine. But it actually adjusts the image so it is hard to even line up the barcode. E.g. say you are pointing your phone at a barcode and on the screen you are too far up, you actually have to move the phone to the left. I hope this makes sense its a real mind bending problem !
Real view View through camera
| | | |
| | | |
| | |______________|
I'd suggest starting an Issue on this, then, and mention specifically you're using a Samsung S4.
I don't use barcode scanning myself, though we do use photos. We did have a similar kind of issues, because we sketch over photos. For us, it is not an issue in the app, because the browser uses the metadata in the image to show it in correct orientation.
But we had a problem initially when we sent the pictures and the overlay sketch to a server, and the server was expected to create a nice PDF report. The pictures were sideways!
We had to write some code on the server to read the image metadata and see what orientation the picture is in.
Perhaps the Rhodes barcode software needs to do the same (look at the metadata).
File an Issue here:
It would be useful to reference this post.