Mini burst

[a1ex]

I was just browsing around Canon Rumors and found this idea from Marsu42.

Here's a quick code snippet (coded in 5 minutes) that implements it, maybe somebody can turn it into something a little more useful. You may call it from shoot_task.

Code: [Select]

static void mini_burst_step()
{
    int hs = get_halfshutter_pressed();
    static int phs;
   
    /* did you just press the shutter? (well, halfway, since that's what we can check) */
    if (hs && !phs)
    {
        /* limit the burst to X pictures */
        int number = 3;
       
        /* keep monitoring while you keep the shutter pressed; one you took X pictures, stop */
        int f0 = get_shooting_card()->file_number;
        while (mod(f0 + number - get_shooting_card()->file_number + 10, 10000) > 10 && get_halfshutter_pressed()) {
            msleep(10);
        }
       
        /* if you are still keeping shutter halfway pressed, force a fake "unpress", which will stop taking pictures */
        if (get_halfshutter_pressed())
        {
            SW2(0,100);
            SW1(0,100);
        }
    }
   
    /* update previous half-shutter state */
    phs = hs;
}


[Audionut]

I did this on my first wedding as lead.

Killed card space in 33% of the time and ended up with 66% useless shots.

Spray and pray 

[a1ex]

Spray and pray 

In many programming contests, this was actually a good way to score points if you didn't know how to solve a problem.

Example: let's say your program is allowed to run 1 second. Try random solutions for the first 0.9 seconds and print the best you could find.

(of course, there is a theoretical background about these random methods: http://en.wikipedia.org/wiki/Stochastic_optimization )

[Audionut]

In that case, the first 0.9s of random guessing was useful and didn't generate workload.
If you had to find the solution by hand, random guessing is probably not the optimal way.

Here, M mode implies exposure knowledge and semi-auto modes reduce the exposure workload to EC.

Stochastic optimization methods generalize deterministic methods for deterministic problems.

I don't understand this.  Where is the connection between random variables and deterministic, anything?

[a1ex]

Look at my SNR graph from raw_diag: it tries every time a different (random) set of points, but two test runs will display more or less the same curve.

So, our problem is a deterministic one (the curve is fixed), yet I estimate it from random patches from a defocused image. Of course, I've made the assumption that most of the patches will be from flat areas and only a minority of them will be on edges. So, the algorithm is randomized, but the end result is deterministic.

See also this: http://en.wikipedia.org/wiki/Randomized_algorithm

For example, you have the Las Vegas algorithm, where the randomization is used to reduce the running time, but the algorithm always ends with the correct result.

[gerk.raisen]

Ready to try it just done

[Marsu42]

Here's a quick code snippet (coded in 5 minutes) that implements it, maybe somebody can turn it into something a little more useful. You may call it from shoot_task.

As it's what I'm sometimes doing, this sounds good to me :-) ... since you wrote it for anyone to take, I'll add it to my "lazyhelp" module I'll publish next unless someone else adds it to the core or another module.