fma38 wrote:

Starting with 1.9.7 release, Papywizard can drive an external command-line program. So, if you can make some tests, it will be a good start to know what will be required for complete interaction.

If the software you find does not support command-line driving (without GUI), then try to ask the developers if such feature can be added.

I have been working with Frederic and Todd Gibbs of OxfordEye, the developer of a Windows program called Timelord, to prototype an automated extended exposure bracketing system for Nikon DSLRs which utilises the feature mentioned above.

Initial tests are very promising.

More details ....

We hope soon to have an extended bracketing function - which does not use bulb mode - working for all Nikon DSLRs (even those like my D40, the D40X and D60 which lack built-in AEB) controlled by a modified version of a Windows program called Timelord (from UK software company OxfordEye) under Papywizard control.

This will work only with Papywizard (and a modified version of Timelord) running on a Windows XP system (typically a laptop) with a separate USB wired connection to the camera.

If we get it to work then the user will be able to configure an extended exposure bracketing 'preset' for Timelord which will be automatically invoked by Papywizard (via the Python script) at each shooting position in a pano with optional uploading as-you-go of the images to the host PC. We have it  working now in a semi-automated fashion, which proves the concept, and soon we hope in a fully automated fashion, including writing a Papywizard data file which will record the bracketing for the APPV2/APG import filter.

If we get this to work then we'll try and get something similar working using (a variant of) the Breeze DSLR Remote Pro software for Canon DSLRs - this will depend on getting some co-operation from Breeze but I am hopeful. This would work only with Papywizard (and a variant of the Breeze software) running on a Windows XP system (typically a laptop)  with a separate USB wired connection to the camera. Automated focus stacking is rather more difficult.

There's very litle chance of getting this sort of thing to work on Nokia Tablets, because a USB connection is required, because the DSLR makers' SDKs are only available for Windows, and because the Nokia Tablets lacks the compute power needed.

It may be possible to get something working on Linux PCs using the gphoto2 library - Frederic is exploring this I think.

I believe Olympus offers some SDKs for some of their cameras  - if so in theory a third-party developer could create something that would work for some Olympus cameras.

Anyway don't hold your breath, these things will all take quite a while yet.

Last edited by mediavets (2009-03-06 18:18:24)

Thanks, Andrew I just want to add that if you find some usefull tethered solutions, under windows, MacOS or linux, feel free to post them here, so we can investigate and see if they are compatible with Papywizard.

Ideally what we are looking for is any program that can be run from the command line, optionally with parameters, that performs the following operations, at a minimum, with no further user input/interaction:

1. Loads and connects to the camera.

2. Shoots a sequence of images at different shutter speeds - ie. exposure bracketing. When shooting panos the camera is usually set in manual mode and you would not want to vary the aperture.

3. Disconnects from the camera and Exits.

...............

A suitable program need not be cross-platform. We are intersted in programs that run on any of the these platforms - Windows, Mac OSX, Linux, Maemo.

A suitable program need not work with all brands and models of cameras. We are intersted in programs which work with any DSLR or compact camera.

The program need not have a GUI.

There will need to be some way for the user to configure the desired sequence and range of shutter speeds for exposure bracketing.

The possible range of exposure bracketing should be greater than any offered by a built-in AEB function, otherwise there would be no point in using it. In other words a program that merely triggers the camera's built-in AEB function is not what we are looking for.

It may be desirable for the program to be able to upload images to the host PC on a shot by shot basis, but this is not essential.

.............

Any hardware device that can make the camera take a series of shots at different shutter speeds in manual mode and can be triggered via a switch would also be of great interest.

Last edited by mediavets (2009-03-07 10:14:49)

bigwade wrote:

Maybe I'm a bit silly but what is the goal about this all ?
Most camera's can do bracketing (sorry Andrew, just upgrade your D40
If these camera's are set well, PW can do the trick.

It's not about simply trying to overcome my D40's lack of AEB. The goal is rather more ambitiuous and has far wider application than that.

The goal is to offer software controlled automatic extended bracketing - initially extended exposure bracketing - in a tethered shooting setup.

Extended means offering a greater range than is offered by a camera's built-in AEB capabaility.

The built-in AEB capabaility of most cameras is insufficient for many pano shooting scenes:
http://www.panoguide.com/r/?p=http%3A%2 … 2Faeb.html

Automatic means that, other than configuring the bracketing settings, the user does not have to do anything during the shoot, the extended bracketing will managed by a third-party program under the control of Papywizard.

I don't think you can expect a tethered solution for all brands written by Frederic combined with the PW software to run the Merlin.......

Frederic has written a 'universal script' for Papywizard which enables Papywizard to pass 'responsibility' for triggering the shutter to a third-party program. The extended automatic exposure bracketing is handled by the third-party program. Frederic does not write these programs.

If the script is present when Papywizard is started then, instead of the camera being triggered via the camera port on the Merlin head, Papywizard will invoke the third party program at each shooting position. The third-party program controls the camera while shooting images at that shooting position, then control passes back to Papywizard which moves the head to the next shooting position, and so on, until the pano shoot is complete.

Any program that meets the requirements set out in my earlier post could be used to control the automatic extended exposure bracketing.
http://www.autopano.net/forum/p40369-ye … -18#p40369

Our first implementation will use a modified version of a program called Timelord, from OxfordEye a UK software developer.
http://www.oxfordeye.co.uk/

The Timelord software runs on Windows and only controls Nikon DSLRs. We are experimenting with this program initially because in its unmodified form it is close to what we need, and the developer has shown interest in modifying the program to meet our needs.

When we get it to work with a modified version of Timelord, then we shall have 'proof of concept' and can approach other software developers - such as Breeze Systems, who make DSRL Remote Pro which works with Canon cameras, to see if they are willing to make a modified version of their software which will meet our needs.
http://www.breezesys.com/products.htm

It is highly unlikely that we shall find a single third-party program that would work with all brands and model of camera because this sort of software is typically developed using SDKs (Software Development Kits) produced by camera manufacturers. These SDKS are of course brand, and in some cases model, specific.

BTW
I'm not going out on the streets with a fancy laptop, I'm happy with the Nokia stuff to run the Merlin.
Indoor (studio) I can still connect my camera to my Mac (tethered) and control the movements of the head step by step via the Nokia.
Bracketing and all other stuff I can do with the tethered software, in my case Remote Control via DPP on my Mac.

The difference would be that instead of using Step-by-step when shooting with papywizard and controlling the third-party software (DPP in your example, but it could equally have been Timelord or DSLR Remote Pro) yourself, with automatic extended exposure bracketing, as we prepose, the whole process for shooting a pano scene with extended exposure bracketing would be automatic.

This automation becomes important when shooting panos comprising a large number of images, and is a major reason for using a robotic pano head in the first place.

So I am curious about the demands/"needs" from others...
grtz!

So are we. That's why I am trying to describe what is it we are doing so that others can contribute ideas.

...........

Automatic extended exposure bracketing has been our initial goal. First because it is probably a feature more people might use, and secondly because it is probably the easiest to achieve.

But the concept could in theory be applied to, say, automatic focus bracketing, which could be used as well as automatic exposure bracketing.

Or even to implement Frederic's original idea of intelligent automatic extended  exposure bracketing - where the system would only bracket exposures where it was necessary, and only take as many shots as required, to capture the full dynamic range. But this is considerably more complex than what we will be able to achieve initially.

Finally I should point out that no-one has to use this feature/functionality. If the script is not present when Papywizard strats then it behaves just as it does now, triggering the camera via the camera port on the Merlin head.

Last edited by mediavets (2009-03-07 12:43:03)

bigwade wrote:

I'm not going out on the streets with a fancy laptop, I'm happy with the Nokia stuff to run the Merlin.

YES - right!
Let´s stay with the initial idea: a pocket decvice to control the Merlin running PapyWizard.
I now have a PC latop also - but i wouldn´t like to use it on the go. The Nokia message pad is far more convenient.
There´s nothing against, in my eyes, using the camera in bulb-mode and run bracketing this way controlled by PapyWizard.
Or am i wrong? Maybe there´s a problem using short exp.times? If so - doing bracketing means static objects anyway and therefore no problem using longer times . . maybe using a neutral-density filter.

I wouldn´t like to have a laptop with me to control the Merlin and/or the camera just for extended bracketing.
Such a Nintendo on the other hand . . . running PapyWizard AND a bracketing-software: why not? It´s small and light and not expensive.
But building a complete new Papy for Nintendo and buying a new device just for having extended bracketing . . .

best, Klaus

mediavets, the price of eepc's are continuing to fall in price and can be found for as little as £100 which is a similar price to a DS this price will only go down further. I too would not really want to walk the streets with a laptop, but it seems like I already do , a tiny eepc maybe acceptable as you say in certain situations. Many eepc's have wifi and BT capability and can also run linux and now even have touch screen adaptors. As small devices go maybe the audrino or the USB controller you mentioned is the way to go.

http://www.arduino.cc/


http://www.blip.com.au/item.aspx?itemid=12



Best
Gordon

Last edited by Gordon (2009-03-07 19:03:05)

Paul wrote:

mediavets wrote:

Tethered shooting control software for Nikon DSLRs:

somewhat else for free:

http://www.diyphotobits.com/2009/02/03/ … racketing/

Developer says:

"Only works in P, A or S modes as the bracketing is controlled by adjusting the exposure compensation. I’ll do M mode support later."

May be more interesting when it works in M mode.

About exposure in bulb mode, you need a real-time OS to ensure the exposure time are correct...

mediavets wrote:

Did you ever find out more about this:
http://www.autopano.net/forum/t5344-hdr … dr-trigger

Should be little difficulty triggering it from the camera port on Merlin via Papywizard.

In fact, I guess that using the Merlin contact rather than the push button should work out-of-the-box...

Precise shutter speeds in a sequence are surely not that important - for automatic exposure bracketing - so long as the sequence of shutter speeds is consistent and repeatable?

Yes, but without real-time OS, you can't do things consistent and repeatable...

Hi,

mediavets wrote:

fma38 wrote:

mediavets wrote:

Did you ever find out more about this:
http://www.autopano.net/forum/t5344-hdr … dr-trigger

Should be little difficulty triggering it from the camera port on Merlin via Papywizard.

In fact, I guess that using the Merlin contact rather than the push button should work out-of-the-box...

Except that the push button is also used to select from among the several different programmed functions the device supports:
http://www.doc-diy.net/photo/hdr-jack/

Thanks for notifying me of this interesting thread, mediavets. Modifying the HDR-Jack to work with a cable is theoretically straightforward. The push-button connects one pin of the AVR to ground, so you can connect a remote release cable in parallel. I assume the Merlin camera release port just short-circuits two wires for a single short period of time.
A slight change in the software will be necessary. To get the HDR function after pressing the button once (or shortinging the wires via Merlin) the 'delayed trigger' function and the hdr function must be swaped. This is trivial as both functions are in a swich-case like structure.

The problem is that the bracketing series takes about 25s (last shot is 15s). The last shot is necessary in dark places like churches but completely unnecessary in daylight conditions. Some kind of preselection would be nice.

Currently I'm developing an enhanced version of the HDR-Jack. There will be a rotary switch with 15 positions for different modes like in the SmaTrig project (http://www.doc-diy.net/photo/smatrig/). I'll try to include a external trigger connector. It could be also used  to control the exposure via mp3+bulb. This would be a possibility to allow precise timing for non-RTOS devices.

The general problem of bulb mode bracketing is the limited shortest exposure time. In the case of Canon it's ~1/200s. IMHO the only clean solution is to implement a USB-host in a small embedded system and copy the commands form gphoto, but I guess this is a full time job for a middle-experienced DIYer...

Cheers, Luk

PS:
Benedikt Sauter describes an open source USB-host for embedded systems in his diploma thesis.

Paul wrote:

doc-diy wrote:

IMHO the only clean solution is to implement a USB-host in a small embedded system

voila, here it is:
http://hackaday.com/2009/01/17/cuiduino … b-support/

I guess the USB has no USB-host functionality. In the USB-tree you need one host to control the communication. Usually it's the PC. As the camera is a not a host you will need one on the other side. That's the problem with all the phones and palms with USB ports. Please correct me if I'm wrong. I'm still learning about matter.

doc-diy wrote:

Please correct me if I'm wrong. I'm still learning about matter.

sorry, you are right ...

how about this:
http://rz-robotics.de/z-usb.html
http://www.vinculum.com/prd_vdip1.html