Issue 1351 in zxing: Automatic flash setting when scene appears to be dark

[Nikolaus Huber]

Issue link

Hi.

I started working on this idea and now have a very rudimentary implementation but wanted to ask a few questions:

The best way to implement it seems to add code to the class "PreviewCallback.java" in android/camera. I tried adding a AutoFrontLightManager in the style of the AutoFocusManager but using the Camera.PreviewCallback interface instead, but failed. Also it seems that only one PreviewCallback can be held by the camera at one time (link).

Question 1: Should I add the code for Auto Front Light to the class "PreviewCallback.java" or should I look for a different option? If different, any ideas?

Question 2: After I finish writing the code, how do I best get my code committed?

[Sean Owen]

This sounds good to me. I think the best thing to do is to hook into the point in the code where the image has been converted to luminances, and sample the image (perhaps pixels on the diagonal?) to assess its average luminance, and store that value along with recent averages so that you know what the luminance has been like in the last few seconds. When the current luminance is high and is notably higher than in the recent past, use Message to send a message to CaptureActivityHandler, which can decide whether to turn on the torch by calling a method on CameraManager. See setTorch() there. This probably needs an ability to not bother changing the state if the current state already matches desired state.

That's about it; I don't know if it's too hard to wire up cleanly. I do think it will take a little tuning so its responsive but not flickering. There's also the question of performance impact of sampling.

[Nikolaus Huber]

Ok. So I cleaned it up a bit.

I don't currently use the Message to the CaptureActivityHandler since the PreviewCallback already has access to the CameraManager and its setTorch() method. Should I still do it the "Message" way? The setTorch() method definitely needs to be altered a bit, as by every change it also copies it into the "Use Front Light" Setting, which in this case should also ideally be deactivated. I will look into that.

The Auto Front Light Algorithm is a bit weird at the moment (I just took the average of a semi-diagonal and compared it to a threshold), but I will try and improve that. Another idea would be to also use the Ambient Light Sensor (I will try and look into that and how complicated it would be)

Do I need to add the strings for the preferencesActivity for every language? What does it do when it does not find the right string for a language?

[Sean Owen]

Not quite, it has access to CameraConfigurationManager. That's enough to change the setting, but you will cause errors because you haven't paused auto-focus. Going in via CameraManager does that correctly.

I don't think you need any new strings here... at least don't worry about it now.

[Nikolaus Huber]

Are you sure that the CaptureActivityHandler would be the best solution? Since this would seem to take a lot of handing down of objects to actually the it into the PreviewCallback Class. Also, the CaptureActivityHandler seems to more do the interaction between different activities (from decoding succeeded to showing the result for example) and less during the same activity.

As PreviewCallback gets initialized inside of CameraManager, wouldn't it be easier to just hand itself down as well and skip the messages all together.

Would it be possible to commit what I have so far (after changing to the setting of Torch through the CameraManager)?

[Sean Owen]

Maybe so, I hadn't looked at it great detail. The key is that CameraManager is needed, not CameraConfigurationManager. 

These classes are getting quite coupled, but, they always were.

You can post an intermediate patch in a new issue and I'll take a look and work it in as needed.