[Papywizard v2] Open talk - general design, ideas...

[fma38]

by fma38 » Thu Aug 27, 2009 9:59 am

Why not? Do you have any idea for the interface?

[Paul]

by Paul » Thu Aug 27, 2009 6:10 pm

I am not familiar with your style / design rules or prog internals

could it be an import like presets or style sheets in the file menu
and 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.

[Gordon]

by Gordon » Thu Aug 27, 2009 10:18 pm

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.

Best
Gordon

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

[fma38]

by fma38 » Thu Aug 27, 2009 10:34 pm

Seems good. But what about 2 comboboxes? One for the camera, and one for the lens?

Too bad the camera.txt file from Autopano package does not contain the sensor resolution... Well, at least, I can use it to replace the first 2 input fields...

[Paul]

by Paul » Fri Aug 28, 2009 7:25 am

But what about 2 comboboxes? One for the camera, and one for the lens?

I think the users will more often change the lens than the body, but I may be wrong.

One preset file - one combo - with all cam/lens combis one uses is more failsave than two independent settings.

[fma38]

by fma38 » Fri Aug 28, 2009 8:17 am

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...

[fma38]

by fma38 » Fri Aug 28, 2009 1:45 pm

Here is my proposition. Has you can see, the combobox is editable, so you can set a new name, press the 'Add' button, and the current entries will be added to the xml file.

When you select a config, the custom entries are disabled, and the 'Add' button turns to 'Remove', so you can delete the config.

Is it Ok for you?

[Paul]

by Paul » Fri Aug 28, 2009 1:56 pm

Is it Ok for you?

for me:
more convenience using PW, so more than ok :):)

[fma38]

by fma38 » Fri Aug 28, 2009 2:58 pm

Ok, let's try to implement this

[flyvholm]

by flyvholm » Wed Sep 09, 2009 3:55 pm

Hi Frédéric!

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.php
This 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 timeline
Allow ease in/ease out of movement around keyframes
Allow 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:

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.

[fma38]

by fma38 » Wed Sep 09, 2009 5:54 pm

Hello flyvholm, and welcome on this forum!

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

[flyvholm]

by flyvholm » Thu Sep 10, 2009 12:05 am

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.

[fma38]

by fma38 » Thu Sep 10, 2009 6:54 am

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...

[fma38]

by fma38 » Thu Sep 10, 2009 2:05 pm

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?

[mediavets]

by mediavets » Sat Sep 12, 2009 4:50 pm

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?

[fma38]

by fma38 » Sat Sep 12, 2009 7:18 pm

Yes, but only for manual move, without automatic position refresh. I also have to check if there are no electrical problems (too much load for the head).

[flyvholm]

by flyvholm » Mon Sep 14, 2009 5:34 am

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.

[clarksbrother]

by clarksbrother » Sun Oct 25, 2009 3:52 am

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.

Once again - thanks for your efforts and consideration!

[fma38]

by fma38 » Sun Oct 25, 2009 9:19 am

Hello clarksbrother,

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.

So, be patient

[fma38]

by fma38 » Sun Oct 25, 2009 9:23 am

BTW, about the idea to use the original controller for manual moves does not work at all. In fact, pluging both the interface and the controller leads to electrical problems.

So, I removed the menu entry, and the key binding (for the reasons I explained above). You will have to use the icons on the GUI to move the head...

[mediavets]

by mediavets » Sun Nov 01, 2009 4:28 pm

Frederic,

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?

[fma38]

by fma38 » Mon Nov 02, 2009 7:58 am

I'll see if it can be easily implemented...

[jamma-pcb]

by jamma-pcb » Thu Nov 05, 2009 3:37 am

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)

If anyone here would like to see this happen please let me know

[klausesser]

by klausesser » Wed Nov 18, 2009 1:46 pm

Please, install teh latests dev. release (2.1.13): it works better then the 2.0.0.

Hi Frédéric!

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 . . . )

best to you, Klaus

[fma38]

by fma38 » Wed Nov 18, 2009 4:11 pm

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?

I'm wondering: did you make updates of pyqt? In a console:

$ sudo gainroot
# apt-get update
# apt-get upgrade

This may help.