Shot Histogram Request

waterwingz

12138

Re: Shot Histogram Request

« Reply #90 on: 26 / January / 2013, 18:08:49 »

Advertisements

Quote from: lapser on 26 / January / 2013, 18:05:27

OK, here's the current diff file.

Thanks - wasn't really expecting you to take time out to do this. I'll play with it this week after I get over the shock of doing the first pass through my 2012 taxes.

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #91 on: 27 / January / 2013, 14:51:56 »

http://www.youtube.com/watch?v=MQah7sksQaw#ws
I did another time lapse with the sx260 and g1x last night in the rain. I tried Saran (plastic) Rap and tape to protect the cameras from the rain. That worked pretty well, but some water still got on the lens. I put on one of those butterfly lens hoods on the G1X and that kept most of the water out. You can see me putting it on in the video.

The G1X did about 3,500 shots until the battery died. There was a sudden increase in brightness near the end, which I also noticed in my last test video (not uploaded). That could be in the script, or a bug in set_sv96(..). I'll figure that one out later.

The sx260 halted with an unspecified Lua error at about 1500 shots, giving only the "SCRIPT TERMINATED" message. This has happened before on both cameras while writing a log file, but this time I wasn't writing a log, so it must be related to something else.

Both cameras were in continuous mode, slowed down by the delay right before shutter open, set with set_shot_interval. The sx260 was set to 2000 msec, and the g1x 1500 msec. I have a possible answer, and solution:

My current get_shot_ready() function returns false until the shot meters and histogram are ready, and then returns true only once per shot. In continuous mode, you wait for get_shot_ready(), read the shot meters, set the exposure, and go back to waiting for get_shot_ready(). The problem is that get_shot_ready() has a timeout, which defaults to 100 msec. Normally, that's plenty of time, but occasionally, it starts timing out. I think the problem may be related to the script reading the shot meters while they're being computed for the next shot.

I realized that there's no need for a timeout in get_shot_ready(). It always returns immediately, so the script can implement a timeout if it wants to.

In continuous mode, the camera keeps shooting all the time. set_shot_interval(..) slows it down, but the shots can come fast and furious. The camera keeps up as well as possible by buffering shots. I think this is what the 2 raw buffers are for.

I think you can still set Sv96 and Tv96 during the delay in capt_seq_hook_set_nr(), but I'll have to test that more. It's taking awhile to figure out all these complications, but once I do, I should be able to keep up and meter exposure in continuous mode reliably at 2 shots per second or more.
====

I've also done some experiments with the histogram using a step size of 1, which samples the entire raw buffer. It takes about 16 seconds to do this, using get_raw_pixel(x,y). I just discovered that it only takes 1.5 seconds to go through (trash) the entire raw buffer using the raw buffer base address. A little in-line assembly code might even speed it up a little more.

I'm actually more interested in hot pixel removal in the raw buffer for long exposure night shots. It looks like 1.5 seconds is the minimum time it could take, which would be a big improvement over taking a dark frame every shot that doubles the time for each shot. Looks like another project for the future.

My latest shoot() bug idea got shot down in tests by skrytlen. I'll try to hold off until I can reproduce the bug on a camera that I can test myself.

Here's the test video I did last night from Skinner Butte in Eugene, Oregon, named after the city founder, Eugne Skinner. The highest spot in the background, towards the left, is Spencer's Butte, which is about 2,000 feet (600m) high. A lot of my other time lapse videos are taken from there.
[url=http://I did another time lapse with the sx260 and g1x last night in the rain. I tried Saran (plastic) Rap and tape to protect the cameras from the rain. That worked pretty well, but some water still got on the lens. I put on one of those butterfly lens hoods on the G1X and that kept most of the water out. You can see me putting it on in the video.

The G1X did about 3,500 shots until the battery died. There was a sudden increase in brightness near the end, which I also noticed in my last test video (not uploaded). That could be in the script, or a bug in set_sv96(..). I'll figure that one out later.

The sx260 halted with an unspecified Lua error at about 1500 shots, giving only the "SCRIPT TERMINATED" message. This has happened before on both cameras while writing a log file, but this time I wasn't writing a log, so it must be related to something else.

Both cameras were in continuous mode, slowed down by the delay right before shutter open, set with set_shot_interval. The sx260 was set to 2000 msec, and the g1x 1500 msec. I have a possible answer, and solution:

My current get_shot_ready() function returns false until the shot meters and histogram are ready, and then returns true only once per shot. In continuous mode, you wait for get_shot_ready(), read the shot meters, set the exposure, and go back to waiting for get_shot_ready(). The problem is that get_shot_ready() has a timeout, which defaults to 100 msec. Normally, that's plenty of time, but occasionally, it starts timing out. I think the problem may be related to the script reading the shot meters while they're being computed for the next shot.

I realized that there's no need for a timeout in get_shot_ready(). It always returns immediately, so the script can implement a timeout if it wants to.

In continuous mode, the camera keeps shooting all the time. set_shot_interval(..) slows it down, but the shots can come fast and furious. The camera keeps up as well as possible by buffering shots. I think this is what the 2 raw buffers are for.

I think you can still set Sv96 and Tv96 during the delay in capt_seq_hook_set_nr(), but I'll have to test that more. On thing that's taking so long is figuring out all these complications, but once I do, I should be able to keep up and meter exposure in continuous mode reliably at 2 shots per second or more.
====

I've also done some experiments with the histogram using a step size of 1, which samples the entire raw buffer. It takes about 16 seconds to do this, using get_raw_pixel(x,y). I just discovered that it only takes 1.5 seconds to trash the entire raw buffer using the raw buffer base address. A little in-line assembly code might even speed it up a little more.

I'm actually more interested in hot pixel removal in the raw buffer for long exposure night shots. It looks like 1.5 seconds is the minimum time it could take, which would be a big improvement over taking a dark frame every shot that doubles the time for each shot. Looks like another project for the future.

My latest shoot() bug idea got shot down in tests by skrytlen. I'll try to hold off until I can reproduce the bug on a camera that I can test myself.

Here's the test video I did last night from Skinner Butte in Eugene, Oregon, named after the city founder, Eugne Skinner. The highest spot in the background, towards the left, is Spencer's Butte, which is about 2,000 feet (600m) high. A lot of my other time lapse videos are taken from there.

Logged

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

pigeonhill

1155

Re: Shot Histogram Request

« Reply #92 on: 27 / January / 2013, 17:36:59 »

lapser

I assume you did no post processing deflickering? In other words your script ensures a sufficiently smooth transition during the day to night shooting? Do you do any ISO changes, or do you restrict yourself to only Tv changes?

Also, would you be prepared to share your script? I find looking at other scripts is a great way of learning more about CHDL/LUA scripting. I am still a novice 'scripter', but wishing to learn more.

Finally, are all the functions you use in the version you previously sent me for my S95 and G11? In other words the exposure adjustment calls?

Cheers

Garry

Logged

lapser

1093

Re: Shot Histogram Request

« Reply #93 on: 27 / January / 2013, 18:51:14 »

Quote from: pigeonhill on 27 / January / 2013, 17:36:59

I assume you did no post processing deflickering? In other words your script ensures a sufficiently smooth transition during the day to night shooting? Do you do any ISO changes, or do you restrict yourself to only Tv changes?

I made the video with the free program, Videomach, without processing the pictures. In fact, I left all the photos on the SD card, and output only the video file to the computer. Each picture is a frame. Using the shot meters to adjust exposure in 1/96 ev increments, combined with the high shot rate makes a very smooth time lapse, plus a very easy post production process. I think I tried auto white balance this time. That's where LRTimelapse would come in handy, because CHDK can't adjust white balance (yet).

The exposure changes are done in the script. This test script sets sv96 to 100 ISO, and adjusts tv96 until it gets to 1/2 second. Then it adjusts SV96 until it gets to 800 ISO. Then it goes back to tv96 up to 10 seconds. After that, things get dark fast.

My previous scripts used the brightness, bv96, to adjust the exposure as it got dark, to avoid overexposing, i.e. 192 ev96 down between +500 and -500 bv96. I haven't implemented that in this script yet, but it works pretty well.

Quote

Also, would you be prepared to share your script? I find looking at other scripts is a great way of learning more about CHDL/LUA scripting. I am still a novice 'scripter', but wishing to learn more.

My creative process is pretty messy, but I'll see if I can clean up the script a little and post it for you soon.

Quote

Finally, are all the functions you use in the version you previously sent me for my S95 and G11? In other words the exposure adjustment calls?

I've been changing things pretty fast, so it might be better to start with new builds. I'll post those with the script for you when I get something ready.

I just finished changing the get_shot_ready() function so it doesn't time out, and doesn't delay at all in single shot mode (not needed). I also changed the test for single shot mode from
single=get_drive_mode()~=1
to
single=get_drive_mode()==0

The G1X has a continuous drive mode with auto-focus that returns a drive mode of 2. Using a script, though, it doesn't always auto-focus. The first time I run this script, it does auto-focus:

Code: (lua) [Select]

--[[
@title Clapse
--]]
--MUST BE IN CONTINUOUS MODE
press("shoot_half")
repeat sleep(10) until get_shooting()
print("Holding shoot_full")
print("Press <menu> to exit")
press("shoot_full_only") -- continuous mode
repeat
  sleep(100)
until is_pressed("menu")

The second time I run it in continuous mode, it does NOT auto focus, although it does shoot continuously. Also, it seems to only focus with shoot_full_only, and not with just shoot_full.

I think there's code that releases all the keys when a script ends, so I haven't bothered to do it in restore(). I'm not sure this is working right on the G1X. Maybe Phil could take a look.

Logged

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

pigeonhill

1155

Re: Shot Histogram Request

« Reply #94 on: 27 / January / 2013, 19:31:22 »

Thanks

Logged

philmoz

3450

Re: Shot Histogram Request

« Reply #95 on: 28 / January / 2013, 02:09:56 »

Quote from: lapser on 27 / January / 2013, 18:51:14

The G1X has a continuous drive mode with auto-focus that returns a drive mode of 2. Using a script, though, it doesn't always auto-focus. The first time I run this script, it does auto-focus:
Code: (lua) [Select]
--[[ @title Clapse --]] --MUST BE IN CONTINUOUS MODE press("shoot_half") repeat sleep(10) until get_shooting() print("Holding shoot_full") print("Press <menu> to exit") press("shoot_full_only") -- continuous mode repeat sleep(100) until is_pressed("menu")The second time I run it in continuous mode, it does NOT auto focus, although it does shoot continuously.

Works fine on my G1X.
Possibly some other camera or CHDK setting might be interfering.
Try deleting or renaming your CCHDK2.CFG or CCHDK3.CFG file (depends on version you are running) and using the unmodified trunk or release version.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

lapser

1093

Re: Shot Histogram Request

« Reply #96 on: 28 / January / 2013, 15:40:21 »

Quote from: philmoz on 28 / January / 2013, 02:09:56

Works fine on my G1X.
Possibly some other camera or CHDK setting might be interfering.
Try deleting or renaming your CCHDK2.CFG or CCHDK3.CFG file (depends on version you are running) and using the unmodified trunk or release version.

Thanks Phil. I reformatted my SD card and started from scratch with the full version. The script worked before and after I applied my time lapse patches, so you were right (as usual).

I have the new get_shot_ready([enable]) working. The optional parameter [enable] refers to the post shot wait for the script to call get_shot_ready() again. get_shot_ready(0) never waits, get_shot_ready(1) always waits, and get_shot_ready() only waits in continuous mode. I changed the test for continuous mode to:
get_drive_mode()!=0 (mode 2 is continuous with auto focus on my cameras).

get_shot_ready(-1) ends the script wait, but doesn't reset the ready flag. This call can be used to let the shot processing continue after the time critical script code is finished, i.e. setting the new exposure.
====
One other new thing I just added is a minimum interval option based on shutter time.

set_shot_interval(interval [,imin ,nshots])

imin + shutter time is used if it is longer than interval. imin defaults to 0, which gives a 0 delay as it gets dark and the shutter time increases beyond the interval time. Setting imin >450 or 500 should keep the interval ahead of the shutter time a little, so there's always some delay and the interval increases smoothly as it gets darker, rather than being dependent on the variable shot processing time. This may be hard to understand, but it should result in a video whose speed accelerates smoothly as it gets dark. With imin>750 and an interval of 1000, there should be enough delay to keep the buffers from clogging up at too fast a shot rate in continuous mode. More testing is needed. If it doesn't work, I'll eat my shor... on second thought, not.

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 #97 on: 29 / January / 2013, 21:18:31 »

I tested the new time lapse changes yesterday at sunset with the G1X. My SX260 is all wrapped up and ready to mail back to Canon for warranty repair.

I also bought a floor model SX50 at Costco with a good discount. It looks like a nice camera. CHDK is being ported, with good progress. I haven't done anything with the camera except take a few pictures. I did notice that it holds manual focus when the display is turned off and back on, unlike the G1X. The viewfinder is electronic, while the G1X has an optical viewfinder.

Anyway, back to the G1X time lapse test. It took 2,800 pictures at 1 shot per second with logging without any problem. I used a 750 msec minimum interval plus shutter time. I need a better name for it besides minimum interval. But I think it helped keep the camera from backing up saving files to disk. The script wait time was always under 50 msec max. I did notice the screen printing lag behind a little sometimes. The camera would flash its busy signal during this time. But it always caught back up by the next shot.

I think I'm understanding what happens in continuous mode. There are two raw buffers used in continuous mode. The camera shoots as soon as a raw buffer is empty. It seems to take around 250 or 300 msec from shutter open to when the raw buffer is ready. Then the camera takes another shot immediately and puts it in the alternate raw buffer. It then waits until the raw data in the main buffer has been converted to jpg and saved to the SD card. As soon as the main buffer is clear, it takes the next shot into the main buffer. The 2 buffers allow a higher shot rate. In single shot mode, you can get about 1 shot per second. The 2nd buffer increases that to 2 shots per second, since shooting and filling the buffer are decoupled from the jpg conversion and file saving.

This presents a problem for my shot meter, though. The next picture is already taken, or waiting to be taken in my interval delay loop right before shutter open. It's not certain that the exposure changes calculated by the shot meter can be applied to the next shot. It appears to be a shot behind. The first two shots in the video, which I hold for 4 seconds each, show this. The first shot is metered by the camera, with the 4 metering areas drawn. The next shot is metered with the shot_meter from the first shot, but the exposure change didn't make it in time to be applied. So the second shot has the same exposure as the 1st shot. The 3rd shot shows an exposure change, probably computed from the first shot, but could be from the second shot. I'll have to fix this.

The problem is that the shot meter returns a relative value, not an absolute brightness. When you add the shot meter value to the current Tv96, the next shot should be properly exposed. It's important that the Tv96 used to take the metered shot is known, since that's the reference Tv96 for the meter. But it looks like the TV96 used for the current shot is taken from 2 shots back, not the last shot. With the light changing the script will over-correct based on 2 shots ago. The next shot, based on the brighter meter value 2 shots ago, will be underexposed. The meter sees that and over exposes the following shot. In other words, it might oscillate up and down one or 2 ev. I have seen this happening, but I thought it was from clouds going by or compression artifact.

So I'll have to save tv96, sv96 and av96 for each shot right before the shutter opens, and use these values to get an absolute Bv96 from the meter after the shot. This should also make the shot meter return value identical to the get_bv96() return value in the camera. get_shot_bv96() may be a more appropriate name if this works out, rather than get_meter_bv96().

I also noticed that there is a sudden brightness jump towards the end of the video again. This time I had a log file, and the brightness jump occurred when tv96 reached 0, or 1 second shutter time. It jumped immediately to 2 seconds. In the video, this means it gets suddenly brighter, and faster, since the shutter time is longer than the shot interval. But at least the speed of the video accelerates smoothly after that, as the shutter time increases to 6 seconds. The new code, where I base the minimum interval on the shutter time seems to work well, and gives a smoother speed increase than just letting the camera shoot as fast as it can. Plus, there were no script delays writing to disk, which I now think are caused by full file buffers. This seems to slow the camera to a crawl, so it's best to avoid it by slowing the shot rate.

I'm not sure what caused the sudden exposure jump from 1 to 2 seconds. I'm setting sv96 and tv96 using the built in routines in shooting.c modified to set immediately in half_shoot. I'm doing another test now using propcases in Lua to set sv96 and tv96 to see if the problem is with the modified routines in shooting.c.

Here's the video and attached log file of last night's test:

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

Skinner130128g1x.LOG (136.72 kB - downloaded 30 times.)

« Last Edit: 29 / January / 2013, 21:40:31 by lapser »

Logged

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

lapser

1093

Time Lapse Test using propcases to set exposure

« Reply #98 on: 30 / January / 2013, 00:25:59 »

This test uses propcases for exposure instead of the modified set_sv96(..) and set_tv96_direct that works immediately in half_shoot. I didn't see the sudden exposure change at 1 second, so there must be something wrong with one of these functions. My guess is set_sv96(..) is the culprit. There's a lot of code in there to set the base sv that just doesn't make much sense. set_tv96_direct just sets the propcases the same way I do in Lua, so it's probably not the problem.

I'll try modifying set_sv96(..) so it just sets 2 propcases and ignores the base. It gives the right exposure, which is what counts. The ISO speed is also correct, to the nearest Canon value, in the Exif data. Reyalp doesn't seem to want to fix anything in the exposure functions, so I may have to write a new function: set_sv96_correctly()

This test produced 3500 pictures in 2 hours, mostly at 1 shot per second. The script starts at 100 ISO until the shutter time goes to 1/2 second, increases to 800 ISO, and then increases the shutter to 10 seconds. The playback speed goes up at the end of the video as the shutter time exceeds the interval time. But I increased the minimum interval time based on shutter time to make sure there was a little delay between shots so the buffers don't back up. It worked. The delay between shots (idle delay) started at 600 msec with 1/100 shutter. This means that it could have gone at 2 shots per second and still have 100 msec delay left over.

However, as the shutter time increased, the idle time between shots dropped to 100 msec. This still kept the buffers running smoothly. The script wait time was 30-40 msec most of the time, with one 60 msec, but no higher. This is with writing 2 lines of log data per shot, so it looks good.

I tried to compare the script shot counter with get_exp_count(), and the script counter was 1 behind. I'll have to work on matching up the shot the meters measured, and the exposure used for that shot. Also, it would be nice to know the exposure number, i.e. the filename, that goes the exposure data.

This video always chose meter #1, the upper left quandrant, as the brightest meter. The meter values didn't really show oscillations, but they drop very slowly at 1 shot per second.

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

House130129.LOG (204.64 kB - downloaded 28 times.)

Logged

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

lapser

1093

Some new discoveries

« Reply #99 on: 01 / February / 2013, 14:17:49 »

I added a minimum delay of 100 msec in capt_seq_hook_nr() right before the shutter opens. I did another sunset time lapse last night, and the delay seemed to work to keep the file save buffers from filling up, as I hoped. The shot rate stayed constant, and the script processing times stayed in the 40 msec range.

But the script still halted with a script error, and when I re-started it, it halted again almost immediately. I then changed the delay to use the shutter time to set the minimum interval, and it didn't halt again. So it's related to certain timing conditions, and not the file write buffer full problem like I thought before.

Because the shutter opens and takes a shot on it's own in continuous mode, the script may be setting the exposure values (sv96 & tv96) at the wrong time, i.e. when the shutter is open. You might even have sv96 set, and tv96 missed, for example. Also, the exposure values used for the shot may be different from what they are by the time script reads the meters.

The exposure timing problem can be solved by setting exposure in capt_seq_hook_nr() right before the shutter opens. I tested this on the G1X, and setting tv96 at this time works. So I'll write a new function: set_exp96(sv,tv,av,nd) that sets the exposure right before the next shutter open. Then I can match up these values later when I'm computing the shot meter. Setting aperture and ND filter may require a delay afterwards, so I'll have to incorporate that too. Does anyone know a way to tell if the aperture and ND filter are ready? I'll have to experiment some more to figure this out.

I also need to return bv96 from the shot meter, not a deltaEv value. The script can then compute the correct exposure independent of the current exposure values. Also, I want to know bv96 so I can adjust exposure to get darker as the brightness goes down, i.e. underexpose at night.

Here's last night's time lapse at 30 fps made from 1 shot per second.

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

Logged

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