Shot Histogram Request

lapser

1093

Re: Shot Histogram Request

« Reply #40 on: 08 / December / 2012, 02:00:21 »

Advertisements

I did some significant changes to the metering today, with good results. I was able to eliminate the reference shot requirement!

I set up the step size and metering area in set_shot_histo(), so I also know the total number of samples before build_shot_histogram goes through the image pixels. I initially set my reference to an average pixel level of 50 percent of its total range (white level-black level)/2. I add up the actual pixels and get the sum, then subtract the log of the actual sum from the log of the 50% level, and set a new shutter speed based on this difference. In other words, the reference picture is one with all pixels at 50 percent of maximum (50% grey).

It worked! But the histogram of the resulting image was "exposed to the right". That is, it was overexposed. So I subtracted 2 f/stops, which means my reference is an image with all the pixels at 12.5% of maximum. I think this is what the built in meter is set to, because the exposure matched the one calculated by the camera with the first half_shoot pretty closely.

For the following video, I just took all the pictures, unprocessed, and turned them into a 30fps time lapse at 1 shot per frame. The shots are taken at 1.5 shots per second. The metering area, set by parameters in my new script, is at the upper left.

Despite my efforts to keep the camera dry with an umbrella, it was still getting sprinkled, and I decided to give up. But I took a video of driving in the rain, still at 1.5 seconds per shot. This was a more difficult metering test, but it seemed to get the metering much better than the camera meter could have. I found a few times where the upper left was covered by a dark tree in one shot, and then showed brighter clouds in the next. The brightness jump was noticeable, but only lasted one shot. Mostly, the brightness of the images appear pretty uniform.

The log files show that the exposure of the 2 sections of cloud videos dropped 1.5 ev in the first part, and 2 ev in the second part. The exposure changes smoothly, with no sudden jumps that might flash in a time lapse. The only "flashes" I saw were rain drops hitting the lens!

http://www.youtube.com/watch?v=BauS8Jq0pHc#ws

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

lapser

1093

Re: Shot Histogram Request

« Reply #41 on: 10 / December / 2012, 01:28:53 »

This time lapse was done at 2 seconds per shot, played back at 30 fps. It goes from day to night with the metering area set to a small box at the upper left. It's impressive how smooth the change from light to dark is, with no flashing. Remember, there's no half shoot, so nothing to adjust the exposure with but my get_shot_meter() routine.

As it gets darker, the meter keeps adjusting the exposure to keep the sky at the upper left at the same brightness, which overexposes the city lights at the end. The shutter time started at 1/367 second, and was 29 seconds at the end.

The bump near the beginning was me putting a plastic bag over the camera to protect it from a few sprinkles of rain.

http://www.youtube.com/watch?v=pnIeuphozw4#ws
I decided to use independent areas for the histogram and the meter. Coding that ended up a mess of variable switching and confusion. It was easier just to use arrays for the bounds of the meter and histogram areas.

Well one thing led to another, and I ended up with 4 independent meters you can set at different parts of the picture. Meter 0 goes with the histogram. It might be useful to have a spot meter, and an overall meter with histogram. The overall meter would have picked up the city lights changing. I could switch to the city lights meter when it suggested lower exposure than the sky meter and avoid the overexposure at the end.

I'm not sure what to do with 4 meters, but maybe someone will use all of them. The meters are working great, though. Next is to work on the histogram part to make it more useful for setting exposure. I'll start by making it 12-bit instead of 10 - still bit shifting the G1X down to 12 bits to save memory.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

lapser

1093

Re: Shot Histogram Request

« Reply #42 on: 10 / December / 2012, 01:56:38 »

This is a full resolution picture demonstrating the ability to use 4 different meters each with its own area specification. This picture was produced by setting each pixel to 0xFF after reading it for a sample, so it shows both the sample area and sample density. If you click on the image and zoom in to full resolution, you can see the dot pattern. By using an odd number step size between samples, the color of the pixels alternates and gives a better sample.

I also shifted every other row to the right by 1/2 step size, to spread the samples out a little more.

The image was produced with this simple script:

Code: (lua) [Select]

shot_meter_enable(1,0,0,25,25)
shot_meter_enable(2,75,0,100,25)
shot_meter_enable(3,0,75,25,100)
shot_meter_enable(4,75,75,100,100)
shoot()

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

lapser

1093

4 exposure metering areas

« Reply #43 on: 10 / December / 2012, 23:38:40 »

I converted the histogram to full size. Before, it took 0.002 MB (2K). 12-bit sensors will now take 0.008 MB, and the 14-bit G1X will take 0.032 MB. CHDK on start up says it takes 0.24 MB, and the camera has 2.4MB available on both the G1X and SX260. The extra histogram memory is only allocated it you enable histograms. You can enable just the meters without allocating memory. I think the memory use will be worth it if I can calculate something useful for setting exposure. I'll try calculating an exposure change to make the next shot exposed to the right (ETTR). I'm not sure how worthwhile that would be, but I think it's possible.

I tried an experiment with 4 metering areas at a time. There's 1 at the upper left, another is the lower half, a third one is in the center, and the 4th is the entire picture. If you look at the dot pattern in the photo, you can see all 4 areas represented. At least it works.

It may be useful for special situations, like day to night. With one meter on the sky, and the other on the city, you could choose the meter with the least exposure (i.e. fastest shutter speed). The sky is brighter in the day, and the city lights are brighter at night. Maybe that would keep from over-exposing the lights when it gets dark.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

lapser

1093

Latest Test Time Lapse

« Reply #44 on: 11 / December / 2012, 00:48:26 »

This actually got interesting enough that I wished I didn't have my test dots enabled. I was testing the new metering areas, but I missed getting a pretty good sunset.

I capped the exposure time at around 8 seconds at the end, so I didn't get a bad overexposure from trying to keep the sky at the same brightness as night fell. Note the video speeds up as the shutter time increases at the end. I've experimented with fading from one shot to the other at slower speeds, but it tends to look jerky. I think by shooting in continuous mode, the time between shots will be low enough that fading between them will look smoother.

http://www.youtube.com/watch?v=3B9XfdHIJ5o#ws

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

lapser

1093

12 & 14 Bit Histograms

« Reply #45 on: 12 / December / 2012, 12:35:15 »

I changed histogram.c to do the full histogram for higher than 10 bits. Then I decided it wasn't worth it, and took it out. In addition to the extra memory it takes (4 and 16 times the memory for 10-bit), there would need to be changes to get_histo_range(...) which I decided aren't worth the complications, not to mention trying to explain how to use it.

Anyway, I don't think the extra precision is needed. I was trying to figure out what to do with a shot histogram that might be more useful than get_histo_range(..). I read descriptions of how professional photographers use the histogram. What they describe is, they take a shot, look at the shot histogram, and adjust the exposure (or framing) so that the left and right side of the histogram are not clipped off.

So what I propose to do is calculate an exposure change, like I've done for the meters, based on the histogram. It would be easiest to understand by adding a function:

get_histo_meter(options...)

It would return the exposure change needed to move the histogram to the top, bottom, or in between, or whatever options I could figure out. You would use it just like the get_shot_meter(..). For example, option 1 might move the histogram to the right (ETTR):

Tv=Tv+get_histo_meter(1)

The options could specify a target for the end point, and percentage of pixels allowable over or under the target. I suppose the target should be linear, and in percent of full range. It could go like this:

Tv=Tv+get+histo_meter(1,50)

This might mean that you want the brightest pixels to be 50% of the full camera range, i.e. the white level/2. This is 1 f-stop below clipping. You could do a similar thing for the darkest pixels. I.E. change the exposure so the darks are in range, i.e. exposure to the left.

The combination of the right and left exposed images might be all that's needed to produce an HDR image. If the two exposures were too far apart, you might need one in the middle.

Anyway, just updating my thoughts on where I'm going with the shot_histo research.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

lapser

1093

Continuous (burst) mode discoveries

« Reply #46 on: 12 / December / 2012, 13:30:11 »

I'm finding more and more advantages to using continuous mode for a time lapse. The fastest I can go in single shot mode is around 1 shot per second, by keeping half_shoot pressed, and using shoot_full_only. With continuous mode, you just keep shoot_full pressed the whole time. On my cameras, this yields around 2 shots per second. Other cameras have specs over 3 shots per second. Wow.

Another great thing about continuous mode that I just discovered is that the display shows the last picture! In single shot mode, the display goes blank while the camera is taking a picture. I think this is because the camera uses the display for pre-shot metering. At night, when you're taking long exposures, the screen is blank most of the time, with a short flash in between shots. You can't see what's happening. And by blank, I don't mean the back light is off. It's still draining power to show a dark screen.

But in continuous mode, the display shows a picture during long exposures. Try it with your camera in continuous shooting mode (with CHDK). Then take a series in single shot mode while holding half press between shots.

So continuous mode is ideal for time lapses, for speed and picture display. I can still adjust exposure between shots using the new get_shot_meter(..). The only problem is that you can't adjust the speed. The time lapse is ALWAYS 2 or 3 shots per second, even if you really want them 10 seconds apart. I can probably switch to single shot or get shoot_full_only to work with continuous mode, but I would lose the display part, and there's a jump from 1 shot per second up to 2 without the option of 1.5 seconds.

But from examining raw.c timing, I realized that you could add a precise delay in raw_save_file() that would work in continuous mode. In fact, there's already a delay before raw_save_file() is called to allow the exposure counter to update to the right file name. The comments note that this can slow down "burst" mode. But that's exactly what I want to do here.

But you don't want to let Lua just set a delay. If you set a delay of 10 minutes by mistake, the camera would hang for 10 minutes. Not good. Here's my idea:

set_shot_delay(enable) sets a 1 second delay.
set_shot_delay(disable) cancels delay in progress

if you don't call set_shot_delay(enable) again within 1 second, the delay times out and the shot continues. Or if you want the shot to continue immediately, use the disable option. It should be simple to code it in. I'll see how it works.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

waterwingz

12138

Re: Shot Histogram Request

« Reply #47 on: 12 / December / 2012, 15:11:25 »

Quote from: lapser on 12 / December / 2012, 13:30:11

But you don't want to let Lua just set a delay. If you set a delay of 10 minutes by mistake, the camera would hang for 10 minutes. Not good.

There are lots of ways to hang the camera while debugging a script. This would just be one more that needed to be debugged and fixed. I wouldn't waste any time trying to protect the programmer from this sort of mistake.

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #48 on: 12 / December / 2012, 17:11:47 »

Quote from: waterwingz on 12 / December / 2012, 15:11:25

There are lots of ways to hang the camera while debugging a script. This would just be one more that needed to be debugged and fixed. I wouldn't waste any time trying to protect the programmer from this sort of mistake.

That's a good point. Thanks for the input. The idea is also to make it easy to program.
[edit] What I mean by easy to program is that limiting the delay to 1 second would require the Lua programmer to write a loop, calling the delay routine every second (or faster), and compute the last time delay at the end. Whew! Why not just delay for 20 seconds, if that's what you want. raw_save_file is just going to call sleep() anyway.

I'm going to try a sunset time lapse tonight with the new program. I set up 4 meters, 1 in each quadrant of the total frame. I go through each meter and choose the one that recommends the least exposure: that is, the meter that produces the darkest picture. It'll be fun to see what happens. Gotta go.

« Last Edit: 12 / December / 2012, 23:39:27 by lapser »

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

lapser

1093

4 Meters Successful Test

« Reply #49 on: 12 / December / 2012, 23:33:08 »

The clouds and drizzle didn't cooperate, but the new 4 exposure meter experiment worked like a charm. I set up the Lua script to enable all 4 exposure meters. Then, after each shot, it went through all the meters and picked the one with the highest value, which was the brightest area. It used the value of that meter to adjust exposure, that is it added that meters value to Tv to get the new exposure.

The first shot the script does is the only one metered by the camera, with half_shoot. Lua reads the Tv from this shot, and used it as the starting Tv. Then, the Lua program simply adds the value from the highest meter to the starting Tv and sets this new Tv for the second shot. In this case, the upper right part of the sky was the brightest, so the program used that value. The upper 2 (sky) meters were about 3 Ev brighter than the lower 2 meters of the picture. The initial camera exposure was in between these two.

Here's the log data for the first four pictures:
Times (2 sec interval)
Meter # Meter Value (Tvd) || Shot Total || Tvd Tv Seconds
1 158 | 2 172 | 3 -158 | 4 -157 || 410 460 || 172 781 1/281
1 -13 | 2 0 | 3 -329 | 4 -331 || 320 1930 || 0 781 1/281
1 -13 | 2 0 | 3 -330 | 4 -331 || 320 2000 || 0 781 1/281
1 -14 | 2 0 | 3 -331 | 4 -331 || 320 2000 || 0 781 1/281

Here's what the first image, using the camera exposure, looked like. Note that for the first image, i drew the meter areas on the image in the raw buffer, so it shows up in the picture.

Here's the second image. Note the exposure is correct for the upper right quadrant (meter 2). Meter 2 was used to correct the exposure, so the other quadrants are underexposed. This is exactly what I wanted for a sunset time lapse. All that's missing is the sun.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos