I don't agree.
Perhaps api to get orientation changed or a common library is buggy etc. Then it is a dev team problem. Dev team must explore the problem to know where is the bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For any mode that requires Open Camera to process the image (i.e., it's not saving JPEG data direct from the camera driver), then the bitmap itself is rotated to reflect the orientation, rather than making use of the Exif orientation tag. So I don't set one - which I guess means the default is undefined (0).
Or does it matter that it's specifying an orientation of 0, as opposed to not specifying any orientation? (I note that on an image taken on my OnePlus 3T in Std mode, there appears to be no orientation reported at all by exiftool.) But this seems to be the behaviour of the Android API (either Bitmap.compress(), or ExifInterface) so I'm not sure it's feasible for me to strip out that tag.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For any mode that requires Open Camera to process the image (i.e., it's not saving JPEG data > direct from the camera driver), then the bitmap itself is rotated to reflect the orientation,
rather than making use of the Exif orientation tag. So I don't set one.
i use OC since i get a S2 Plus and then a S7. OC always set Exif orientation tag for STD, DRO modes. For HDR mode i must check this. Suddenly no more Exif orientation tag for DRO. why an Exif orientation tag for STD and no more for DRO? Why to change this ? Is it a problem?
My old Kodak camera, the S2 Plus and S7 stock camera apps set Exif orientation mode. What is the utility of not adding the Exif orientation tag? I understand you don't set it if it does not exist with you Oneplus 3T but i don't understand for the other smartphone which supply it.
Thanks
Last edit: Epistémé 2019-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What are you using the Exif orientation tag for? This tag indicates to applications that the image should have an additional rotation applied. So there are two ways to do rotation: either set the tag, or rotate the image pixels themselves.
When the image saved comes directly from the camera driver, then which of these two methods is used depends on the device.
When Open Camera creates the image (rather than the camera driver), it uses the method to rotate the image pixels themselves. I see this in other applications, e.g., if I edit an image with exif orientation in Paint.NET and then resave, the resultant image doesn't have any exif orientation, as instead the pixels have been rotated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This appears to be a side-effect of Android's ExifInterface (which I use to transfer/modify Exif tags). If I save a bitmap directly, the orientation tag isn't present. But if I use the ExifInterface to modify some tags - even though I don't set orientation to anything, it seems to put an orientation tag with undefined value, as you note.
I'll see if I can work around it by explicitly writing a "normal" (1) orientation tag to indicate no rotation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i check that in photo there is no value
exiftool -TAG -Orientation 20190804T165732.jpg
Orientation : Unknown (0)
with Samsung camera no problem
Samsung s7 G930F
android 8.0
problem is linked to HDR mode, in std mode we get orientation.
this problem occurs with my Samsung s7 and s2 plus.
DRO : same problem, no orientation.
opencamera 1.47.2
problem still there
I see this is OC in std mode but also with images captured with Moto camera (Moto G3, Android 6.0) so I don't know that it's specifically an OC issue
I don't agree.
Perhaps api to get orientation changed or a common library is buggy etc. Then it is a dev team problem. Dev team must explore the problem to know where is the bug.
For any mode that requires Open Camera to process the image (i.e., it's not saving JPEG data direct from the camera driver), then the bitmap itself is rotated to reflect the orientation, rather than making use of the Exif orientation tag. So I don't set one - which I guess means the default is undefined (0).
Or does it matter that it's specifying an orientation of 0, as opposed to not specifying any orientation? (I note that on an image taken on my OnePlus 3T in Std mode, there appears to be no orientation reported at all by exiftool.) But this seems to be the behaviour of the Android API (either Bitmap.compress(), or ExifInterface) so I'm not sure it's feasible for me to strip out that tag.
i use OC since i get a S2 Plus and then a S7. OC always set Exif orientation tag for STD, DRO modes. For HDR mode i must check this. Suddenly no more Exif orientation tag for DRO. why an Exif orientation tag for STD and no more for DRO? Why to change this ? Is it a problem?
My old Kodak camera, the S2 Plus and S7 stock camera apps set Exif orientation mode. What is the utility of not adding the Exif orientation tag? I understand you don't set it if it does not exist with you Oneplus 3T but i don't understand for the other smartphone which supply it.
Thanks
Last edit: Epistémé 2019-10-31
What are you using the Exif orientation tag for? This tag indicates to applications that the image should have an additional rotation applied. So there are two ways to do rotation: either set the tag, or rotate the image pixels themselves.
When the image saved comes directly from the camera driver, then which of these two methods is used depends on the device.
When Open Camera creates the image (rather than the camera driver), it uses the method to rotate the image pixels themselves. I see this in other applications, e.g., if I edit an image with exif orientation in Paint.NET and then resave, the resultant image doesn't have any exif orientation, as instead the pixels have been rotated.
I use openSuse linux with KDE environment.
Along the time I saw more and more apps taking care the of Exif orientation tag:
Vlc
kde dolphin
Okular
Gwenview
Digikam
Google photo.
Till recently OC adds this tag for STD and DRO. OC keeps setting this tag for STD but no more for DRO.
With Digikam i use it to rotate photo.
Thus for me it is normal a photo or video gets an Exif orientation tag.
0 is an invalid EXIF orientation value (which should be between 1 and 8) and some software will complain it. For example, img2pdf will stop working: https://gitlab.mister-muffin.de/josch/img2pdf/issues/61#note_915.
This appears to be a side-effect of Android's ExifInterface (which I use to transfer/modify Exif tags). If I save a bitmap directly, the orientation tag isn't present. But if I use the ExifInterface to modify some tags - even though I don't set orientation to anything, it seems to put an orientation tag with undefined value, as you note.
I'll see if I can work around it by explicitly writing a "normal" (1) orientation tag to indicate no rotation.
This does not seem to be completed - it is still with zero orientation tag.
I'm having the same issue.
Reported here : https://sourceforge.net/p/opencamera/tickets/737/