HackDay – hack attempt 2 – screen brightness

After my less-than-entirely-successful first hack, I started a second idea yesterday afternoon for the IBM HackDay.

Background
Windows Mobile smartphones include a screen brightness control. When indoors or in low light levels, you can turn the screen brightness down to maximise the battery life. When outdoors or in bright ambient light, you need to turn the screen brightness up in order to be able to make out things on the screen.

The idea
The plan was to write something that would use the camera in my cameraphone to work out the ambient light level. And then use this to programmatically alter the screen brightness as appropriate.

Why?
It takes seven screen-taps to change the screen brightness – so it’s not very quick. Something that did it for me would improve the usability of my phone.

What was the plan?
There wasn’t really a plan. I’ve not done anything with the camera API on Windows Mobile before, so the first job was to find out what function is made available. I started with managed code, but it seems that (in an effort to abstract the details of different cameraphone types and hide the complexities of device management from the developer) you can only access a finished camera viewer – with all the normal camera controls and widgets – for use in your own application.

This left me with giving it a try in native code, and seeing what can be done.

How far did I get?
Not very. 🙂

My first approach was to try and access the camera device and get some brightness value out of it. No luck – as far as I can see, it’s just not exposed.

Second approach was to try and programmatically take a picture using the camera (without making the camera viewer appear on screen), and see what information I could get out of the graph builder or the capture filters used to take the picture. No joy here either… I think the closest I got was probably when I tried something like this:

IMixerPinConfig2* piMixerPinConfig2 = NULL;
pStillPin->QueryInterface(IID_IMixerPinConfig2, (void **)&piMixerPinConfig2);

DDCOLORCONTROL color;
piMixerPinConfig2->GetOverlaySurfaceColorControls(&color);
long brightness = color.lBrightness;

Not sure what that would have given me back, but it’s all kinda academic as it didn’t work anyway. (The attempt to get the IMixerPinConfig2 object failed with HR_NOINTERFACE – although the code compiled, I guess it’s not implemented in Windows Mobile.)

My next plan was to take a picture, then see if I can get anything useful out of that picture. I did consider looking through the pixels in the picture and “analysing” it for some idea of brightness, but wasn’t sure that I’d get anything sensible out of that. I’m not really into photography, but I knew that cameras put a lot of metadata about pictures into EXIF tags. I know that my camera puts the date and time in there, so I wondered if my phone camera might put some indication of the brightness in there. As the settings are pretty much all automatic for the camera, I thought that info like shutter speed or the exposure that it decided to use might be a clue as to the current brightness.

So I had a stab at writing some C++ to take a picture programmatically and get the EXIF data out of it. Closest thing I found was an array of numbers tagged as a “Luminance Table”. It sounded like it might be useful, so I tried adding these together to get some rough indicator of brightness.

By this point, I fancied a break from struggling with a camera which isn’t very friendly to developers, and had a go at controlling the screen brightness.

This wasn’t too bad – you do this by changing a registry value, then let the OS know that the registry value has changed and it should go back and read it again.

You put a value between 0 (off) and 10 (uber-bright) into HKEY_CURRENT_USER\ControlPanel\Backlight\Brightness and HKEY_CURRENT_USER\ControlPanel\Backlight\ACBrightness then generate a BackLightChangeEvent.

The last bit was to work out how to translate my LuminanceTable sum into a brightness value from 0 to 10. So I took a bunch of pictures from around B block (where we were based for HackDay) to get some values to use to calibrate it.

Except… they were the same in all my pictures! It seems that the LuminanceTable values are something about the camera, rather than about the picture. So it… erm… wasn’t telling me anything.

Damn.

I did think about doing the same for sound – adjusting the volume of my phone based on the background noise level. But a quick Googling showed that this has been done before… earlier this month! Spooky coincidence.

Comments are closed.