Remote connection:

Well, there are several applications with this requirement. Actually we are working in one of them that require this specific feature.
I can mention some basic ideas of what you can do (you will get more ideas after start using Panoshoot for sure):

- If you are shooting a time-lapse session with long values (a several days session like a multi position grass growing or multi position flowers opening), you can check the status remotely from your office or house. Something similar if you get a contract to shoot a building in construction where could be necessary making adjustments over the time or provide to your customer an integrated web page to shoot at specific events in specific positions.

- If you have a business with several photographers and want to provide remote support and help, this feature is very useful.

- If you are shooting large panoramic in restricted areas (you have limited time access) like airport towers and other restricted places, you will love the fact that you can access your Panoshoot without the requirement of be in place all the time.

- If you want to share your work on internet (or even rent as a service your expensive infrastructure of camera-Panogear-Panoshoot), you have the option to integrate and create a web page with direct connectivity to your equipment. (Advanced Panoshoot API interface and internet access will be very useful).

- If you get a contract to photography a large event (like big social events, red carpet, etc), you can install several cameras with Panoshoot and Panogear to shoot from different points and control all of them with your smartphone. They can point all together to the same interest point to get a 3D perspective or to capture multiple angles at the same time of the same area; you will do the job of several auxiliary photographers with just an economic Wi-Fi router. It will show you as a very professional and innovative photographer and give you additional advantage over traditional services. (We will include this functionality in a future update or early if some user requires it urgent for a specific big event.)

You have a very deep knowledge about the topic and we really appreciate your highly detailed comments and feedback. They are very constructive and extremely valuable.

So who is going to be responsible for supporting Panoshoot users?

Kolor via the Kolor forum; or Panoshoot via their online support ticket system?

Not sure if I fully understand the question, but I will try to describe how Panoshoot handle multiple shoots.
The term “multiple shoot” and “bracketing” are interchangeable for Panoshoot. The differentiation depends on how the user configures the camera. If the user set the camera to process a “shutter signal” as a bracketing with different exposure values, it will be a bracket. If the user set the camera to process a “shutter signal” as a single shoot, it will be a multiple shoot.

In both cases Panoshoot will output a "XML record” in a similar format that Papywizard do. I agree that if the head didn’t move, it should not be necessary write again the pitch, roll, yaw coordinates, but we need to be compatible with current established XML standard for interoperability, even if this is not the most efficient way. We will be happy to optimize this interchange data format for a more efficient structure if the “receivers” (means Autopano) will accept a modified format.

It could be a good point here to provide our feedback about the format for interchange data between systems/apps (means Panoshoot/papywizard/Autopano). The XML format is more appropriate on this case due the data is not highly structured (is not a clear tabular and planar data) and the objective is interoperability between different systems, in contrast with the PicPoints presets import mechanism previously described.

Javqui

Speed/accuracy trade-off.
Thanks for the explanation. Interesting...

But not really what I was try to get at.

Let's be much more specific...in relation to using APP/APG to stitch panos using the Papywizard Import wizard, what what max. speed vs accuracy value would you advocate with a typical 25-30% overlap before the loss of accuracy impacts the APP/APG stitcher?

With a Panogear/Merlin mount, how much faster can Panoshoot complete any particular pattern, with identical camere/lens settings, than Papywizard or the T&C controller?

Interesting observations; but, yes, you did misunderstand my question.

I believe that Panoshoot offers a feature to repeat an entire pano shoot automatically, either immediately a shoot finishes or after a timed delay?

In such a scenario does the XML data file created for the first pano shoot get overwitten by the repeat pano shoot; or are all automaticalle repeaed pano shoots of this type recored in a single XML data file?

If the later is the case, how can such a file later be used with the APP/APG Papywizard Import wizard?

The speed/accuracy settings will utimately depend on the number of images you will take. If you are shooting a 360x180 mosaic at 200mm focal length then you will want a speed/accuracy trade-off setting between 80-90%. The rule of thumb to follow here is the more images and movements the panogear will take/make the more room for error since the panogear loses accuracy after each movement.

For example, with a 70mm focal lenth (CANON 24-70MM) I usually use a 90-95% setting. With a 15mm fisheye lens on a Canon 5D II I use 100% setting since accuracy will not be an issue due to the low number of images (2 rows x 6 columns).

In what circumstances might one use a value of less than 80%?

If there are none - why have a scale of 1-100?

Currently the xml file does not accumulate the data for each mosaic (But this is something to look into and I believe we will have to explore how APP/APG will handle such a file) .

In the case of the repeated shoots of the same session the same file can be used for the import of each mosaic since the data will be identical.

In light of all this however I found that there is really not much use for the xml file with the pattern the Panoshoot follows. The accuracy in stitching is identical no matter which method you use. hence it would save you more time to just use the auto detect setting. For custom presets with complicated patterns I think that the xml file will be most useful since it will communicate to APP/APG the pattern of the shots.

My point was that, in my opinion, when the user specifies automatically repeated shoots then Panoshoot should create a separate XML data file for each of the repeats.

Now it sounds as if it might already do that.

My understanding (misunderstanding?) from reading the User Manual is that if the user chose not to download an XML file after pano shoot the the next shoot would overwrite that file with a new XML data file.

So is this what happens with an automatically repeated shoot scenario?


True.


Woa there....I've had to read this through several times to se if you had indeed written what I initially thought you had written.

I think you are suggesting that if you shoot pano using a regular grid/matrix pattern (in Papywizard-speak, a Mosaic pano), which would typically be a partial pano because it would be better to use a preset for any pano with HFOV of 360. Then there is never an advantage in using the Panoshoot created XML data file with the APP/APG Papywizard Import wizard.

If that's what you really think and intended to communicate then I think you are very mistaken; and in my opinion your statements (highlighted) are just plain wrong. And I have to wonder if you have grasped the idea (and reality) behind recording shooting positions and the APP/APG Papywizard Import wizard.

You will I'm sure understand that if you shoot panos with longer focal length rectilinear lesnes then it is quite likely that you will end up with some 'featureless' images (blue sky, white celing/wall and so on) that the autodetection system cannot link to it's neighbouring images, and these 'featureless' images will consequently be omitted from the stitch.

The XML data file of recorded shooting positions provides the APP/APG (and PTGui Pro) stitchers with data to enable the placemnt of 'featureless' images that the autodetection system would otherwise not be able to place.

Oh dear....this file may 'work' with the current APP/APG Papywizard Import wizard but it does not appear to be a Papywizard-compatible XML format data file.

The Papywizard data file definition was published by Kolor here:

http://www.autopano.net/wiki-en/action/view/Panohead_XML_data_file

The Panoshoot XML format data fileyou provided contains many tags and attributes that do not exist in the definition.

That's fine. Just don't say it's a Papywizard-compatible XML foemat data file, because it isn't.

Perhaps it would be better if you worked with Kolor to develop a new separate Panoshoot Import wizard for APP/APG. It would potentially enable APP/APG to utilise data that Panoshoot records that Papywizard does not.

But then it appears that you think the whole concept of data file and Import wizard is worthless, so why bother.

I have tested it using the Papywizard import tool in APP/APG and it worked fine. I will double check when I return home from my trip.

I believe that Panoshoot offers a feature to repeat an entire pano shoot automatically, either immediately a shoot finishes or after a timed delay?

In such a scenario does the XML data file created for the first pano shoot get overwitten by the repeat pano shoot; or are all automaticalle repeaed pano shoots of this type recored in a single XML data file?

If the later is the case, how can such a file later be used with the APP/APG Papywizard Import wizard?

My point was that, in my opinion, when the user specifies automatically repeated shoots then Panoshoot should create a separate XML data file for each of the repeats.

Oh dear....this file may 'work' with the current APP/APG Papywizard Import wizard but it does not appear to be a Papywizard-compatible XML format data file.

The Papywizard data file definition was published by Kolor here:

http://www.autopano.net/wiki-en/action/view/Panohead_XML_data_file

The Panoshoot XML format data fileyou provided contains many tags and attributes that do not exist in the definition.

That's fine. Just don't say it's a Papywizard-compatible XML foemat data file, because it isn't.

Perhaps it would be better if you worked with Kolor to develop a new separate Panoshoot Import wizard for APP/APG. It would potentially enable APP/APG to utilise data that Panoshoot records that Papywizard does not.

Oh dear....this file may 'work' with the current APP/APG Papywizard Import wizard but it does not appear to be a Papywizard-compatible XML format data file.

The Papywizard data file definition was published by Kolor here:

http://www.autopano.net/wiki-en/action/view/Panohead_XML_data_file

The Panoshoot XML format data fileyou provided contains many tags and attributes that do not exist in the definition.

That's fine. Just don't say it's a Papywizard-compatible XML foemat data file, because it isn't.

Perhaps it would be better if you worked with Kolor to develop a new separate Panoshoot Import wizard for APP/APG. It would potentially enable APP/APG to utilise data that Panoshoot records that Papywizard does not.

As far as I know, APP/APG ignores the header, and only uses the <shoot></shoot> part. Which is the same...

Andrew: did you ever USE the APG-PapyWizard import with importing an xml-file from the T&C ? It works as well as the "original" PW files generated by a Nokia or by a PC for example.

Kolor provided the PW-file featured tags some time ago - you´d be surprised how few tags are used at all in today´s APG.

What happens in the PW-import-module actually to me seems somewhat clandestine . .

best, Klaus

None of those scenarios seems to make any sense to me.

I just can't imagine any pro or semi-pro photographer letting his expensive gear out of his/her sight.
Increasingly pros are opting for more expensive robotic mounts; like the Panoneed, the SeitzVRdrive2, the Rodeon or the Panomachine systems.

That's not correct.

The Papywizard Import wizard definitely reads - and reports to the user - the values I have shown in bold in the screenshot below; it may read and use more?

Who knows? Kolor has never, as far as I know, published any details of which values it does or doesn't currently use from a Papywizard XML data file.

Kolor also has the freedom to use any or all of the defined values in future implmentations of the Papywizard Import wizard.

If the developers of other robotic head controllers follow the published definition then their XML data files should be assured of being compatible with current and future implementations of the Papywizard Import wizard.

And that's my point in reporting when they don't follow the definition.

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

Of course controller manufacturers are free to establish their own proprietary definition for their output data files and to work with Kolor to develop a controller specific APP/APG Import wizard. Seitz appears to have taken that approach after initially claiming that their VRDrive2 output data file format was Papywizard-compatible, when it wasn't.

Most of them definitely do!

best, Klaus

And you can imagine doing them with a Panogear/Merlin, and a DSLR, controlled by Panoshoot?

As i wrote:
"Doing things like Javqui described you preferably do as a pro. Pros don´t use Merlins. For several reasons.
It´s as simple as that . . "

No - i can´t imagine doing it using the Merlin.