Skip to content
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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

mcelotti
Copy link
Contributor

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

  • Reported an issue in the JIRA database
  • Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
  • Added automated test coverage as appropriate for this change.


private Uri fromBitmapToUri(Context context, Bitmap inImage) {
ByteArrayOutputStream bytes = new ByteArrayOutputStream();
inImage.compress(Bitmap.CompressFormat.JPEG, 85, bytes);
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link

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?

Copy link
Contributor Author

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

Copy link

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?

Copy link
Contributor Author

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

@janpio
Copy link
Member

janpio commented Aug 23, 2018

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?
Is it possible something depends on the current behavior?

@cljmomo

This comment has been minimized.

@mcelotti
Copy link
Contributor Author

Yes, with some devices (ie samsung) the capture image is rotated and rotation details are in EXIF data.
If something goes wrong the "rotateAccordingToExifOrientation" should return null (or the original bitmap) hence no rotation will be applied.

@janpio
Copy link
Member

janpio commented Aug 23, 2018

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?

@mcelotti
Copy link
Contributor Author

Well, we could return null if ExifInterface.ORIENTATION_NORMAL

@mcelotti
Copy link
Contributor Author

@janpio What do you think? Shall I return null if we have EXIF data but orientation is normal?

@janpio
Copy link
Member

janpio commented Aug 24, 2018

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.

@mcelotti
Copy link
Contributor Author

Ok, I've updated the commit and now it uses original image if we have EXIF but no rotation

Copy link
Member

@janpio janpio left a 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).

@mcelotti
Copy link
Contributor Author

Well, I understand your position but in my opinion the bug itself is more critical than 1) or 2)
There are so many samsung devices out there, and there might be also other non-samsung with the same problem.

@janpio
Copy link
Member

janpio commented Aug 24, 2018

... 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).

@ffMathy
Copy link

ffMathy commented Sep 12, 2018

It has been 19 days and this fixes a critical issue. Can we merge it?

Copy link

@ffMathy ffMathy left a 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.

@ffMathy
Copy link

ffMathy commented Sep 20, 2018

@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?

@janpio
Copy link
Member

janpio commented Sep 20, 2018

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.

@ffMathy
Copy link

ffMathy commented Sep 22, 2018

@mcelotti this PR has conflicts. Can you take a look?

@mcelotti
Copy link
Contributor Author

@ffMathy it's kind of natural to have conflicts after 1 month. Anyway, I'll take a look

@mcelotti mcelotti force-pushed the CB-13683 branch 2 times, most recently from f713a5b to 97f658d Compare September 24, 2018 09:46
@mcelotti
Copy link
Contributor Author

a quick note: the current code of "Capture.java" has 34 warnings in android studio, I think this should be addressed

@janpio
Copy link
Member

janpio commented Sep 24, 2018

@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.

@mcelotti
Copy link
Contributor Author

@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.

@janpio
Copy link
Member

janpio commented Sep 24, 2018

We are trying. You can help out over at #105 to enable us merging again.

@ffMathy
Copy link

ffMathy commented Sep 29, 2018

Build has now been fixed, but how do we re-run the build for this PR?

@janpio
Copy link
Member

janpio commented Sep 29, 2018

I can do that and just did. Build is now green.

@ffMathy
Copy link

ffMathy commented Sep 29, 2018

Awesome! Can't wait until this is merged!

@ffMathy
Copy link

ffMathy commented Nov 14, 2018

@janpio sorry for bothering you again, but is there anything we can do to involve the parties needed for reviewing?

@janpio
Copy link
Member

janpio commented Nov 14, 2018

Short: No.
Long: Materialize a Cordova committer with enough Android knowledge and time to review this.

@ffMathy
Copy link

ffMathy commented Nov 14, 2018

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!

@ffMathy
Copy link

ffMathy commented Nov 14, 2018

@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.

@valgen
Copy link

valgen commented Jul 17, 2019

Hi, does anyone know when this PR will be merged?

@janpio
Copy link
Member

janpio commented Jul 17, 2019

No.

@rogervanwile
Copy link

@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.

rogervanwile added a commit to rogervanwile/cordova-plugin-media-capture that referenced this pull request Jan 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants