Ok. I'll start another thread, for tethered stuff, and automatic bracketing.

Ok, let's discuss about all delays in Papywizard. Here re the chronograms of the present and future releases. I plan to implement the D version, so it will be possible to choose the delays when the shutter contact is closed (level 1), and open (level 0).

1) do you think we need another parameter, for the mirror lockup time, or do we use the stab. delay, as in the current version?

2) do you prefer a ratio for level 1 vs level 0, or the real delays (they will be dependent, so the sum is always equal to the total delay)?

I also plan to rename Tv (Time value) to something else, like 'shutter delay', or something like that, as the real Tv value (from camera), is included in this delay. Feel free to propose better names...

(I'll add the A and B chronograms to the documentation).

GURL wrote:

Is it possible to say that one shot-position corresponds to one trigger-cycle when no bracketing is wanted and corresponds to two or more trigger-cycles when two or more exposure values are to be used ?

I think we can use these terms, yes. Maybe 'shooting position', rather than 'shot position'? So, for you, a 'trigger cycle' can include several pusles (when using mirror lockup feature)?

is the fact that the state of the circuit which controls the shutter haves to change its state 4 times (opened - closed - opened  again - closed  again) something true for every digital camera, every DSLR, every Canon DSLR or only some Canon DSLR ?

It mainly depends on the camera setting: if you activate the burst mode, then I think all µ-cycles (AF, mirror lockup if any, shutter, and again in case of auto bracketing) can be achieved with only 1 longer pulse. But if you let the camera setting in one-shot mode, I think every camera needs a pulse per µ-cycle (except for AF, which is included in the first mirror/shutter cycle).

Here is a new proposal for the next releases, with a simpler and more efficient cycle:

mediavets wrote:

I thought you intended to incorporate the mirror up into the Stabilisation delay to reduce overall shooting time?

Yes, that's what I proposed here. The 'pulse high' param does not need to be very large - a few ms. So, the main delay is the stabilization delay.

If the user wants to include the AF cycle, he will have to choose a 'pulse high' value long enough. In this case, I agree we could include this pulse in the stabilization delay for the mirror lockup cycle... But it may be dangerous, as the mirror will lockup only at the *end* of the AF cycle. If the AF takes too long, then the mirror will lockup very late, at the end of the stabilization delay. As it can shake the camera, it can lead to blur image. So, I think it is better to let it as shown. If no AF cycle is needed, just use a short 'pulse high' value.

If you implement the above schematic what set of variables will the user have to enter?

stabilization delay (s)
shutter cycle time, previously called time value (s)
pulse high (ms)
min pulse low (ms)

So, only 2 additional params are needed, for the pulses shape.

Should users be advised to set their cameras to single shot mode?

Yes, in the documentation.

Well, only in v2 for now, but I may release a 1.8 with some minor v2 backported features, some day... This one can be added to the list.

When would it be appropriate/useful to use AF when shooting panos with Merlin/Papywizard?

My simple Nikon D40 will not take a shot if AF is not achieved, when AF is enabled.

fma38 wrote:

It mainly depends on the camera setting: if you activate the burst mode, then I think all µ-cycles (AF, mirror lockup if any, shutter, and again in case of auto bracketing) can be achieved with only 1 longer pulse. But if you let the camera setting in one-shot mode, I think every camera needs a pulse per µ-cycle (except for AF, which is included in the first mirror/shutter cycle).

One of the cameras I use (Olympus) haves two programmable delays: first delay corresponds to the usual self-timer (French: retardateur.) The second one corresponds to the camera having to wait after the mirror reaches its up position and before the shutter is opened (a setting controls this variable delay.) Using this camera a single and brief trigger button push is enough for one shoot. Using the first delay and using the second delay are independent options.

On the other camera I use (Fuji F5, akin to Nikon D200) the self timer works as usual while using the "mirror up" option excludes the self timer and wants the trigger being pressed twice (resulting in the stupid situation where one needs to buy a remote when both a tripod and a long lens are to be used...)  Nikon D200 and D300 have an "exposure delay mode" where the shutter release is delayed 1.0 sec to avoid vibration.

mediavets wrote:

fma38 wrote:

Well, only in v2 for now, but I may release a 1.8 with some minor v2 backported features, some day... This one can be added to the list.

Hmmmm.....Let's hope there are no 400D (and 350D and 450D?) users with Papywizard on Nokia Tablets who want to use bracketing.

Because it won't work with 1.8, and V2.x only works on the N800 and N810; and 2.x doesn't run properly on those tablets yet because the virtual keyboard won't work with 2.x branch of Papywizard until some newer release of QT is available and there's no telling when that will be.

I was hoping to use my 350D for bracketing when I eventually upgrade. This feature might be upgraded later as it's on fma38's list.

Gordon

fma38 wrote:

mediavets wrote:

If you implement the above schematic what set of variables will the user have to enter?

stabilization delay (s)
shutter cycle time, previously called time value (s)
pulse high (ms)
min pulse low (ms)

So, only 2 additional params are needed, for the pulses shape.

As you know I use a gentled-JUMP to trigger the shutter of my D40 via IR - because the Nikon D40, D40X and D60 lack support for a wired remote.

The gentled-JUMP requires switch closure for about 0.5 seconds to ensure reliable operation.

Is this going to work OK with your proposed new scheme? I will only be triggering the shutter once per shooting position because the D40, D40X and D60 also lack mirror lock-up and AEB.  I'm not sure that any Nikon DSLR has a conventional mirror lock-up function.

Last edited by mediavets (2009-02-11 09:21:17)

mediavets wrote:

As you know I use a gentled-JUMP to trigger the shutter of my D40 via IR - because the Nikon D40, D40X and D60 lack support for a wired remote.

The gentled-JUMP requires switch closure for about 0.5 seconds to ensure reliable operation.

Is this going to work OK with your proposed new scheme? I will only be triggering the shutter once per shooting position because the D40, D40X and D60 also lack mirror lock-up and AEB.  I'm not sure that any Nikon DSLR has a conventional mirror lock-up function.

I think there will be no problem; you will be able to fine tune the trigger signal so it works perfectly with any external triggering mecanism.

Mirror lockup is an option, and is not mandatory (I never used it yet with my 20D). Just don't select it on Papywizard...

Frederic,

I understand the intellectual attraction of the idea to 'modularise' Papywizard. But I wonder if it is not going to:

a) complicate the program unnecessarily, resulting in 'bloatware'.

b) compromise the ability of Papywizard to run on handheld platforms.

c) risk increasing cross-platform inconsistencies and incompatibilities.

I'm not sure how realistic it is to envisage third-party development of Papywizard plug-ins.

Last edited by mediavets (2009-02-11 10:01:48)

fma38 wrote:

Gordon, did you try to use bracketing with Papywizard 1.6.1, on your 770 and your 350D? Do you have the same issue as numz?

No i haven't as currently planning to use the Nikon D40 on the unit, I will experiment with the 350D for you.

Gordon

Instead of calling an external script, which in turn call the tethered program, this will be done from a plugin. As I designed these plugins, they have their own config dialog. So, it will be possible to write a dedicated plugin for, say, TimeLord, with all parameters needed by TimeLord, and modify these params from Papywizard.

Sure, all plugins will have the same interface (from a developer point of view), to be switchable. We will have to find this common interface, and implement it in each plugin.

Is it what you excpect?