Improvements to press, click, release for shooting keys

philmoz

3450

Re: Improvements to press, click, release for shooting keys

« Reply #40 on: 02 / January / 2013, 04:16:04 »

Advertisements

Quote from: lapser on 02 / January / 2013, 04:03:49

But you don't need to wait for shutter_open_tick_count to change, which may not work for all cameras. Instead, you can wait for state_shooting_progress to change, which is already in AS_WAIT_SAVE. But instead of waiting for:
if (state_shooting_progress == SHOOTING_PROGRESS_DONE)
you wait for:
if (state_shooting_progress != SHOOTING_PROGRESS_NONE)

If you move the AS_WAIT_SAVE to go between the press and release, it should work.

AFAIK this will just move the point where it may hang.

The state_shooting_progress variable is set in raw_savefile - if the firmware decides that the shot cannot be taken for whatever reason then raw_savefile will never get called and state_shooting_progress will be stuck at SHOOTING_PROGRESS_NONE.

This is why my fix checks shooting_in_progress() instead - if the camera can't take the shot then this will go back to 0 when the shutter is released (after the missed shot).

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: Improvements to press, click, release for shooting keys

« Reply #41 on: 02 / January / 2013, 05:15:50 »

Quote from: philmoz on 02 / January / 2013, 04:16:04

AFAIK this will just move the point where it may hang.

Ye of little faith! Let's see if the test fixes the bug or not, i..e. doesn't hang AND doesn't miss shots. If my fix hangs or misses shots, and I can't figure out how to get it working, then maybe you're right.
http://chdk.setepontos.com/index.php?topic=9118.msg95189#msg95189

Quote

if the firmware decides that the shot cannot be taken for whatever reason...

Yes, I understand how your fix works. But I don't think the firmware decides the shot cannot be taken "for whatever reason." As I've described in perhaps too much detail, the firmware decides to take a shot if the shutter button is down when it finishes the last shot and is ready for the next shot. The current shoot() code has the possibility it could release the shoot button BEFORE the camera is ready to take the next shot. There also might be a camera requirement that the shoot button has to be down for a certain period of time to take a shot. This helps prevent inadvertent shots from "key bounce".

Maybe get_shooting() goes true before the camera is finished focusing, and the shutter is up by the time it's really ready. The combination of focusing and flash charging may change the timing. You're counting on the camera being ready to shoot immediately after get_shooting() goes true. I don't think you can count on that.

Let's work together and figure this out, Phil. We're not in competition here. With your knowledge of CHDK task processing, maybe you have a better way to test if the camera started the shot, i.e. before shutter open, and that works on all cameras. Let's find a better way to do this than skipping shots, and figure out what's happening instead of "whatever reason."

I don't think it will be necessary, but we could add a timeout to my code if needed. My changes also make shoot() work at 1 shot per second with shoot_full_only. That's a significant capability, but it only works by holding shoot_full until the camera takes the shot.

Your method stops the hanging, but doesn't really solve the problem. But together, we can figure it out.

Logged

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

lapser

1093

Stay off my lawn

« Reply #42 on: 02 / January / 2013, 12:09:31 »

I stepped back and tried to look at this from the other perspective, and I realize I'll have to accept the "stay off my lawn" signs. Missed and irregular shots aren't acceptable for my time lapse purposes, but they are a big improvement over hanging the script completely. Specifically, the focus bracketing problem is solved by Phil's mod, since missed shots don't matter in that application, or most other ones. But shots that hang are a problem in all applications.

So from now on, I'll confine my changes to separate Lua functions, and not suggest any modifications or change the behavior of existing CHDK functions. I'll be writing my own shoot function. I'll call it:

shoot_lapser(shot_interval)

No wait, that doesn't sound good, maybe:

shoot_or_hang()

I guess I'll have to think of a better one.

Logged

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

reyalp

14118

Re: Improvements to press, click, release for shooting keys

« Reply #43 on: 02 / January / 2013, 15:53:08 »

Quote from: lapser on 02 / January / 2013, 05:15:50

Yes, I understand how your fix works. But I don't think the firmware decides the shot cannot be taken "for whatever reason." As I've described in perhaps too much detail, the firmware decides to take a shot if the shutter button is down when it finishes the last shot and is ready for the next shot.

It would be unwise to assume there's only one way shooting can fail.

As a general thought, it would probably be useful to come up with a way for the various shoot() stages to time out. We have encountered this problems in various forms a number of times. While it would be better to shoot if possible, timing out gracefully would definitely be an improvement over hanging.

Quote

The current shoot() code has the possibility it could release the shoot button BEFORE the camera is ready to take the next shot. There also might be a camera requirement that the shoot button has to be down for a certain period of time to take a shot. This helps prevent inadvertent shots from "key bounce".

All these "may" and "mights" would benefit from controlled testing. Not just "it seems to fix the problem" but actually verifying that the presumed cause triggers the symptom in question. The camera log http://chdk.wikia.com/wiki/Debugging#Logging_camera_console_output can be useful for verifying the timing of things like this. I frequently speculate about what the camera is doing under the hood and... if I had a dollar every time I was wrong, I'd be quite wealthy

Quote

So from now on, I'll confine my changes to separate Lua functions, and not suggest any modifications or change the behavior of existing CHDK functions.

I hope this is in jest. Heated technical discussions frequently result in something better than any of the individual contributors would have done on their own.

Logged

Don't forget what the H stands for.

lapser

1093

Re: Improvements to press, click, release for shooting keys

« Reply #44 on: 02 / January / 2013, 23:39:41 »

Quote from: reyalp on 02 / January / 2013, 15:53:08

It would be unwise to assume there's only one way shooting can fail.

That's for sure! The shooting problem may be related to failure to focus, or the timing of set_focus commands. As you said, different cameras act differently.

Quote

As a general thought, it would probably be useful to come up with a way for the various shoot() stages to time out.

I did test adding a timeout, and it worked. At the start of a shoot_full press, I added the current tick count to the timeout value and stored this as the timeout tick count. It worked, but it created some interesting Lua "bugs" that were hard to figure out, when it timed out.

Quote

All these "may" and "mights" would benefit from controlled testing.

Yes, I've already filled up a lot of log files. But it's really hard to test a problem that happens 1 in 100 times you shoot(), that you can't reproduce on your camera. I like to think up a theory, test, and modify the theory, i..e. the scientific method. When I'm working on a project, I always seem to wake up in the morning with a new theory to test. Thanks for the link.

Quote

Quote
So from now on, I'll confine my changes to separate Lua functions, and not suggest any modifications or change the behavior of existing CHDK functions.
I hope this is in jest. Heated technical discussions frequently result in something better than any of the individual contributors would have done on their own.

That does sound a little like I'm going to "Take My Marbles and Go Home" That's not what I meant. I was referring to not changing the CHDK shooting keys or current shoot() function. For my high speed shooting with exposure correction to work, I need the keys and shoot function to behave differently. You convinced me that it's too risky to change the key functions, so I decided to stick to separate functions just for my time lapse for now. And I've certainly learned a lot from this discussion.

Logged

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

lapser

1093

Re: Improvements to press, click, release for shooting keys

« Reply #45 on: 03 / January / 2013, 15:53:48 »

OK, here's a suggestion for improving philmoz's shoot() modification. If shoot() fails , try it again before returning to the script. I bet it would work on the second try, and you wouldn't need a return value to say it worked, or all the logic in the script to check for failure. If it didn't work on the 2nd try, it probably would never work, so it wouldn't be useful for the script to check a return value and try again anyway.

It would be dirt simple to program. Define int did_shoot=0. It needs to be reset in script.c to be safe. At the beginning of AS_SHOOT, check did_shoot. If it's 1, reset it to 0 and return (no need for error return). At the end of AS_SHOOT, set did_shoot=0 if successful. If unsuccessful, set did_shoot=1, and push AS_SHOOT again.

You could have skrylten check it with the focus/flash script and see if it still missed shots before taking the error return out.

http://chdk.setepontos.com/index.php?topic=9118.0

[EDIT] Tested and works. It's actually easier than described here (see next post)

« Last Edit: 09 / January / 2013, 15:38:29 by lapser »

Logged

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

lapser

1093

Improvement to shoot() function bug fix

« Reply #46 on: 09 / January / 2013, 15:20:47 »

As described in my last post, a better way to fix the shoot() hang bug is to re-shoot instead of returning an error code. Here's the change to the current philmoz fix:

Code: [Select]

//current version
331	static void action_stack_AS_WAIT_SAVE() 
332	{ 
333	    if (!shooting_in_progress()) 
334	    { 
335	        action_pop_func(); 
336	        if (libscriptapi) 
337	            libscriptapi->set_as_ret((state_shooting_progress == SHOOTING_PROGRESS_NONE) ? 0 : 1); 
338	    } 
339	} 

//improved version
331	static void action_stack_AS_WAIT_SAVE() 
332	{ 
333	    if (!shooting_in_progress()) 
334	    { 
335	        action_pop_func(); 
336	        if (state_shooting_progress == SHOOTING_PROGRESS_NONE) 
                {
                     action_push(AS_SHOOT); //re-shoot
                     action_push_delay(100); //delay before re-shoot?
                }
338	    } 
339	}

Tested and works without script changes:
http://chdk.setepontos.com/index.php?topic=9118.msg95324#msg95324

« Last Edit: 09 / January / 2013, 15:24:11 by lapser »

Logged

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

reyalp

14118

Re: Improvements to press, click, release for shooting keys

« Reply #47 on: 11 / January / 2013, 00:16:55 »

If you re-shoot indefinitely, then you may just end up making the script hang by repeatedly trying and failing to shoot.

I'm not really sold on the idea of re-trying at all. Shoot failing is an error condition, returning control to the script seems more appropriate to me than trying to second guess. The script could easily try to shoot again, where hard-coding the re-shoot makes the actual behavior more unpredictable. Fixing or identifying the conditions that cause shoot to fail and addressing those seems like a much more useful place to put effort.

Logged

Don't forget what the H stands for.

lapser

1093

Re: Improvements to press, click, release for shooting keys

« Reply #48 on: 11 / January / 2013, 06:53:06 »

Quote from: reyalp on 11 / January / 2013, 00:16:55

If you re-shoot indefinitely, then you may just end up making the script hang by repeatedly trying and failing to shoot.

I think the best solution is this fix, and if anyone reports that it hangs re-shooting over and over, we can add an error return. I'd be very surprised if this ever happens. It would almost be a "shorts eating event."
http://news.bbc.co.uk/2/hi/programmes/newsnight/9598802.stm

skrylten reports that this fixed his problem with one re-shoot (I printed a re-shooting message). The bug only happens on the 2nd shoot(), so the script is probably in a loop that will fail to shoot repeatedly anyway.

Quote

I'm not really sold on the idea of re-trying at all. Shoot failing is an error condition, returning control to the script seems more appropriate to me than trying to second guess. The script could easily try to shoot again, where hard-coding the re-shoot makes the actual behavior more unpredictable. Fixing or identifying the conditions that cause shoot to fail and addressing those seems like a much more useful place to put effort.

I'll change it to re-shoot once and then error return, and if it works, post the change here. Then you can pick which one you want to use. Re-shooting worked on the first try for skrylten, so that should fix his problem, and fix any old scripts too. I think it will make the shoot() function reliable enough to use again. The current recommendation seems to be to use press/release because shoot() is unreliable.

I'd love to figure out the cause, but I've never had the failure on my cameras. When I finish the time lapse changes, I'll see if I can reproduce the bug on my camera or a borrowed camera and try to figure it out.
===
Speaking of time lapse changes, would you like me to post a diff of just the changes to set_tv96_direct() and similar functions so they use SET_NOW in half_press instead of SET_LATER, as we discussed? I think this should definitely be in the trunk, since it adds the ability to meter and then adjust exposure for the next shot without having to release half_shoot and needlessly re-meter.

Logged

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