-
Notifications
You must be signed in to change notification settings - Fork 495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CB-13683: (android) cordova-plugin-media-capture rotates pictures with some devices #100
base: master
Are you sure you want to change the base?
Conversation
src/android/Capture.java
Outdated
|
||
private Uri fromBitmapToUri(Context context, Bitmap inImage) { | ||
ByteArrayOutputStream bytes = new ByteArrayOutputStream(); | ||
inImage.compress(Bitmap.CompressFormat.JPEG, 85, bytes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hardcoded quality? Is this smart?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know there's no param in this plugin to set a specific image quality for the standard image capture. If we add a param to set quality it should work for standard images and rotated images, but this was not related to the issue. Anyway I agree, it's not smart, what would you suggest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally the plugin doesn't really touch the image, right?
But if it was rotated, the result is uncompressed and has to be compressed to get to a similar size than what was returned by the device, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we just set it to 100
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an option, sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
85 seems a bit random. 100 is still hard-coded, but at least it won't interfere with the quality wanted - they can always change the quality later.
Is that what we'll go with then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, the compression is now 100 abed367
Did I understand correctly that this PR adds some functionality that reads the EXIF data of the pictures and does a rotation if the EXIF data indicates it might be necessary? Can this break functionality on older/other devices? |
This comment has been minimized.
This comment has been minimized.
Yes, with some devices (ie samsung) the capture image is rotated and rotation details are in EXIF data. |
I was more wondering if some device maybe reports something in EXIF data, but the pictures came out right anyway - but wouldn't any more with this patch applied. Possible? |
Well, we could return null if ExifInterface.ORIENTATION_NORMAL |
@janpio What do you think? Shall I return null if we have EXIF data but orientation is normal? |
Did I understand correctly that this would avoid having to touch the image at all if not rotation is necessary? Then that sounds like the proper thing to do. |
Ok, I've updated the commit and now it uses original image if we have EXIF but no rotation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
As the default behavior for some devices changed, this should probably be considered a breaking change.
I am also not 100% if 1) there are no ways in which this could break behavior some users might rely on and 2) the default compression of the returned image is a good thing (although I can't think of an alternative).
Well, I understand your position but in my opinion the bug itself is more critical than 1) or 2) |
... which is why I approved the Pull Request and just left those as a comment for whoever decides to merge (which might as well be me if no-one else shows up). |
It has been 19 days and this fixes a critical issue. Can we merge it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works like a charm - tested on brand new Samsung Galaxy S9.
@janpio it could seem as if the tests fail for other reasons than actual code. Could seem as if the build process itself is broken. Would you agree? |
Ahem yes, very much possible. Still has to be taken into account before reviewing and merging by a maintainer, which is why it is reflected in the project board state. |
@mcelotti this PR has conflicts. Can you take a look? |
@ffMathy it's kind of natural to have conflicts after 1 month. Anyway, I'll take a look |
f713a5b
to
97f658d
Compare
a quick note: the current code of "Capture.java" has 34 warnings in android studio, I think this should be addressed |
@mcelotti To make sure this doesn't get forgotten/buried, please open a new issue. Feel free to look into it and create a PR yourself of course if you have the time and interest. |
@janpio sure I could, but with all these open PRs (14) people will end up with a ton of conflicts if you merge this "code review" first. And if you merge the review in the next months then ... I'll have a lot of conflicts. I think there should not be so many open PRs, you should try to accept/reject more often. |
We are trying. You can help out over at #105 to enable us merging again. |
Build has now been fixed, but how do we re-run the build for this PR? |
I can do that and just did. Build is now green. |
Awesome! Can't wait until this is merged! |
@janpio sorry for bothering you again, but is there anything we can do to involve the parties needed for reviewing? |
Short: No. |
Do you have a list of committers somewhere that would elligible for that description? My concern is that there won't ever be random Cordova committers that will come by and review this. Only new people that won't fit that description. This is a critical bug. It's unusable on Android devices. The fix works. It has been tested by the author and myself on real devices. The approach we are using right now doesn't seem very pragmatic to be honest. I get that we shouldn't try to rush things in, but this could take years! |
@jcesarmobile you (relatively) recently pushed an orientation fix for iOS. This issue is regarding Android which has the same problem. If you have Android experience also, can you help out by reviewing it? I suppose you have interest in getting this bugfix out too, if you are targeting Android devices. |
Hi, does anyone know when this PR will be merged? |
No. |
@janpio : What have to be done to merge this PR into the master? Who can do this? This PR was opened 1,5 years ago. |
Fix Android Photo Rotation apache#100
Platforms affected
Android
What does this PR do?
It fixes this issue: https://issues.apache.org/jira/browse/CB-13683
What testing has been done on this change?
Tested on a real device that was having this issue (samsung s2)
Checklist