So, here's the first "successful" test of my external exposure control system. On Friday, I got a chance to shoot a sunset, but had made an egregious error in my software -- when calculating exposure time, I had designed it to (in addition to lots of other things) act like a normal light meter and show exposure times in 1/x second values (e.g. 1/4, 2", so on). Unfortunately, when converting from my calculated exposure setting to mS for bulb exposure - I rounded to the nearest 1/x exposure value -- effectively rendering the system no more accurate or granular than the in-camera meter. By the time I figured out my mistake and fixed it, it was already dark.

A point worth noting: I designed it such that it can measure 1/100th EV changes and respond to them. I'm not sure 1/100th EV actually equals a whole millisecond in all cases (the smallest time I can track for exposure) - but it definitely makes very minute exposure changes.

In between some bad weather today, I shot a short video using the system. In this case, I'm using a manual (m42 Super-Takumar 35mm) lens attached to the K10D and set to f/16. The meter is pointed "in the general direction" of my shot, and the aperture setting is adjusted on the meter until I get a value pretty close to a mid-gray exposure. The camera won't reliably respond to bulb exposures shorter than 70mS, so this becomes my floor. Fortunately, the shortest exposure calculated during the shoot was 71mS =)

Anyhow, the system was set to adjust up and down as needed. In the less-than-interesting video below, the exposure time fluctuates from 71mS at the beginning and ends up around 102mS at the end, changing as clouds pass over. I'm pretty happy with the results, there is practically no flicker. In case you're wondering if there's any difference, consider that when you see the dark clouds coming in, it gets noticeably darker outside.

Hopefully, if my visiting family keeps themselves busy for the evening, I can shoot the sunset tonight too, and see how that goes.



Edit: here, you can download the original from vimeo, and see the result much better: http://vimeo.com/download/video:8669368 ... 246be4ecb6

Edit: replaced youtube version w/ vimeo version

!c

yeah so it looks pretty normal No Seriously - Great Job - you almost need to have another camera running (without exposure control) to show how remarkable this clip is. So is this external controller camera specific or can you hook it up to any camera? I think you are on to something here.

timt

Thanks! I'm actually running a test right now (having to shoot out the front door, as it keeps raining) where I'm letting the camera do its own exposure metering for a while, then I'll hook up my system - and let that run through sundown.

The design, as such, will work with any camera that uses a two-or-more-pin connecting remote. That is, if the remote jack sends power down one contact, and you connect that with another to fire (or engage auto-focus) then it will work as designed. That at least covers Canon EOS, all the Pentax digitals, and many others - you just have to know the pin-out and have the right connector. The design could be modified to support IR-remote cameras by removing the opto-isolator, (this isolates the camera from the rest of the circuit, and vise-versa, in case you accidentally short something out - the precious camera doesn't get fried) and replacing it with an IR LED on a long wire or something.

Once I've made sure everything works like expected, I'll share the design and software. If you really just want to start jumping into the waters early, I've written a couple of tutorials on the light sensor I'm using, here: http://roamingdrone.wordpress.com/2008/ ... g-started/

!c

Science was never one of my strong points so can you explain the difference of the relative sensitivity of your impressive metering system in terms of camera stops from a standard camera meter to your custom set up.

I understand you set the aperture (example given - f16) and then the shutter is finely adjusted via your light sensor?
Would it be more accurate if it read a dedicated 18% grey card set in near-shot or is this not necessary?

Matt,

Effectively, given that most cameras meter in either 1/3 or 1/4 EV steps, and this is capable of metering in 1/100 EV steps - the granularity of measurement is increased about 25 times. This, in theory, allows to make much finer adjustments to exposure. (A full EV step is equivalent to a 'stop' - a doubling or halving of exposure.)

So, say the camera sees a change in illuminance - from 320lx (exactly EV 7) to 352lx (a 10% increase in light) it has to make a decision to stay at EV 7, or jump 25% to 7.25 and under-expose slightly. By moving in 100 EV steps, we can adjust exactly to the change (presuming the change is measure-able in thousandths of a second =)

For this device, you set the ISO and Aperture - it reads the light energy falling on the sensor, converts that to illuminance (that is, how we perceive the light reflecting off a surface) and uses those three values to calculate the 4th half of the APEX formula: exposure time (shutter speed). I have set it up to also allow me to change the range of information it gives back to me - so I can make it more or less reactive to small changes in light, and the EV steps are adjustable (so you can make it as dense as the in-camera meter =) - I also have an EV adjust setting, like in the camera - so you can more easily map what it's reporting to the exposure you want.

It would definitely be more effective to meter off a card that's in the scene its self, but for landscape-style shots, that would require either a good spot meter or wireless connectivity to the device =) In fact, my test tonight has me very under-impressed with the concept of metering some "ambient" level not in the shot - it simply doesn't work at all for longer lenses, and has serious issues with wider shots where the sky is in part of the shot, and is very bright compared to the ambient light around you (sun is near horizon and blocked by structures, for example). It's going to need some more work, I'll upload the test from this sunset in a couple of hours.

!c

I think one of the most important things for building a system like this, for dealing with sunrises and sunsets, is that the device only be able to go in ONE DIRECTION. It's the ups and downs that kill you with most systems, in addition to the large leaps in exposure. In other words, can you make it so that for sunsets, it can only adjust to let in more light, never less. I would call it a ratchet mode, similar to what a roller coaster has when you first go up the incline.

Amazing Church! Your research and science behind this is really admirable... I can't wait to see more out of your adventures.

Yup - already there - except I called it "latch" - you can latch it so that it only goes one way (that is, if you latch to only increase exposure, it will always go up - each longer calc will become the new floor). A test earlier indicated that could be a problem in some situations too - a lot of dark clouds went over, darkening everything up, and twenty minutes later it lightened up 1/2EV - it caused a pretty nasty increase in exposure due to the inability to adjust back down w/ latch on. It works when the change is gradual and straight-forward, i.e., very overcast skies don't seem to work out too well. I've designed so that you can engage and dis-engage latching while the program is running -- i.e. wait to enable it until its the right time.

Here's another from tonight, covering about the 40 minutes of sunset on a dreary overcast evening -- I'm happy with it, other than it being generally under-exposed, it's not perfect yet, but I'm very happy with only one full day of testing it! =)

I'm going to upload the walk-through videos of the device to youtube in a minute, here's tonight's test:



Edit: forgot to mention, exposure started around 360mS and ended at 8,760mS (8.76s)

!c

That's looking pretty smooth for overall exposure variations.



For us scientifically-challenged members, what is that exposure range in EV/stops?

@ F/16 (what I shot at), it would be about 9.5 EV starting and 4.75 EV at the end.

!c

Very nice. Maybe you could apply some type of curve to it, so it ramps the exposure kind of slowly as sunset or sunrise approaches? To me what would be most useful is something that could smoothly make big transitions like day to night or visa versa. Are you saying that the clouds might trick the "latch" device? Perhaps if it could only change the exposure 1/100 EV per frame (or whatever amount actually works best) during the "latch," for example, it would be a smoother ramp? Just tossing out ideas here.

Very smooth, nice! So you can handle a dynamic range change of factor 24 (delta EV~4.6), pretty impressive!

Can this software on the arduino also do some more complex math, like fitting a function? You could then compute a trend during the transition from day to night with a smooth function, which has the same effect like Tom's ratchet, but maybe smoother and also possible for day - night - day time lapses!

So here's a quick walk-through of the UI:



And here's a video showing the internals of the device:



As for complex math? Yeah, it can do it =) To handle multiple wavelengths of light for conversion, I perform a gaussian function - an integration of the power spectral density and the luminous efficiency function across the spectrum of visible light. (I covered how to do that in the second article I wrote on the light sensor.) Of course, the current program only has about 1k of program memory left, and I have maybe 100 bytes of RAM left too. Heh. I can always cut useless features - like displaying the current frequency being read, or the uW/cm2 display, etc...

The question is -- would that do what we want? The reason I ask that is that the curve spread expected from a fitting function would change greatly based on whether it were summer, winter, fall, or if it were cloudy (slightly), cloudy (very), or bright clear skies. I already prevent nuanced fluctuation by requiring at least two EV readings to be the same before allowing the change (i.e. it takes two seconds to to move an EV step) -- I started adding in some basic averaging functions last night, so that it takes an average across 8 seconds -- after the EV normalization I mentioned happens.

As to changing a maximum amount per frame - that might not work too well, depending on your exposure cycle - at ten seconds, it went from almost no change per frame, to 1/10th EV per frame as the sun quickly dipped behind the horizon, and then settling to no change at all after dark. And, of course, the exposure time can be greater than the shot cycle (I make sure it doesn't try to interrupt the current shot) - so it could 30-60s between frames.

One thing I'm going to change is to eliminate "out of bounds" readings on the standard cycle (it updates values once per second) - that is, set a maximum variation (say 20%), and ignore any change greater than that between two cycles. Say: Reading1 = 8.15 EV, R2 = 10EV, R3 = 9.8EV -- R2 would be discarded, but R3 would be kept. That would prevent jumps like 8.15 -> 9.8 -> 8.2, so that we get 8.15 -> 8.15 -> 8.2

!c

that is sooo friggin cool! I can't wait to get my hands on one!!

So here's my question: How do you handle the exposure possibly exceeding the interval? I think it's fine for the exposure/interval to be a "sliding scale" as long as the device knows to wait a preset time for buffer dump time... It causes the final video to 'accelerate' but there are ways in post to get rid of that if you want... Personally I find it to be a fascinating effect.

I'm glad you touched on this point, because, at least with my camera, there are other issues too - if noise reduction is on, it takes a dark frame for the same time as the shot, thereby increasing the actual time to complete the exposure 2x. In bulb mode, if you're not aware of this, it won't respond to the trigger until after it's completed the dark frame, and then it only gets a partial exposure on the next firing because it doesn't respond to the remote until the dark frame is complete. So, there are two tricks (mostly I learned this when I built my motion control system):

1: It uses the "optimistic intervalism" I described in my TLA design - that is, if the camera is still exposing, but the interval time has elapsed, it keeps the counter running, and skips triggering the camera this round. Once the camera is dis-engaged, the counter is above the maximum time allowed for interval, and the camera fires right away again. So, on short exposures, if you set 10s, you get exactly 10s between shutter trips, but once your exposure exceeds 10s, you get exposure_time between exposures.

2: Handing noise reduction. To prevent bulb timing issues with cameras w/ NR (like mine) that take a black frame of same length after the shot (thereby doubling the actual exposure time), I added in a little bit of logic that checks when it is making the current exposure -- if the current exposure * 2 is greater than the interval time, it temporarily sets the interval time to the original time + difference -- interval_tm = interval_tm + ( ( exp_tm * 2 ) - interval_tm ) and then adds 10ms for good luck. It does this on each firing of the camera (adjusts the _next_ interval time) so when you have it adjusting both ways it will go back to normal when it can.

This can, of course, be setup such that you could either specify a time (for buffer clearing), or have it do the 2x thing for dark frame NR, or some combination of both =)

Edit: oh yeah, I also forgot to mention it auto-scales sensitivity to light levels, so I can keep high resolution to light changes in both daylight and the dark of a moonless night.

!c

Ok, after reading your blog, I understand better Still I want to truely understand... So, I guess you know the wavelength dependent sensitivity of your photo diode. Is this ilA_spd[i] in your integration? And v_lambda[i] is the model spectrum of some known source (like the models in usual cameras: Daylight, clouded sky, etc)?



Ok, I guess averaging does the job as well! I just wondered if one could model the transition from daylight to nighttime by a function and then fit it to the measured values. But probably that is really very depending on where you are and on the weather and so...

By the way: I ordered a Arduino, you made me interested Thanks again for sharing!

Well, not exactly. You've kinda got it backwards there =) ilA_spd[] is a table representing the spectral power distribution for an incandescent lightbulb (illuminant 'A') - that is, of the total amount of power being received, how much of it is represented in each wavelength. That table is actually a function you compare to the number of uW you've received total, and how much of it should be at each wavelength. v_lambda[] is the standard luminous efficiency function, that is - how visible a particular wavelength of light is to our eyes. The function I put in the code there (and the same one I use in this device) is very, very "estimated" - note how I jump in 20nm wavelengths, and presume that each nm between has the exact same SPD as the current one. This is so we can get the calculation done in a reasonable amount of time, and with a reasonable amount of memory consumed. (Although having 3 18 element float arrays is a bit insane in the uC world - it fits *grin*)

I didn't put the D65 table in that blog post, but I linked to the CIE tables where to get it. I used the 'A' values for my tests, hence the poor overall exposure, I'm going to switch over to the D65 (65Kelvin) tables soon, as they are closer to actual daylight than the ILA.

I haven't actually calculated for the per-nm sensitivity response of the chip its self yet, I promised that in a third article and just haven't gotten around to doing that yet. It seems to work "well-enough" w/o it - in fact, if you'll note, I always use the 1.0 response wavelength (420nm) in the calc_uwcm2() function. "Good enough for government work" as they say =)

Don't worry if it seems hard - it wasn't easy for me either, it took me over two weeks to get that code working and had to buy refresher books on calculus and algebra2 to figure out what the heck I was doing wrong - and the only way to verify was code and test against a reference source -- "this level of light _should_ be around 70lx, and this should be around 1lx" - I kept coding, testing, and re-writing until I got my expected results. My girlfriend hated me for those two weeks =)



To be honest, I don't think averaging is even needed. I think the biggest problem is just taking your readings from the right sources. All the tricks and such are just for working around not being able to get a good reference for your measurement. I'm thinking of extracting the sensor from the body of the box, and making a scope attachment for it - or even a lens attachment, and then a way to hook that up to the flash hot shoe for mounting. This way I could take a reading relevant to what I'm actually shooting. I've noted that it works GREAT whenever it's got a field of view similar to the lens, and horribly when the lens has a much narrower field of view. Like I said earlier, I think the "measuring general ambient light" is a much tougher option. It might make it easier to design the hardware, but the software will require a LOT of tricks.

For some tests, I had the device suspended above a sheet of white paper, and then spent about 20 minutes adjusting it to match my exposure and go from there, without fail, it would later either read too much or too little. The only tests that worked so far were with a wide-angle or standard lens, and pointing the sensor at the scene I'm shooting.

Congrats on ordering the arduino! Man, once I started getting them, I can't stop thinking of applications. I seem to want less to go out and shoot than to make some cool new device and move on *grin* Then again, that may be the product designer in me, hehe. With such a simple platform, everything seems within reach.

!c

When this device is used in a T/L shoot it is my understanding (... and I could be definitely wrong!)....
that your set interval will be constant, the resultant exposure very even and fairly flicker free, but the actual motion time in each frame could be different because your device is moderating the length of exposure .

Would this cause some interesting "time-dilation" effects as the shutter compensates for exposure?

An interesting effect ... are you able to share your technical data: shooting duration, exposure time, f-stop, interval, iso, etc. .....was it a waning moon?

Your description of the sensor is awesome, I just got it running and counting photons like crazy Thanks a lot!