It is currently Sat Oct 20, 2018 8:41 am




Post new topic Reply to topic  [ 24 posts ] 
 Testing External Exposure Control 
Author Message
Post Testing External Exposure Control
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


Sun Dec 14, 2008 12:15 pm
User avatar

Joined: Tue Apr 29, 2008 2:48 pm
Posts: 1144
Post Re: Testing External Exposure Control
yeah so it looks pretty normal ;) No Seriously - Great Job :D - 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

_________________
Please check out how to embed a Vimeo link.
Tim T


Sun Dec 14, 2008 12:31 pm
Profile
Post Re: Testing External Exposure Control
pixelbot wrote:
yeah so it looks pretty normal ;) No Seriously - Great Job :D - 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


Sun Dec 14, 2008 1:02 pm
User avatar

Joined: Tue Aug 26, 2008 3:30 am
Posts: 824
Location: Sydney, Australia
Post Re: Testing External Exposure Control
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?


Sun Dec 14, 2008 3:05 pm
Profile
Post Re: Testing External Exposure Control
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


Sun Dec 14, 2008 3:47 pm
Site Admin
User avatar

Joined: Thu Mar 27, 2008 2:15 pm
Posts: 1695
Post Re: Testing External Exposure Control
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.


Sun Dec 14, 2008 4:19 pm
Profile
Post Re: Testing External Exposure Control
Amazing Church! Your research and science behind this is really admirable... I can't wait to see more out of your adventures.


Sun Dec 14, 2008 5:00 pm
Post Re: Testing External Exposure Control
timescapes wrote:
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.


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


Sun Dec 14, 2008 8:35 pm
User avatar

Joined: Tue Aug 26, 2008 3:30 am
Posts: 824
Location: Sydney, Australia
Post Re: Testing External Exposure Control
That's looking pretty smooth for overall exposure variations.

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

!c


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


Sun Dec 14, 2008 9:25 pm
Profile
Post Re: Testing External Exposure Control
matt b wrote:
That's looking pretty smooth for overall exposure variations.

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

!c


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


Sun Dec 14, 2008 9:55 pm
Site Admin
User avatar

Joined: Thu Mar 27, 2008 2:15 pm
Posts: 1695
Post Re: Testing External Exposure Control
shutterdrone wrote:
timescapes wrote:
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.


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


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.


Sun Dec 14, 2008 10:28 pm
Profile
User avatar

Joined: Fri Jun 13, 2008 5:54 am
Posts: 611
Location: Oslo, Norway
Post Re: Testing External Exposure Control
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!

_________________
Canon 400D, 50D, 5D Mk II. Canon L 16-35/f2.8, Sigma 10-20. Adobe Creative Suite 4.
website:
http://www.magictimelapse.ch/en


Mon Dec 15, 2008 2:27 am
Profile
Post Re: Testing External Exposure Control
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


Mon Dec 15, 2008 8:05 am
Post Re: Testing External Exposure Control
that is sooo friggin cool! :o 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.


Mon Dec 15, 2008 10:18 am
Post Re: Testing External Exposure Control
milapse wrote:
that is sooo friggin cool! :o 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


Mon Dec 15, 2008 10:37 am
User avatar

Joined: Fri Jun 13, 2008 5:54 am
Posts: 611
Location: Oslo, Norway
Post Re: Testing External Exposure Control
shutterdrone wrote:
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...

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)?


shutterdrone wrote:
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.

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!

_________________
Canon 400D, 50D, 5D Mk II. Canon L 16-35/f2.8, Sigma 10-20. Adobe Creative Suite 4.
website:
http://www.magictimelapse.ch/en


Mon Dec 15, 2008 11:33 am
Profile
Post Re: Testing External Exposure Control
Michael wrote:
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)?


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 =)

Michael wrote:
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!


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


Mon Dec 15, 2008 12:19 pm
User avatar

Joined: Tue Aug 26, 2008 3:30 am
Posts: 824
Location: Sydney, Australia
Post Re: Testing External Exposure Control
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?


Mon Dec 15, 2008 5:36 pm
Profile
User avatar

Joined: Tue Aug 26, 2008 3:30 am
Posts: 824
Location: Sydney, Australia
Post Re: Testing External Exposure Control
tmophoto wrote:
you can see it in the first 1/3 of this shot (i was messing with the exposure and fstop) its really choppy (it was my first timelpase shot with a motion head i didnt know what i was doing)


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?


Mon Dec 15, 2008 9:58 pm
Profile
User avatar

Joined: Fri Jun 13, 2008 5:54 am
Posts: 611
Location: Oslo, Norway
Post Re: Testing External Exposure Control
shutterdrone wrote:
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


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

_________________
Canon 400D, 50D, 5D Mk II. Canon L 16-35/f2.8, Sigma 10-20. Adobe Creative Suite 4.
website:
http://www.magictimelapse.ch/en


Fri Dec 26, 2008 10:25 am
Profile
Post Re: Testing External Exposure Control
What's the latest on this Church?? I'm dieing to try it out! Did I ask you what the limitations on the shortest bulb exposure is on the Pentax 2.5mm pin??


Fri Jan 02, 2009 6:31 am
Post Re: Testing External Exposure Control
milapse wrote:
What's the latest on this Church?? I'm dieing to try it out! Did I ask you what the limitations on the shortest bulb exposure is on the Pentax 2.5mm pin??


Hey man! I've been testing out a few designs to get more accurate/useful data. I'll answer the easy question first - the minimum repeatable (!) bulb exposure time for the K10D is 70mS. You can do shorter periods, but they tend to hiccup and wander below 70mS. This has actually been a bit of a problem, as during full daylight, even at ISO 100 and F16, I've had to add ND filters to get down to 70mS. (That's about 1/14th second.)

Ok, for status - I've tried three methods for metering, each with serious drawbacks:

1) "Ambient" light - metering in the shade somewhere. This works great as long as your shot doesn't include sky. =) The reason is that the sun is still reflecting in the sky long after the light has dropped immensely in the area you are metering. The light drop-off in the shade has a sharper ramp than in the sky, causing blow-outs of the sky during the last 20-30 minutes of the transition. I've contemplated a "sky-mode" - where you can program in that sky is in the shot, and to put a nice knee on the exposure time curve, but there's more testing for this method before I get there. I'm thinking it can be done w/o any real hackery there, if I can just get the right hardware design. Testing out a new holder/meter setup next week or so.

2) "Wide-angle scene averaging" - I made a hot-shoe mount for the sensor and point in the general direction of the shot. It works "OK" provided you're using a wide-angle lens, and is easily fooled by over-head street lights and such.

3) "Through-the-viewfinder metering" - works ok, *except* the mirror/pentaprism arrangement actually reduces the amount of light a great deal. It's easy enough to adjust for the "viewing aperture" and black-outs when exposing and all of that, but it's hard to make up for the 5-9x light lost! Lose resolution here as sun sets, and the light drops below the useful range of the sensor.

So, the fourth method I'd like to try soon is using a "matched lens" and mount for it. That is, create a mounting plate, affix a second matching lens to it, and meter through that by adjusting it to have the same scene. This still requires viewing aperture adjustment (not a big deal in software), but doesn't have the pentaprism and mirror to reduce the light hitting the sensor. I'm not sure how long this is going to take, but I know I won't be able to get to it for the next few weeks, as some other projects have increased in priority (lady bought me a table saw for xmas, and I've been promising her a nice fountain for months, so I'm getting that out of the way right now =)

Michael - I'm glad to hear you got an arduino and got the sensor working! These things are addictive ("What, the coffee pot isn't accurate enough? Let's upgrade it!") - let me know if you have any questions, always glad to help!

!c


Mon Jan 05, 2009 8:27 am
User avatar

Joined: Thu Jan 15, 2009 1:23 pm
Posts: 4
Location: Hilo, Hawai'i
Post Re: Testing External Exposure Control
Wow! This tread has got me entranced. We've been trying to find a way to plot a sunset/sunrise then draw an exposure curve that gives us a nice clean transition into night/day and not loose the colors. Mostly we've been ramping manually and trying to fix the flicker in post. As you can see in this: http://www.gemini.edu/videos/pio/MKInversionHD.mov

One of the telescope controls engineers I work with is building an intervolometer for me with the idea of programing the plotted curve into the unit rather than metering as we go. Does that sound workable?

_________________
Kirk Pu'uohau-Pummill
http://www.gemini.edu/videos/pio/gemini ... _music.mov


Thu Jan 15, 2009 5:45 pm
Profile
Post Re: Testing External Exposure Control
Kamakoa - I don't know if it would actually work, but I think that's an idea well worth pursuing. The thing that begs the question is that can you fine-tune it enough to your specific environment for it to be truly useful? That is, the "fading of light" at sunset is not linear, you may find during the first 15-20 minutes, it fades at around 1/50th EV every thirty seconds, and then in the last 15 minutes of sunset, it fades at a rate of 1/100th EV/second.

Of course, that's going to be impacted by environmental features, etc.

That being said, I'd really like to see if something like that works well in multiple environments, or if the algorithms have to be specifically tuned to the place where the shots are to be taken. Of course, I'm not prepared to do this *grin* I've already got so much time invested in this one technique, that I'm just about ready to completely move on to some other problem =)

At any rate, I think I've finally hit the "sweet spot" of this technique. It seems to work well, I get a small amount of flicker, but I think that can be worked out by simply tuning the device via the options already available in it, nothing that requires a change to the design or software.

So far, the best technique I've come up with for measuring light is placing the sensor inside of a 3-sided box (essentially, three pieces of 1x6 screwed together in the shape of a C, with the sensor housing screwed through the upright part, facing to the bottom), painted a nice, clean white on the interior. This sensor is then placed in _shade_ (the shade from a building, vehicle, tarp, or something else) and pointed _at the scene being shot_. It is important that it is protected from interference, its darned sensitive - just standing within 2' of any of the three open sides of the box it impacts its readings!

Anyhow, once its placed in such an orientation, the ISO and target f/stop are set, and the EV reading is adjusted (positively) in 1/4 EV increments until the expected exposure value is achieved. Now, the other parameters are set, and the program is set to run - largely without any interference from the user.

Some changes I made:

It turns out that EV averaging is largely a waste of time - it just means your EV is constantly moving up and down as changes are worked into the average, and you never get a correct reading. Instead, Tom had kind of hit on a point earlier about "maximum change between shots" - in the current design, you simply set a maximum threshold of change _between readings_ (rather than between shots! this is _very_ important!) - so, if the device is configured to to do 1/100th EV increments, and a max change threshold of 3 is set, that means it can only change 0.03 EV up or down, every second. (Readings are performed once per second for accuracy.) So, on a five second interval, the maximum change would be 0.15 EV up or down between the shots. The helps minimize the impact of, say, a dog coming up and sniffing your sensor (this was a huge problem w/ the neighbors dog during my tests! He would come up and sniff at it, and add 5EV of exposure time to some frames!) while shooting.

The other thing I fixed was resolving jitter. Since we're dealing with analog (infinite variations) to digital (two states) conversions, and adding to that the sensitivity of both data calculation and transmission to outside interference, there is a lot of "bouncing" in the signals. Primarily, the frequency read from the chip varies slightly even given the same amount of light. Originally, I had attempted to work out this "jitter" by waiting until the EV calculation phase, and then requiring that I had two EV values that were the same before making a change. This was problematic in that the old dog situation above would cause it to bring a very long reading (low EV) and it would take a long time to recover, several seconds, as it would jitter quite a bit settling back in w/ more light on it. EV averaging simply meant the read EV was constantly moving up and or down with the changes - never fixing in with a point. I presume that it would've eventually worked out, using say, a 10 minutes average, but that requires holding 600 values in memory! (60 seconds * 10 minutes) It turns out, that it's much easier to deal with on the front end. Jitter is resolved by requiring a minimum threshold of change in Hz for the frequency readings. Setting it to 20Hz means that for most uses, jitter is almost completely eliminated, although very-dark exposure calculations (i.e. difference between 100 and 150 stars visible =) are impacted -- this can be adjusted down in those situations.

Now, another primary problem I was having was that when exposure time increased beyond interval time -- I thought I had resolved it when making this video, but during the process saw that I had done something really stupid in the software, and messed that up. I've since resolved it, but unfortunately you see a gap in the video where it went haywire due to the bug. Essentially, now I just require a minimum of 1 second between shots. This is primarily due to the fact that the camera de-bounce the remote input, and you have disconnect the trigger for at least a minimum of 1.5x the de-bounce time programmed into the camera. I just said "screw it", and made sure there was always a minimum of 1 second between shots.

So, below is the latest test video. The first half shows it completely un-modified, and a moderate amount of flicker. The second half shows it with GBEdeflicker run through vdub at default settings. I am confident that I can resolve the minimal flicker through config settings alone, no changes to hardware or software. This is also the last time you'll see this boring scene - it's just a lot easier to test this right outside the door, than driving ten miles to find out you made a bone-headed mistake.

The exposure time starts at 1/6th second @ ISO 400 / f/16. The ending exposure time is 8.3s.



Edit: I'll have the page up with the software and hardware designs very soon. Everything will be open-source.

!c


Wed Jan 28, 2009 8:34 am
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ] 


Who is online

Users browsing this forum: No registered users and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore. pozycjonowanie