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

[fma38]

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

by fma38 » Sat Jan 10, 2009 3:32 pm

As I'm about to release the last stable version of the 1.x branch, and I would like to thank all people involved in this nice project: beta testers, translators, contributors or simple users, you all helped me to bring Papywizard to a state I never imagined! I also want to thanks Alexandre, and all the Kolor team, for their help and support to this project.

So, I think it is time to start to talk about Papywizard v2 We already discussed about a few features which have been delayed to that branch, so it would be a good idea to summurize them here, and see what we want to do with this branch, on what plateform and so.

Here are a few ideas/questions/propositions...

1) Timelapse: I don't know if people interested are still reading us. As I don't know much about this technic, I will need some help and ideas. I would also like to know what pure panoramic users think about this feature. Do you think it should be integrated into Papywizard, or should be a standalone application? In any case, a lot of code could be shared, and I plan to split Papywizard in several pieces, to be able to reuse common parts.

2) Tethered shooting: I think this will be a major improvement. I plan to be able to download the images as soon as they are shot, extract thumbnails to display them in mosaic shooting area, or do intelligent automatic bracketing.

3) Preset editor/management: we launch the idea to build some sort of server, to create/store/retreive presets. Another approach is to have a integrated editor, with import/export tool. Or a mix of both.

4) Support for other panohead: as I will soon test a Panoduino-like servo-based panohead, I will make a better design to be able to drive any kind of hardware. The accuracy will also be improved, by implementing backlash correction routines.

5) Save/load configurations: this is what we called 'presets for mosaic mode'.

6) Plug-ins support: I always dreamed to be able to dynamically add feature to my programs (not only to Papywizard), but never took the time to implement a good plug-ins framework. I think I will do it in the v2. The goal will be to implement all internal (defaut) features as plug-ins, and to allow the user to write its own, to add, or even replace, some features. I don't know where it will lead us, but, well, let's try

7) Code review: this will be the first step: a big code review, to improve stability, add more error catching and so. And to implement the plug-ins framework...

8) Plateforms and toolkit: this is a sensitive point... As I said, I don't want to drop Nokia support, as a lot of users recently bought one to run Papywizard, and as it is a very simple way to drive the Merlin head. On the other hand, such devices are limited, especially the 770; it is clear that tethered shooting feature will need a lot of resources, and a USB host port. So, all features won't be available on all plateforms... I would also like to switch to Qt toolkit. As Nokia now owns Trolltech, it seems that Qt will be the first toolkit used by future Nokia's devices. What I read on forums, is that PC Qt applications seems to run fine out-of-the-box on Nokia. But again, this will require at least a N800

Ok, your turn, now

[klausesser]

by klausesser » Sat Jan 10, 2009 4:13 pm

Hi Frédéric!

Good news!
TimaLapse is very special and i think most pano-users wouldn´t need it. BUT: a device like the Merlin obviously is great for making it! And it´s fun anyway . .
Tethered with quick download: Wow - that would be great for a quick overview on scene.
Plug-ins would be fine also!
Stability should be added. Basically it is stable already - but some things . .

Well - great times ante portas :cool:

best, Klaus

Last edited by klausesser on Sat Jan 10, 2009 4:13 pm, edited 1 time in total.

[Paul]

by Paul » Sat Jan 10, 2009 10:57 pm

are there defined somewhere basic capabilities which a motorhead should communicate?
or do you have already a concept for an abstraction layer?

I think of basics like:
- range of the two axes in degree 0-360, 0-180, continuous or limited (like with servos)
- hor. resolution, vert. resolution per degree
- hor. backlash, vert. backlash
- hor. min. and max. speed, vert. min. and max. speed
- speed ramping
- min. time for stabilisation

commands:
Move Up, Move Down, Move Left, Move Right, Move To
release shutter

it would be great if PW2 is able to run on "Pocket" devices and Tablet- or Netbook-PCs

I don't see so much people around who are able to develop plugins. This may change if there is any kind of open hardware for a motorhead, but then someone is needed who deals with the components like RepRap http://store.rrrf.org/

[mediavets]

by mediavets » Sat Jan 10, 2009 11:01 pm

Hi Frédéric!

Good news!
TimaLapse is very special and i think most pano-users wouldn´t need it. BUT: a device like the Merlin obviously is great for making it! And it´s fun anyway . .
Tethered with quick download: Wow - that would be great for a quick overview on scene.
Plug-ins would be fine also!
Stability should be added. Basically it is stable already - but some things . .

Well - great times ante portas :cool:

best, Klaus

How does timelapse differ from an intervalometer?

[AlexandreJ]

by AlexandreJ » Sun Jan 11, 2009 9:58 am

1) Timelapse: I don't know if people interested are still reading us. As I don't know much about this technic, I will need some help and ideas. I would also like to know what pure panoramic users think about this feature. Do you think it should be integrated into Papywizard, or should be a standalone application? In any case, a lot of code could be shared, and I plan to split Papywizard in several pieces, to be able to reuse common parts.

I really think that this feature is part of the panorama head control software even if it's not really panoramic. Each shoot has 2 always 2 parameters : location and time of shooting. It's true that in panoramic, we don't really care of the timing, but I think it's an common background that we should put into the heart of the system (even if it's not used a lot on the GUI )

2) Tethered shooting: I think this will be a major improvement. I plan to be able to download the images as soon as they are shot, extract thumbnails to display them in mosaic shooting area, or do intelligent automatic bracketing.

So true. This is huge. It will need to cope with the complicated task or remote thumbnail retrieval. We need to use some already well working library for that : http://www.autopano.fr/wiki/action/view/Pilotage_APN

3) Preset editor/management: we launch the idea to build some sort of server, to create/store/retreive presets. Another approach is to have a integrated editor, with import/export tool. Or a mix of both.

One idea : we are creating such server just for that feature for autopano. It will be used to handle autopano updates, plugins updates, cameras support upgrade easily.
It works per project, and for each project you can have several upgrades : for example, updating just the cameras.txt file in autopano is possible with this system.
Moreover, it's crossplatform.
It's quite what you need, so Kolor can provide you this facility for papywizard.

4) Support for other panohead: as I will soon test a Panoduino-like servo-based panohead, I will make a better design to be able to drive any kind of hardware. The accuracy will also be improved, by implementing backlash correction routines.

Yes. That part is to isolate from the other part of the code in a plugin. Each plugin can control one panohead. With a good specification of that part, I'm sure it's easy to convince panohead hardware manufacturer to create themself the plugin.

6) Plug-ins support: I always dreamed to be able to dynamically add feature to my programs (not only to Papywizard), but never took the time to implement a good plug-ins framework. I think I will do it in the v2. The goal will be to implement all internal (defaut) features as plug-ins, and to allow the user to write its own, to add, or even replace, some features. I don't know where it will lead us, but, well, let's try

You have to design the plugin system by answering these questions :
- what is the kernel part of the software ? this will tells you what is really the software, it's goal, it's logic. For this project, I would define it as 'software to take photos with a controlled panohead' : it's generic enough but not too much. For example, we could have said 'software to take photo with a controlled device'. For example, it the controlled device is a drone, I think it's beyond this project. Everywhere in this project, we suppose that the only freedom of control is rotation around a point.
- what module could be switched by another one ? this often indicates that there is place for plugin ( example : merlin IO library could be replaced by gigabot IO library )

7) Code review: this will be the first step: a big code review, to improve stability, add more error catching and so. And to implement the plug-ins framework...

8) Plateforms and toolkit: this is a sensitive point... As I said, I don't want to drop Nokia support, as a lot of users recently bought one to run Papywizard, and as it is a very simple way to drive the Merlin head. On the other hand, such devices are limited, especially the 770; it is clear that tethered shooting feature will need a lot of resources, and a USB host port. So, all features won't be available on all plateforms... I would also like to switch to Qt toolkit. As Nokia now owns Trolltech, it seems that Qt will be the first toolkit used by future Nokia's devices. What I read on forums, is that PC Qt applications seems to run fine out-of-the-box on Nokia. But again, this will require at least a N800

That would be a great move. For device support : http://trolltech.com/qt-in-use/story/device
And for us, Kolor, because we could participate more in this project because we are Qt developer ( I never coded one line of python myself... ).

[fma38]

by fma38 » Sun Jan 11, 2009 2:15 pm

1) Timelapse

I really think that this feature is part of the panorama head control software even if it's not really panoramic. Each shoot has always 2 parameters : location and time of shooting. It's true that in panoramic, we don't really care of the timing, but I think it's an common background that we should put into the heart of the system (even if it's not used a lot on the GUI).

One idea I had was to be able to either make a time-lapse pano, or a pano time-lapse Seriously, if we have 2 engines, a pano engine and a time-lapse engine, one should be able to mix both engines, in whatever order. In short: either take a complete pano at repeating times (this is the intervalometer), but in addition, we could choose to move a little bit the center of the pano, or either time-lapse each position of the pano. But I don't think it is very relevant, as time-lapse the first picture for an hour, then the second, then the third could not lead to a correct pano...

Here, I really need the help of people making time-lapse, to see what has to be done, and how it can be included in pano features.

2) Tethered shooting

So true. This is huge. It will need to cope with the complicated task or remote thumbnail retrieval. We need to use some already well working library for that : http://www.autopano.fr/wiki/action/view/Pilotage_APN

This will be a non-trivial part, as most libs are in C, so it will need a lot of work to run them on different plateforms... Unless I re-write something entirely in python.

3) Preset editor/management

One idea : we are creating such server just for that feature for autopano. It will be used to handle autopano updates, plugins updates, cameras support upgrade easily.
It works per project, and for each project you can have several upgrades : for example, updating just the cameras.txt file in autopano is possible with this system.
Moreover, it's crossplatform.
It's quite what you need, so Kolor can provide you this facility for papywizard.

Sounds good It is clearly a very nice solution.

4) Support for other panohead

Yes. That part is to isolate from the other part of the code in a plugin. Each plugin can control one panohead. With a good specification of that part, I'm sure it's easy to convince panohead hardware manufacturer to create themself the plugin.

Once plugins are available, it will be trivial.

6) Plug-ins support

You have to design the plugin system by answering these questions :
- what is the kernel part of the software ? this will tells you what is really the software, it's goal, it's logic. For this project, I would define it as 'software to take photos with a controlled panohead' : it's generic enough but not too much. For example, we could have said 'software to take photo with a controlled device'. For example, it the controlled device is a drone, I think it's beyond this project. Everywhere in this project, we suppose that the only freedom of control is rotation around a point.
- what module could be switched by another one ? this often indicates that there is place for plugin (example : merlin IO library could be replaced by gigabot IO library).

Thanks for these tips. I think I will need your help on that part, as I'm not familiar with such pattern.

8) Plateforms and toolkit

That would be a great move. For device support : http://trolltech.com/qt-in-use/story/device
And for us, Kolor, because we could participate more in this project because we are Qt developer (I never coded one line of python myself...).

Python uses Qt in a very close way than C++ does. It is in fact much simple. The problem is more in Qt usage: what widget to use, what method I need to overload to fit my needs and so... I will maybe need help on this, as I think I made more complex things in GTK than I ever did in Qt (I uses it at work for simple tasks, as most of the code is command-line oriented).

Ok, so I really need some users input, here, for the timelapse, preset editor, configuration load/save, tethered shooting (on the user point of view), and on the global GUI (which is always the non-trivial part, as it is what users first see). And for any feature not mentionned here... Do not hesitate to repost your previous requests that I delayed for v2, as I may not have saved all of them.

[mediavets]

by mediavets » Sun Jan 11, 2009 4:29 pm

If Presets in V2 are to be very similar/identical to Presets in V1.x then I don't think we need a Presets Editor. Unless you are thinking of something very 'smart' - a sort of Preset Generator that would take user input such as:

4 shots at +80 pitch
12 shots at +40 pitch
12 shots at 0 pitch
12 shots at -40 pitch
4 shots at -80 pitch

and turn that into an optimised set of shooting positions (a custom Preset) with calculated yaw separations, and rows offsets and an optimised path/sequence. of head movement to minimise shooting time.

Now that would be worth having.

It could be an on-line application.

Last edited by mediavets on Sun Jan 11, 2009 4:30 pm, edited 1 time in total.

[fma38]

by fma38 » Sun Jan 11, 2009 4:50 pm

No, nothing so smart (there are too much things to take into account).

In fact, there a several possibilities:

1) Having an internal editor to add/edit/remove a preset. It should be possible to edit the title, the comment, and all positions.

2) Having only an import feature, to get presets from the server.

3) Having both, plus the export to the server feature.

In any case, the xml file will be the save method, will remain the same, and could be manually edited/loaded as it is now. In addition, an on-line application to add/edit/remove presets on the server (or it can only be a standalone application).

[mediavets]

by mediavets » Sun Jan 11, 2009 8:01 pm

I'd like feature within (or could be external to) Papywizard to add or remove a preset to/from the 'permanent' set of custom presets.

If we had such a feature I would like the default presets to be accessible to this tool/feature as well.

A feature within Papywizard to import from an on-line server-based preset database would be 'cute' but far from essential IMO.

[fma38]

by fma38 » Sun Jan 11, 2009 8:08 pm

That's the way I see it. The default presets will be copied as users preset the first time the application is used. Then, you will be able to edit them as you like. The question is: what (where) is the 'permanent' set of presets? My idea is that it is just a xml file (same structure as the currrrent one), and can be either on your hard disk, or on a remote server (Kolor).

[claudevh]

by claudevh » Sun Jan 11, 2009 10:47 pm

Frederic,

Ne pense-tu pas que les utilisateurs francophones ne doivent pas également pouvoir donner leur avis ?
Veux-tu lancer un post sur le même sujet en français ?

[fma38]

by fma38 » Sun Jan 11, 2009 11:29 pm

Claude, good idea!

[GURL]

by GURL » Mon Jan 12, 2009 7:54 pm

This is only an "open idea" but what about having "exposure anchors" one could set before shooting?

(To be developed latter in the French forum.)

[fma38]

by fma38 » Mon Jan 12, 2009 8:04 pm

What do you have in mind?

[marc]

by marc » Tue Jan 13, 2009 1:07 am

Your project, Frederic, is very interesting to me aside from the seamless Autopano interface. I'm with Peace River Studios, the manufacturer of PixOrb, a motorized pan-tilt head. The motors on our head are stepper harmonic gear motors. The motor control and capture software that we use for the PixOrb and our other motorized products is our own, built on FileMaker Pro for OSX and Windows; however, the prospect of communicating with the head using a pocket device is very intriguing.
Communication with the different makes of controllers for servos or steppers will require, as you've pointed out, a plug-in for each (written by each hardware provider, probably). Aside from the syntax issues there are those relating to support for peripherals such as the serial device that our controller manufacturer makes that acts as a communication manager and buffer and informs the host when, for instance, a move is completed.
Another thing that might be worth considering is the control of more than 2 axes. We have a linear axis for our TrailRail with PixOrb and have received requests for additional motorized axes including zoom control.
I can send you and anyone else who is interested screen shots of our setup dialogs to show what types of parameters can be controlled by the user. This might be helpful for you if you want to include one more piece of hardware in your development plans.

[fma38]

by fma38 » Tue Jan 13, 2009 10:05 am

Marc, it would be very interesting to be able to drive your PixOrb device from Papywizard, and I would be pleased to add such support (I think a protoype can be done in the 1.x branch for a quick test, as v2 will not likely be released soon).

The communication can be of any type: serial, usb, bluetooth, wifi, smoke signals... In fact, I have different drivers which just provide a sendCmd() method (these drivers are just different python classes). That's for the transport. Then, we need a protocol object, one for each hardware. For now, I don't have such abstraction, but it is very easy to add. We just need a selector to instanciate the correct one, and, the annoying part, a entry in the Preference dialog.

Then, additionnal axis. That's an interesting point. Can you explain what is the 'TrailRail'? What is it for? About the zoom, do you plan to be able to set any focal value from a user entry in the GUI? In other words, will it have a drive()-like method to go to a specific value? Ok, this part definitly needs to be integrated in v2.

[mediavets]

by mediavets » Tue Jan 13, 2009 10:16 am

Frederic,

Here's some info about TrailRail:
http://www.peaceriverstudios.com/15_trailrail/trindex.html

[fma38]

by fma38 » Tue Jan 13, 2009 10:45 am

Ok, I see.This is an axis (or several) which influences the position of the head. This can be used for othographic panos, and should be linked to GPS data...

[mediavets]

by mediavets » Tue Jan 13, 2009 10:49 am

Ok, I see.This is an axis (or several) which influences the position of the head. This can be used for othographic panos, and should be linked to GPS data...

Also used with movie cameras.

[BeeZed]

by BeeZed » Tue Jan 13, 2009 9:28 pm

Here are my thoughts:

First Papywizard v1 has been great to follow and use, and has allowed may people to explore motorized pano heads. When APG becomes more stable it will be a powerful combination.

For v2:

1) Timelapse: I am very keen to explore this area, especially after seeing the film Earth, which has many panning time lapse sequences. I agree that it is a specialized "toy" that most people will not use.

2) Tethered shooting: This sounds like another area for a plugin, as since you could eventually add in camera control capabilities.

3) Preset editor/management: A basic library of presets and the ability to save preset sets by camera or project would be nice. I can imagine having a set of Canon presets for example. I think an internal editor is important, though it could be a separate program, so a user can customise if needed. I cannot imagine that having users export to a server would be good, as there would be too many presets if everyone generated and exported them. Having the ability to download an updated standard library from a server would be nice.

4) Support for other panohead: I am looking forward to this, and to your building a better head. You have lured me towards Linux, and soon I may be making robots too.

6) Plug-ins support: I think the list of opportunities is endless. You just need more people who can program to help you.

8) Platforms and toolkit: I have a 770, and am content with the current functionality of v1. If you are able to support the next generation of portable devices, that is all we can ask, as the new features will require more processing power and communication. Could the plugin architecture help in this? For example, if tethered shooting is not possible on certain devices, then a plugin could not be installed. Besides, getting help from the Kolor team is one way to get more programmers on the job

[mediavets]

by mediavets » Tue Jan 13, 2009 9:34 pm

Here are my thoughts:

For v2:

1) Timelapse: I am very keen to explore this area, especially after seeing the film Earth, which has many panning time lapse sequences. I agree that it is a specialized "toy" that most people will not use.

Hi BeeZed,

Can you explain how you would shoot - what is involved in shooting - a panning timelapse pano?

What is the end result - a video file?

I just cannot get my head around the notion of timelapse panos at the moment.

Last edited by mediavets on Tue Jan 13, 2009 9:50 pm, edited 1 time in total.

[BeeZed]

by BeeZed » Tue Jan 13, 2009 10:00 pm

Yes you get a movie, or a slide show as one scene fades into the next. If I was shooting sphericals, there would only be panning in the display, but i have seen a series where each capture is only a small section of the 360, and then the center of the view shifts to the right for the next time lapse "frame". So if I know I want to create a slow pan while showing 120 degrees of horizontal view, i can take a 5 frame pano every hour, or day, and shift 10 degrees, and take the next one.

Another way is to have 360 panoramas in a virtual display but also acting like a movie. If the viewer stays in one position, as time goes by, the image will transform into the next time sequence with the same subject matter. If the viewer pans, the scene moves and time flows by.

There is a non panning 360 degree time lapse on the Roundshot site, about half way down this page.

There are also various examples on the IVRPA site.

[klausesser]

by klausesser » Tue Jan 13, 2009 10:02 pm

Here are my thoughts:

For v2:

1) Timelapse: I am very keen to explore this area, especially after seeing the film Earth, which has many panning time lapse sequences. I agree that it is a specialized "toy" that most people will not use.

Hi BeeZed,

Can you explain how you would shoot - whaqt is involved in shooting - a panning timelapse pano?

What is the end result - a video file?

I just cannot get my head around the notion of timelapse panos at the moment.

Hi Andrew!

May i come in here!

Timelapse is really interesting - it can be really thrilling on a site. Though the effect is rather known - but rarely in combination with panning.

To get a smooth effect you need 25 fps. That means, if you shoot 25 pictures you get one second of movie.
Shooting 12,5 pictures a second for two seconds you get two seconds of movie but with doubled speed.
And so on.
That means: during a pan of 180° you must choose a certain amount of shots and a dedicated time to shoot them to get the effect you want.
let´s say: one shot per second while the head is panning 180°. That means as an example per 1 degree one shot - which means 180 shots:25=7,5 secondes of movie.

The question will be: does the head have to stop for each shot? Yes - depending on the exposure-time. At night maybe 2 seconds exposure-time per shot - which means: the head has indeed to stop at each single degree, waits for stabilization, shoots for 2 sec., moves on and so on.

best, Klaus

http://video.aol.com/video-detail/stock-footagewide-shot-pan-time-lapse-rolling-cloudsfog-in-mountain-valley-olympic-peninsula-washington/3206259742/?icid=VIDURVNAT11

Last edited by klausesser on Tue Jan 13, 2009 10:14 pm, edited 1 time in total.

[mediavets]

by mediavets » Tue Jan 13, 2009 10:07 pm

Here are my thoughts:
For v2:

3) Preset editor/management: A basic library of presets and the ability to save preset sets by camera or project would be nice. I can imagine having a set of Canon presets for example. I think an internal editor is important, though it could be a separate program, so a user can customise if needed. I cannot imagine that having users export to a server would be good, as there would be too many presets if everyone generated and exported them. Having the ability to download an updated standard library from a server would be nice.

Hi BeeZed,

Because you can use the File/Load preset... function to load a custom preset (or more than one custom preset) on a per-session basis I can't see any problem with creating a set of Canon, for example, presets right now with V1.x.

These preset files can have any name you like, so you can give each a descriptive name, and you can save them in (and load them from) whatever folder/directory you like on the removable memory card in your Nokia Tablet (or anywhere on a Windows or Linux file system, if using a Windows or Linux PC to run Papywizard).

I would not want in internal preset editor on a Nokia Tablet and I don't see why this function is required as part of Papywizard. It should be aseparate program, if indeed it is needed at all which I don't think it is.

You can create and edit a custom preset XML file with even the simplest of text editors - the Notes tool on Nokia Tablets would do it. However I cannot imagine creating or editing presets in the field while on a shoot - why would you ever need to do this?

WRT downloading presets from server - why would you need anything other than a regular browser?

[mediavets]

by mediavets » Tue Jan 13, 2009 10:24 pm

Here are my thoughts:

For v2:

1) Timelapse: I am very keen to explore this area, especially after seeing the film Earth, which has many panning time lapse sequences. I agree that it is a specialized "toy" that most people will not use.

Hi BeeZed,

Can you explain how you would shoot - whaqt is involved in shooting - a panning timelapse pano?

What is the end result - a video file?

I just cannot get my head around the notion of timelapse panos at the moment.

Hi Andrew!

May i come in here!

Timelapse is really interesting - it can be really thrilling on a site. Though the effect is rather known - but rarely in combination with panning.

To get a smooth effect you need 25 fps. That means, if you shoot 25 pictures you get one second of movie.
Shooting 12,5 pictures a second for two seconds you get two seconds of movie but with doubled speed.
And so on.
That means: during a pan of 180° you must choose a certain amount of shots and a dedicated time to shoot them to get the effect you want.
let´s say: one shot per second while the head is panning 180°. That means as an example per 1 degree one shot - which means 180 shots:25=7,5 secondes of movie.

The question will be: does the head have to stop for each shot? Yes - depending on the exposure-time. At night maybe 2 seconds exposure-time per shot - which means: the head has indeed to stop at each single degree, waits for stabilization, shoots for 2 sec., moves on and so on.

best, Klaus

http://video.aol.com/video-detail/stock-footagewide-shot-pan-time-lapse-rolling-cloudsfog-in-mountain-valley-olympic-peninsula-washington/3206259742/?icid=VIDURVNAT11

Klaus,

Why not just take a panning shot with a video camera - what is it I don't get about what you describe doing with a still camera?

Last edited by mediavets on Tue Jan 13, 2009 10:27 pm, edited 1 time in total.