Ok, so here's how I'm thinking of doing it, considering I've already got the code and the controller and such to do bulb-mode time-lapses, it's not a big stretch for me. However, I _must_ get the motion control done first (just got the 2d CAD done for a new pan unit, that'll mount on the 55" linear slide I just ordered, and move as little as 0.01 degrees vs. my current 0.07 design) -- and I'm going to the desert for a week in about 10 days. *sigh* so little time, and so much of it spent on a bad prototype.. Live and learn!
Anyhow, so here's the gist:
Take a small tube, probably PVC, paint the inside with the ultra-flat black camo paint (we used this a lot with home-made pinhole cameras, we don't want any bounce inside of it), place a small lens at one end, and find a decent focal point - and put a photodiode there. I have a bunch of plastic polaroid lenses, you can salvage these out of re-sale store cameras for a couple of bucks. Make a little mount for it, Then, I'll wire it off to my motor control unit, and have the UI configure an aperture, an ISO setting, and one of four values: don't measure light, no lock (increase or decrease exposure time, based on light reading), lock low (only increase exp. time), and lock high (only decrease exp. time).
Then, the photodiode would be wired straight into an analog input (via a cable that could be disconnected) on the arduino controlling the motors. If the flag is set to measure exposure time, immediately before triggering the optocoupler to connect the pins on the camera cable (and open the shutter), the analog value is read off of the photodiode. If it's changed from the previous value, the exposure time is adjusted according to f/stop and ISO. This would be additive/subtractive, permanently modifying the exp. time for the current program, so it wouldn't have to remember what changes happened before.
The pro's to this technique:
* it's easy, and costs only a few bucks (well, assuming a whole lot about having the arduinos, controls, etc. =)
* it requires no mucking with the camera
* it wouldn't add much weight to a program, reading an analog levels takes only an ms or two
The con's:
* arduino (and the AVR line of chips) have an ADC limited to 1024 possible readings - not a lot of granularity on light levels
* well, it requires writing code and making circuits, and having the code to do everything else, and a user interface, and...
* there's no guarantee it'll be any better than using matrix metering =)
I could probably find a device that would increase the resolution, as long as it doesn't use i2c, as that won't work with my design, but I really want to get the motion control down first =)
As to it being a market-able product, I totally agree, and I know of one person that is about a year ahead of me doing anything like that. I can tell you how to make it, but it's one of those things where I'm not sure it'd be able to/would want to productize it.
BTW, if you have the interest, I'll be happy the share my current motor/camera control code for the arduino -- it's rather stable and neat. The UI code is a sloppy mess, and I doubt you'd need that anyhow. (Unless you're interested in dealing with keypads and lcds =) If you'd like to do something like this, and just don't know where to start on the programming front, it could probably help you a lot.
!c