could it be an import like presets or style sheets in the file menuand a drop down list on the config tab camera/lens in combination with a checkbox "lens set: preset" which disables the manual settings?

definition of the needed params as tags inside an xml-file

Last edited by Paul on Thu Aug 27, 2009 6:12 pm, edited 1 time in total.

Thats interesting Paul, for favourites another way maybe is to input sensor size and then in a similar way to the gigapan method move the camera, so you have apx 30% overlap at the top and bottom, and save this in favourites this also might be feasible.

BestGordon

Last edited by Gordon on Fri Aug 28, 2009 12:22 am, edited 1 time in total.

I don't think it is a good idea to put the camera config in the same combo as the lens params; it will be hard to retreiev the correct config with a so short description. I will make a first version with only lens combo...

I'm an amateur timelapse photographer who recently came across the Teletrack/Merlin mount. Among timelapse photographers the most used mount currently is the Meade DS series mount because it is similarly low priced, custom speeds can be set directly from the hand controller for those who want it simple (e.g. choose a speed, clamp down a button and off it goes), and for those who want advanced control there's an extensive RS232 command set published. But the Teletrack has integrated camera control which opens up new possibilities. Also, the Meade mounts have an awkward unbalanced shape, inconvenient for trying to mount it on a flat surface or just for packing, and they are noisy. From what I've seen/heard the Merlin head is so quiet that it can be used as a video panning head as well which is a really nice bonus. In other words, this mount has the potential to become the best timelapse mount for the price out there, so I am very interested in the progress of your work and contributing if I can.

To see what an ideal interface looks like, check out the video on this site (you can skip the first 10 minutes which is mostly hardware setup):http://www.camblock.com/sect-support.phpThis is definitely more than I expect can be done here, but it may be within reach implementing some of this functionality. The key elements are:Slew mount to different positions, add these as keyframes on a timelineAllow ease in/ease out of movement around keyframesAllow for preview of the trajectory (fast panning speed, no photos)

A couple of things the timelapse photographer needs to think about when setting up a shot:1) The interval between photos has to be appropriate given the focal length and maximum panning speed. If the interval is too long, the scene will move too much from one frame to the next and the footage won't look smooth.2) The exposure time itself cannot be too long or the panning of the mount can introduce motion blur. This again depends on the focal length and max panning speed.If the user can enter the lens focal length used and the focal length multiplier for the camera, advice can be given as to what the minimum shutter speed and maximum interval between frames should be to give sharp/smooth footage once a trajectory has been set and the max panning speed is known. This only needs to be approximate and would be quite helpful reminders to avoid messing up a shot. If this is something you could implement, I could work out the numbers/formulas.

Did you find out whether triggering the camera without interrupting slewing is possible?

BTW, I'm confused about an earlier post:

fma38 wrote:If someone find some usefull informations about these protocols, please share! There are maybe some guys who hacked them using a USB sniffer...

Which protocols are you referring to? I would point to gPhoto, but I see you are already on the gPhoto mailing lists. From what I've read there, gPhoto can set exposure bias on some cameras.

About timelaspe... Well, I have to admit that I don't have enough time to develop this feature on Papywizard. And I'm not sure if it is a good idea to mixup pano and timelapse...

The other problem is with the Merlin: it is not possible to trigger the shutter while the head is moving: at least, I didn't find a way to do that. The only way to shoot timelapse is to go from one position to another, take a picture, and go to the enxt position. Do you think it can be OK for timelapse? The good point is that you don't have any problem with motion blur.

About the protocols I'm talking about in the quoted string, can you give me a link on the post? I don't remember what was the axact subject

On the Meade mounts you can set an arbitrary speed (alt or az), then tell it to start panning at that speed. It won't stop until you send a command to do so, and you can send other commands meanwhile without interrupting motion. It would *appear* that these commands are also available on the Merlin, looking at the page with RS-232 commands in the manual (set tracking rate, start/stop tracking). Are you capable of sending these commands, and if so, does issuing a trigger release stop the motion?

Even if it isn't possible to shoot without stopping the motion, a timelapse feature would still be highly useful. I think the move-stop-move method to avoid motion blur for long exposures would in fact be the most wanted benefit of integrating shutter release with motion - people are buying Mumford rotary tables to obtain this (along with ease-in, ease-out when starting/stopping the motion), and they aren't cheap (~$1000 I believe). Also, the camera can be triggered by a separate remote timer which will be fine for most purposes. The most useful/important feature would be to have an interface for making the trajectory and then being able to replay it at different speeds (e.g. fast for preview - with live view on camera you'll be able to see exactly what you get - then much slower for the actual timelapse). The Camblock setup I linked to would cost ~$10,000, and short of that I am not familiar of anything with this functionality. Hence my big interest.

But I can certainly appreciate if you don't have enough time to develop timelapse features. You are already doing more than anyone could ask.

The quote with protocols was taken from post #47 in this thread.

Last edited by flyvholm on Thu Sep 10, 2009 12:08 am, edited 1 time in total.

I have to re-check, but I'm pretty sure that once the Merlin head has started to move (which either a 'goto' command, or 'start at a given speed' command), it is not possible to trigger the shutter. The RSR232 commands of the GOTO controller are converted to low-level Merlin commands (http://www.papywizard.org/wiki/DevelopGuide#MerlinOrionprotocole).

The protocols I was talking about in postÂ #47 are the ones used by cameras for tethered shooting... It is not really a protocol: you have to load an undocumented binary table, with strange values, then send it to the camera. Same for reading output...

You may have noticed that once Papywizard is launched, the keyboard does not react in a normal way (I mean, for other applications). This is because I didn't find a correct way to bind the arrow keys to the head moves, and I'm using a workarround which is not really clean. Some other keys are also used, like Enter or ESC, but they are not really usefull.

So, I plan to remove these shortcuts. But I have to admit that the arrow keys are very helpfull, especially when you define the start/end positions for a mosaic shooting, or the reference position, with the eye behind the camera (it is not easy to press the right button on a touch screen). My first idea was to be able to use the original controller. But once Papywizard is connected, it periodically reads the position to update the GUI. So, if you try to move the head with the original controller, communication collisions can occur (there is a CS signal, but it is not respected by the original controller, so we never relied on it, and never wired it on the BT or serial interface).

To avoid that, I plan to add a button to suspend the Spy (the thread which periodically reads the head position). The current position won't be refreshed while moving, but it will be refreshed as soon as you press a set start/end position button (but the Spy will stay suspended). As soon as you launch the shooting process, the Spy will be resumed. Once you close the shoot dialog, the Spy can be either suspended again, or remain active (don't know what is best).

fma38 wrote:You may have noticed that once Papywizard is launched, the keyboard does not react in a normal way (I mean, for other applications). This is because I didn't find a correct way to bind the arrow keys to the head moves, and I'm using a workarround which is not really clean. Some other keys are also used, like Enter or ESC, but they are not really usefull.

So, I plan to remove these shortcuts. But I have to admit that the arrow keys are very helpfull, especially when you define the start/end positions for a mosaic shooting, or the reference position, with the eye behind the camera (it is not easy to press the right button on a touch screen). My first idea was to be able to use the original controller. But once Papywizard is connected, it periodically reads the position to update the GUI. So, if you try to move the head with the original controller, communication collisions can occur (there is a CS signal, but it is not respected by the original controller, so we never relied on it, and never wired it on the BT or serial interface).

To avoid that, I plan to add a button to suspend the Spy (the thread which periodically reads the head position). The current position won't be refreshed while moving, but it will be refreshed as soon as you press a set start/end position button (but the Spy will stay suspended). As soon as you launch the shooting process, the Spy will be resumed. Once you close the shoot dialog, the Spy can be either suspended again, or remain active (don't know what is best).

What do you think about?

This is so that we could attach and use the original handcontroller at the same time as having a BT or serial connection?

I see, you already have the commands for setting a speed and start/stop slewing figured out. I don't see why the shutter release command would be disabled during slewing, but of course it could be the case. It isn't something the mount was designed for.

Unfortunately I can't comment on current functionality/design of Papywizard because I don't even have the mount yet. But I'll get there sooner or later!

You would know more about the tethered shooting than I do. However, gPhoto does tethered shooting by now (there's a --capture-tethered option), so they must have the communication figured out for at least some cameras.

First of all - I would like to thank the developer of Papywizard for taking the time and great effort to make such a useful program. I've undertaken my own Orion Autopano head project recently and plan on using Papywizard to control it.

If I may be so bold as to make a suggestion. Have you considered a Windows Mobile version of Papywizard? Given the large userbase, such devices might make the perfect wireless controller that many people already own.

Porting Papywizard on Windows Mobile devices as been asked several times, and I can understand why Unfortunnally, the graphical toolkit I use to develop Papywizard (PyQt = Python binding for Qt toolkit) does not exist on this platform. But Nokia (who now owns Qt) has recently launched another python binding, named PySide. PySide only works on linux and MacOS (with patches), for now, but they plan to port it to Windows soon, and, I guess, to Windows CE/Mobile too, has they did it with Qt last year.

PW assumes that the vertical arm of the Merlin/Orion mount is positioned to the right of the camera (as viewed from behind the camera).

This is fine and logical when mounting the camera in portrait orientation, because then the camera grip is uppermost.

However if mounting the camera in landscape orientation if is more practical, 'natural' and logical to mount the camera with the vertical arm of the Merlin/Orion to the left of the camera (as viewed from behind the camera), so that the camera grip is positioned away from the vertical arm of the mount, and the axis of the lens is closer to the vertical axis of rotation.

Is it feasible to add a new parameter in the Configure/Shooting tab to set whether the Merlin/Orion mount vertical arm is to the left or to the right of the camera (when viewed from behind the camera)?

Or maybe this can be accommodated by some combination of the exisiting Head-orientation and Camera-orientation parameters?

This maybe be not a direct idea for papy but an app that may assist in an easier way of dealing with large spherical panos.

Take a X grid spherical in 3d (direct x engine) all the photos can be loaded up in sequence (snake format as im calling it) left to right next row right to left (looks like a snake trail)

Then an automated alignment feature.

With a complete movable internal view of the sphere the ability to align and tweak edges (if needed) with stretching warping and sub mesh editing for each image for perfect alignment and maybe contrast/tone even HDR combining as well.

Output would be flash viewer with intelligent viewer for fast loading via online use Maybe templates could be used to fit all sorts of layouts and colour schemes of the player.

Was thinking somewhere along these lines with a few coder friends. Papy + this would work hand in hand IT would be coded well and a strict anti-bloatware development policy would be in place :0)

I just installed 2.1.13 - doesnÂ´t work at all - at least in simulation-mode.Cursors are grayed out, "gesamt FOV" and "Anz. Aufnahmen" are also grayed out."Shoot" is grayed also - doesnÂ´t shoot at all.

Numbers still canÂ´t be typed into the boxes but have to be choosen by up and down arrows - that takes uncomfortably long time when switching from 400mm to 20mm for example . . . . was much better in earlier versions!But at least you changed the box-colors to white numbers on light-blue instead of light-yellow background . . . . that helps a little, little, little bit . . . :cool: - but itÂ´s still hardly recognizable when shooting outdoors, honestly.

So now iÂ´ll again switch back to 1.6.1 to be able to work with it even outdoors (ok.: this time of year it isnÂ´t very bright outdoors any more . . . )

The buttons are greyed out as long as your are not connected (Menu Hardware)

I checked an option for spinboxes, which accelerate them when you keep the arrow down (you can use the hardware arrows, which is more comfortable). It does not take very long time to switch from 20 to 200...

And I didn't change anything with colors... Can you make a screenshot of your screen?