Shot Histogram Request

lapser

1093

Re: Shot Histogram Request

« Reply #340 on: 16 / August / 2013, 18:34:28 »

Advertisements

Here's the time lapses I got while I was up at McKenzie Pass (Dee Wright Observatory) overnight during the meteor shower.

I used external power adapters for the SX50 and G1X. I also set up the SX260 with external power using a USB battery overnight. I accidentally unplugged it and had to restart it again. Then I left it on all night, until the external battery shut down. When I got home, I discovered that all of the pictures with the camera powered by the external battery WERE LOST! I don't remember this ever happening with the G1X, but that external battery lasts so long I've never had it shut down. I don't think it even has a shut down, so maybe the camera shuts itself down normally when the voltage gets too low.

Has anyone else lost all their pictures with a sudden loss of external power. I wonder if that happens if you open the battery door after taking some pictures. But here's what I did get:

http://www.youtube.com/watch?v=E08y-vxlnhI#

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

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

There's an interesting, small moving white object in the lower left corner just before the end of the video. It lasts for about 20 minutes in real time, so it's not a meteor. I'm pretty sure it's an airplane reflecting the setting sun.
http://www.youtube.com/watch?v=96Qivk4qKDc#

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

Logged

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

waterwingz

12132

Re: Shot Histogram Request

« Reply #341 on: 16 / August / 2013, 19:27:36 »

Quote from: lapser on 16 / August / 2013, 14:34:56

I think we have a basic difference in how we look at CHDK. I see it more as a platform for writing Lua functions. This is similar to the way smart phones are set up, i.e. as a platform for apps. Simple C functions that make it easier to program scripts in Lua are very worthwhile.

I don't think I have ever suggested anything that contradicts what you have said here, and I don't believe we have a basic difference in how we look at CHDK. We might be at odds on the definition of "simple" though.

Quote

The other reason I wrote set_exp96() is that the code for set_sv96() doesn't work correctly all the time. I had several large glitches in the exposure when using set_sv96().

I've seen those glitches too - the exif info is normal and consistent with the previous and following shot. But the image itself is massively overexposed.

However, in my previous response, I did not suggest using the set_xx96() functions. I did however point out that your set_exp96() function just does a sequence of set_prop() commands in C rather than in Lua. Nothing gained there over just implementing the function in Lua (except for the one line of code that sets your wait_script semaphore at the end of the function - more on that below).

Quote

Another important thing that set_exp96 does is signal chdk to abort the post shot script delay and let the camera go on to the next shot in continuous mode. I could do this by adding a parameter to get_shot_ready() so it aborts the delay without resetting the ready flag, but this is a little confusing.

One fundamental belief I have about writing good functions (per your first point above) is to maximize cohesion and minimize coupling. The use of wait_script in your various functions works, but creates a lot of coupling between functions.

Where to from here then? I think the shot_meter() concept is really good and will make a good extension to CHDK core. As I posted elsewhere, the APEX96 functions in some form needs to be made available to Lua and uBASIC. And some method of managing "SET_NOW" vs "SET_LATER" needs to be considered. How this gets coded is secondary to the best method to integrate this functionality into CHDK.

« Last Edit: 16 / August / 2013, 20:01:24 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #342 on: 16 / August / 2013, 20:27:43 »

Quote from: waterwingz on 16 / August / 2013, 19:27:36

I've seen those glitches too - the exif info is normal and consistent with the previous and following shot. But the image itself is massively overexposed.

That's what I saw too. The propcase method I discovered (see above) has never shown any glitches. Why don't we throw away the entire current set_sv96(sv) and try my method?

Quote

However, in my previous response, I did not suggest using the set_xx96() functions. I did however point out that your set_exp96() function just does a sequence of set_prop() commands in C rather than in Lua. Nothing gained there over just implementing the function in Lua (except for the one line of code that sets your wait_script semaphore at the end of the function - more on that below).

This is what I think the difference between us is. To me, it's well worth it to add a short C function that sets the propcases in a camera independent manner, that's easier to understand and use. Using propcases in Lua is complicated, hard to figure out, memory inefficient, and slower. It works, but it makes for complicated scripts that are hard to follow.

But my when() function worked well for me, and was my preferred solution if set_sv96() is fixed. If we do that, I can get rid of set_exp96() and use a different semaphore. I initially was using get_shot_ready(0), or something like that. Adding the when() function and fixing set_sv96() would be better than set_exp96().

While we're at it, how about if we fix set_tv96() and set_av96(). They're useless now, because they do nothing if the input parameter isn't a valid camera dial setting. They should always set the exposure to something, i.e. the nearest valid camera setting? I would never use it myself, but it would make the actual exposure match the EXIF data, I suppose. Others might find that useful.

Logged

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

philmoz

3445

Re: Shot Histogram Request

« Reply #343 on: 16 / August / 2013, 21:15:58 »

Quote from: lapser on 16 / August / 2013, 20:27:43

Quote from: waterwingz on 16 / August / 2013, 19:27:36
I've seen those glitches too - the exif info is normal and consistent with the previous and following shot. But the image itself is massively overexposed.
That's what I saw too. The propcase method I discovered (see above) has never shown any glitches. Why don't we throw away the entire current set_sv96(sv) and try my method?

The ISO code has already been rewritten - http://chdk.setepontos.com/index.php?topic=10341.msg103282#msg103282

Quote

Quote
However, in my previous response, I did not suggest using the set_xx96() functions. I did however point out that your set_exp96() function just does a sequence of set_prop() commands in C rather than in Lua. Nothing gained there over just implementing the function in Lua (except for the one line of code that sets your wait_script semaphore at the end of the function - more on that below).
This is what I think the difference between us is. To me, it's well worth it to add a short C function that sets the propcases in a camera independent manner, that's easier to understand and use. Using propcases in Lua is complicated, hard to figure out, memory inefficient, and slower. It works, but it makes for complicated scripts that are hard to follow.

But my when() function worked well for me, and was my preferred solution if set_sv96() is fixed. If we do that, I can get rid of set_exp96() and use a different semaphore. I initially was using get_shot_ready(0), or something like that. Adding the when() function and fixing set_sv96() would be better than set_exp96().

While we're at it, how about if we fix set_tv96() and set_av96(). They're useless now, because they do nothing if the input parameter isn't a valid camera dial setting. They should always set the exposure to something, i.e. the nearest valid camera setting? I would never use it myself, but it would make the actual exposure match the EXIF data, I suppose. Others might find that useful.

In progress.

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)

waterwingz

12132

Re: Shot Histogram Request

« Reply #344 on: 16 / August / 2013, 21:54:05 »

Patch file for just the shot_meter & shot_histogram functions. Stripped out the last of the NOW & LATER stuff - that belongs in a different patch.

I think this is "clean" now.... thanks once again to lapser for sharing this.

shot_histo_v2.patch (29.29 kB - downloaded 25 times.)

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3445

Re: Shot Histogram Request

« Reply #345 on: 16 / August / 2013, 22:33:31 »

Quote from: waterwingz on 16 / August / 2013, 21:54:05

I think this is "clean" now....

Only had time for a quick look; but noticed the following:
- shot_histogram.h has lost the warning comment on use in modules/platform independent code
- wait_click behaviour is changed, wait_click(1) now does not wait at all (this may be ok; but may also break existing scripts, it also adds yet another magic number meaning to the function parameter)
- call to script_print_screen_statement(0) in lua_script_error is not needed (script_end already calls script_print_screen_end)

Phil.

Logged

waterwingz

12132

Re: Shot Histogram Request

« Reply #346 on: 16 / August / 2013, 22:56:57 »

Quote from: philmoz on 16 / August / 2013, 22:33:31

Only had time for a quick look; but noticed the following:
- shot_histogram.h has lost the warning comment on use in modules/platform independent code
- wait_click behaviour is changed, wait_click(1) now does not wait at all (this may be ok; but may also break existing scripts, it also adds yet another magic number meaning to the function parameter)
- call to script_print_screen_statement(0) in lua_script_error is not needed (script_end already calls script_print_screen_end)

Thanks - I guess "clean" is a relative term. As in "compared to where I started" with this. And lapser has never pretended for one moment that the patch file he posted at my request was anything but a "work in progress".

Still, it gets us his "shot_meter" code - which is more useful for actual exposure control and adjustments of APEX96 values than the SDM readYUV "spot meter" function that I found linked here. That function turns out to be a wrapper of the standard motion detect code that reads the LCD buffer. A CHDK Lua or uBASIC version is a one line function. Very handy to get relative values in real time but not much help with working with actual APEX96 exposure values from the RAW image data. Lapser's code lets you use the returned value directly in APEX96 calculations - very nice!

« Last Edit: 16 / August / 2013, 23:41:11 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

Re: Shot Histogram Request

« Reply #347 on: 17 / August / 2013, 01:36:41 »

Quote from: waterwingz on 16 / August / 2013, 21:54:05

I think this is "clean" now....

Thanks for working on this! I feel a little like you're tearing apart my baby, but if that's how you want to get it into the trunk, that's fine with me.

Quote from: philmoz on 16 / August / 2013, 22:33:31

- shot_histogram.h has lost the warning comment on use in modules/platform independent code

Did I do that? That was unintentional

Quote

- wait_click behaviour is changed, wait_click(1) now does not wait at all (this may be ok; but may also break existing scripts, it also adds yet another magic number meaning to the function parameter)

That doesn't need to be there any more if you're worried about it. I put it in when you changed the behavior of wait_click(0), as I recall, but I don't use it now.

Quote

- call to script_print_screen_statement(0) in lua_script_error is not needed (script_end already calls script_print_screen_end)

While trying to trigger the "Lua bug", I left the camera running until the battery ran down. After a lua error, the error message sits there with Lua still running, so it never closed the log file and I lost the error message when the battery died. Of course, if the battery dies with Lua running without an error, the log isn't closed either, but there's not much to do about that.

Logged

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

waterwingz

12132

Re: Shot Histogram Request

« Reply #348 on: 17 / August / 2013, 08:27:56 »

Quote from: lapser on 17 / August / 2013, 01:36:41

Thanks for working on this! I feel a little like you're tearing apart my baby, but if that's how you want to get it into the trunk, that's fine with me.

When you have a minute, you might find this interesting :

the ten commandments of egoless programming

Its been reprinted many times online and still holds true many decades later.

Logged

Ported : A1200 SD940 G10 Powershot N G16

lapser

1093

For Siavash Kanani

« Reply #349 on: 18 / August / 2013, 03:43:51 »

Attached is a custom CHDK build with the time lapse mods, and the Tlapser.lua script that works with it.

Unzip the CHDK build and copy it to the root of your SD card that already has CHDK. Make sure you copy all the files and folders, overwriting any files and folders that are already there.

Your version of CHDK is pretty old, but this should update it to a more recent version. You have to set the write protect tab on the card before inserting it into the camera so it auto-boots, for the modified version to load (not the firmware update method of loading). If this doesn't work, try loading the latest CHDK full version 1.3 from the main website, and then add the attached custom version.

Then, try running the Tlapser.lua script. Hopefully, you can figure out what the input parameters mean and how to set the metering areas. I haven't gotten to documenting it yet.

Mr. Kanani found out about the time lapse mods from YouTube:

http://www.youtube.com/watch?v=E08y-vxlnhI#

TLapser.lua (10.13 kB - downloaded 21 times.)

sx50hs-100c-1.3.0-r2995.zip (282.93 kB - downloaded 21 times.)

Logged

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