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