proposal - script shooting hooks - General Discussion and Assistance - CHDK Forum  

proposal - script shooting hooks

  • 290 Replies
  • 107565 Views
*

Offline reyalp

  • ******
  • 14080
proposal - script shooting hooks
« on: 31 / December / 2013, 01:36:57 »
Advertisements
This is inspired by lapsers continuous mode intervalometer stuff from http://chdk.setepontos.com/index.php?topic=8997.0

The basic idea is to let script pause the shooting process at various points, do something, and then tell shooting it can resume. So to shoot a fixed interval in continuous mode, you pause somewhere right before the exposure starts. To analyze the raw buffer, you pause in the raw hook.

The attached patch is a preliminary implementation of this. Unless there are major objections, I will check it into the trunk. The interface will still be subject to change, and I haven't tested it thoroughly yet.

There are currently 3 hooks defined (in order of execution)
'hook_override' - executes in shooting_expo_param_override, before overrides are applied. Can be used to adjust exposure settings after the camera has calculated it's own values.
'hook_remote' -  executes in  wait_until_remote_button_is_released. Can used to control the start of the exposure.
'hook_raw' - executes in raw_process, just after shot_histogram. It could be used to analyze or modify the raw buffer.

Each of the hooks provides a standard interface:
hook.set(timeout)
Enables the hook, so it will block the shooting process for up to timeout milliseconds. 0 disables the hook.
hook.is_ready()
returns true when the shooting process is in the hook
hook.continue()
allows the shooting process to exit the hook
hook.count()
tells you how many times the hook has been reached for this script. This allows you to tell if a particular point has been reached without actually blocking the process.

The attached script is a very simple continuous mode intervalometer using the remote hook to enforce the interval and the raw hook to adjust exposure. The exposure calculation is purely as an example. Lapsers code has much more sophisticated metering, which is something that can and should be added separately. Another thing that should be added is functions to read and write the raw buffer in the raw hook.

some issues and questions
A few ports may call shooting_expo_param_override more than once. The current code will just call the hook multiple times. Affected cameras include A1000 (but I'm not sure if it's in the same code path) and ixus1000 which does it for two subs out of four :-[

I vaguely remember there being some cameras without the remote hook too.

The names are confusing, especially remote. I'm open to suggestions.

Would it be desirable to have a post-raw save hook?

I originally intended to have a hook.wait_ready() which would do the equivalent of
while not hook.is_ready() do sleep(10) end
in the action stack.

Should there be a way to detect timeouts?
Don't forget what the H stands for.

Re: proposal - script shooting hooks
« Reply #1 on: 31 / December / 2013, 10:00:24 »
The basic idea is to let script pause the shooting process at various points, do something, and then tell shooting it can resume. So to shoot a fixed interval in continuous mode, you pause somewhere right before the exposure starts. To analyze the raw buffer, you pause in the raw hook.
This is very cool.  The possibilities this opens up are going to be a lot of fun.  Too bad we can't go back over all the forum posts were we had to tell people what they wanted was not scriptable and needed changes to the core C code.  :(

Quote
The attached patch is a preliminary implementation of this. Unless there are major objections, I will check it into the trunk.
Yes please.


Quote
A few ports may call shooting_expo_param_override more than once. The current code will just call the hook multiple times. Affected cameras include A1000 (but I'm not sure if it's in the same code path) and ixus1000 which does it for two subs out of four :-[
Porting error or valid reason?  I'd guess the former - I wonder if a PM to the original porting person would work. Those are both pretty old cameras.   I'm thinking anyone using these functions can probably safely ignore handling the multiple hook calls and we fix the actual port if someone complains?

Quote
I vaguely remember there being some cameras without the remote hook too.
IIRC correctly,  there were originally four and srsa_4c has fixed three of those?  I'll check.

Quote
The names are confusing, especially remote. I'm open to suggestions.
I agree that hook_remote is confusing (unless you know the hook is where the USB remote pauses for sync) but the other two seem okay to me.  How about changing hook_remote to hook_shot or hook_shoot ?

Quote
Would it be desirable to have a post-raw save hook?
Not sure it would help with deleting the jpg (?) but you never know what it might be useful for if it's not a big deal to add.

Quote
I originally intended to have a hook.wait_ready() which would do the equivalent of while not hook.is_ready() do sleep(10) end in the action stack.
Seems useful - why did you give up on it?

Quote
Should there be a way to detect timeouts?
That would be nice ... especially during the script testing phase.  (assuming this is a seperate question than the previous quote).

Thanks for doing this!
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14080
Re: proposal - script shooting hooks
« Reply #2 on: 31 / December / 2013, 14:47:45 »
hook_shot or hook_shoot
I thought about that, but they are all kind of shot related.

Hmm. Maybe hook_shutter or hook_preshutter.

Quote
Quote
I originally intended to have a hook.wait_ready() which would do the equivalent of while not hook.is_ready() do sleep(10) end in the action stack.
Seems useful - why did you give up on it?
Because I had a working implementation without it, and then wasn't sure if it was worth adding.

However, I think there's value because the script side should also probably have a timeout. Using the above code, script would just wait forever if shooting wasn't triggered for some reason. The timeout in set() refers to the hook waiting for script to release it. Obviously you could timeout the script side that in lua, but it would be start to be a lot of code for every wait. I guess it could be a lua lib. Running it in the action stack might be slightly faster.

A few notes:
The "remote" hook runs before the actual wait for the remote signal. I'm not sure if it would ever make sense to use the actual remote with this hook, but if the script wanted to do something after the USB signal was sensed, it could just do it using get_usb_power(). Anything involving script would negate the fast response anyway.

Similarly, I put the "override" before CHDK normal overrides, so the script could adjust them. With the get_shooting / set_now logic this doesn't matter for most settings, but I don't see any good reason for it to run after.

I haven't included ubasic support, but there's no reason it couldn't be added.
Don't forget what the H stands for.

Re: proposal - script shooting hooks
« Reply #3 on: 31 / December / 2013, 15:00:26 »
A few notes:
The "remote" hook runs before the actual wait for the remote signal. I'm not sure if it would ever make sense to use the actual remote with this hook, but if the script wanted to do something after the USB signal was sensed, it could just do it using get_usb_power(). Anything involving script would negate the fast response anyway.
The only reason the remote hook exists if for shot synchronization between two or more cameras.  The last thing needed after the hook is anything that would vary the time from that point to shutter release.  I can't think of any reason someone would want to insert script code between the 5V USB falling and the shutter opening.

Quote
Similarly, I put the "override" before CHDK normal overrides, so the script could adjust them. With the get_shooting / set_now logic this doesn't matter for most settings, but I don't see any good reason for it to run after.
That whole priority of overrides probably needs to be clarified somewhere.  Right now I believe script overrides beat out menu ones?

Quote
I haven't included ubasic support, but there's no reason it couldn't be added.
Seem like anyone writing something that needs a shooting hook is not going to be using uBASIC by choice ...
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline reyalp

  • ******
  • 14080
Re: proposal - script shooting hooks
« Reply #4 on: 31 / December / 2013, 15:25:46 »
That whole priority of overrides probably needs to be clarified somewhere.  Right now I believe script overrides beat out menu ones?
Right, script beats menu.
But in this context, "overrides" would also includes previous script settings with SET_LATER. Hmmm. In this case it could be confusing, if the script did say
set_tv96 before half shoot (creating a set_later)
hook does a set_tv96 (which becomes a set_now, since get_shooting is true at that point)
previous set_later gets applied right after the hook.

One could argue that the first set_tv96 was dumb, but it's unintuitive that an earlier call would beat a later one.

So maybe it makes more sense to do it after? Would there be any disadvantage? It would let you manipulate CHDK bracketing or auto-iso values, if you wanted.

Adding hooks is very easy and doesn't cost much so we could have both, but that might just be more confusing.

The above applies to the current code as well, if you set both outside and inside half shoot. Or a SET_NOW should clear any SET_LATER values, but I'm not sure I want to get into that.

ISO also needs investigation for cameras that have a standalone shooting_expo_iso_override. It looks like this gets called before the regular shooting_expo_param_override, so probably won't work from the hook.

edit:
The ISO issue also probably applies to the existing logic for using SET_NOW when get_shooting() is true.
« Last Edit: 31 / December / 2013, 16:36:24 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14080
Re: proposal - script shooting hooks
« Reply #5 on: 01 / January / 2014, 18:18:13 »
Checked in, changeset 3301

Note this is in development, functionality and interfaces may change. That's why we have a development branch. It should not impact stability of the trunk when the hooks are not used.

Changes from the initial post:
Hooks renamed
hook_override -> hook_preshoot
hook_remote -> hook_shoot

hook_preshoot now executes after the CHDK override code.

Updated test script attached.
Don't forget what the H stands for.

Re: proposal - script shooting hooks
« Reply #6 on: 13 / January / 2014, 23:31:01 »
So I guess a CHDK wiki page write-up linked to the xref page is in order? 

Added to my "round-tuit" list.   Just before the one about "merge all the scripting references into sub-pages below the xref page,  sorted by section in the xref page to avoid any one page being too long".

Only so many hours in a day .. sigh. 

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14080
Re: proposal - script shooting hooks
« Reply #7 on: 19 / May / 2014, 00:10:18 »
Don't forget what the H stands for.


Re: proposal - script shooting hooks
« Reply #8 on: 19 / May / 2014, 07:02:35 »
I added some documentation http://chdk.wikia.com/wiki/Script_Shooting_Hooks
Thanks for that.  Every so often I think about these hooks and try to come up with a cool idea for what to do with them.   Your recent improvements to the HDR script is good.  But not a lot of coolness factor.  8)
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: proposal - script shooting hooks
« Reply #9 on: 15 / June / 2014, 02:55:36 »
Hadn't had time to look at this before; but seems like a really cool feature.

Random thought - would it be possible to register a function name in the script that the hook code could then 'call'.
Not sure if it's possible; but it might make the scripting easier and avoid the state tests in the main loop.

Phil.
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)

 

Related Topics