[camera]Nickcullen darkcamera fix

[NickCullen]

Fixed camera preview darkness (my test device is a Samsung Galaxy Tab A).

The issue was that the FPS of the preview camera was too high and the auto exposure capability couldn't keep up which resulted in it 'giving up'. This only seems to be an issue on low end devices such as this and I've noticed the level of darkness varies between devices.

PLEASE NOTE: On low end devices (such as the Samsung Galaxy Tab A) this does make the camera preview feel choppy (after all... the frame rate had to be reduced). If I open the stock camera app on this device, the frame rate is identical. Meaning that they're also compensating FPS for exposure gains (so you can actually see what you're about to take a photo of).

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[NickCullen]

I signed it!

[googlebot]

CLAs look good, thanks!

[amirh]

What makes the first returned range the "best"?

[NickCullen]

This is the slowest FPS off the list, and from what I recall when attempting to fix this issue in my app was that the slowest FPS = better auto exposure result of the preview image. That and the fact that the stock camera app on the device is the same FPS I followed suit.

The range values can come in two different varieties:

• (x,x) Where the FPS ranges are the same (I get 3 of these in that list on my device (7,7), (14,14) and (30,30))
• (x, y) Where there is an allowed leeway for the FPS. But from what I recall when trying to fix this issue in my own project led to sporadic behaviour such as the preview image flicking between dark / normal exposure.

I can take a look again tonight and see if including one of the (x,y) ranges that has the largest range between the x and y component to see if this would produce a better overall frame-rate of the preview but all the while keeping the resulting auto exposure values sane?

[NickCullen]

I forgot to add, on newer/high end devices, the first value off that list of ranges is actually quite high. For example, I tested my app on my sisters Huawei p20 pro and the frame-rate was smooth and great exposure settings.

5 other people beta tested my app for Android and none of whom queried slow performance of the camera preview / dark images.

Granted this isn't a huge pool of people, but it does indicate that I improved my in app camera a lot this way.

[jatinmadaan8]

Hey @NickCullen i have tried your code it solved the problem but when the camera start recording the screen zoom in and become dark again and after the recording is done it zoom outs and become light again. And the file also saved as dark recorded. Please help me out here.

[NickCullen]

Hi @jatinmadaan8 I made a comment a few minutes ago HERE about using continuous picture mode to use AE and AF settings from the preview. Could you give that a try?

As a side note though I notice you are talking about video here, I have no experience with the video side of things I'm afraid, I can only hope that this will resolve your issue.

[jatinmadaan8]

Hello @NickCullen i tried it today still no progress. I don't know for no reason when the recording starts it gets zoom and dark.

[NickCullen]

@amirh I have just had some time to check out the biggest FPS range and it works really well (I was in the middle of developing my camera when I saw the flickering darkness so it must of been something else that caused it).

I took some pictures of my device's screen (which unfortunately I can't upload here) when I ran them in 4 different modes:

1. Without this AE exposure range set (the camera preview was basically darkness)
2. The first range (x, x) = (7, 7) off the list (great exposure, slower frame-rate)
3. The middle range (x, x) = (14, 14) off the list (screen was dark again, frame-rate improved but didn't matter at this level of darkness)
4. Range with the biggest difference between (x, y) components = (7, 30) for the Galaxy Tab A. The exposure was fairly much identical to point 2 along with the frame rate, maybe a slight improvement? Didn't get any darkness flickering.

Please note I've added myself to the authors files, as per the contributing notes.

[amirh]

Hi thanks for following up.
IIUC the AE FPS range parameter lets you trade off AE flexibility with frame rate.
I think that for different applications in different scenarios and different devices the best decision would be different, so I don't think we should just make the plugin to always prefer maximum AE flexibility but rather expose this as a parameter and let the application decide.

[NickCullen]

Hi thanks for following up.
IIUC the AE FPS range parameter lets you trade off AE flexibility with frame rate.
I think that for different applications in different scenarios and different devices the best decision would be different, so I don't think we should just make the plugin to always prefer maximum AE flexibility but rather expose this as a parameter and let the application decide.

Hi @amirh
Good point - although this issue only really effects Android devices and not iOS. I don't recall coming across an iOS setting like this during my own development either.

If we were to make it a configurable option in the camera controller, would the setting be miss-leading on an iOS device? Or will a simple statement in the comments stating that the option only effects Android devices be sufficient?

[amirh]

It should be ok to have features that are supported only on some platforms/devices, otherwise we would be limiting ourselves to a lowest common denominator.
I'd leave the API design / documentation comments to someone more familiar with the current plugin, probably a topic worth discussing over a PR.

Also note that we are prioritizing quality over new features right now so it might take time for a PR adding this new feature to be merged.

[lschmierer]

Also note that we are prioritizing quality over new features right now so it might take time for a PR adding this new feature to be merged.

A camera not usable on lots of Android devices because being too dark is not quality.

[neumartin]

Hi!
@NickCullen have you any tip to solve this?, I have the dark image preview error.
Thanks!

[danielroek]

@NickCullen Do you see any possibility to merge your changes in the new federated architecture and expose an option to configure this behaviour via the Dart implementation?

[mvanbeusekom]

This has been solved by PR #3383 and has been released in version 0.6.4+3. I will therefore be closing this PR.

[Prince-Ampomah]

how do I take a picture and save it into cloud firestore