Panoshoot Wireless Control Module for Panogear

[mediavets]

by mediavets » Sun Mar 24, 2013 9:50 pm

Remote connection:

Apparently you can connect to and control your Panogear/Merlin mount plus Panoshoot module from anywhere in the world.

So....why would you want to do that?

I guess I lack imagination because I'm struggling to envisage a scenario in which I might wish to do that.

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

I obviously really lack imagination...

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.

[mediavets]

by mediavets » Sun Mar 24, 2013 9:57 pm

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.

Flattery won't save you.

I had some input to the development of Papywizard so I'm familiar with the ins and outs and pros and cons of that system.

And have since followed the development of the T&C controller with interest, although I have never seen or used one.

I'm just trying to get a better understanding of how Panoshoot differs from Papywizard and the T&C controller; and why one might choose one over the other.

[mediavets]

by mediavets » Sun Mar 24, 2013 9:59 pm

Bounce....

Why not ask Kolor to establish a new section of the forum for Panoshoot questions?

We are going to create a dedicated section for Panoshoot.

Panoshoot on the Kolor Store: http://www.kolor.com/buy/panoshoot.html
Adam created video tutorials that are on YouTube: http://www.youtube.com/playlist?list=PLqPZ7zvLePxdxyLtbTblD7kpiFlGXfja0

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

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

[mediavets]

by mediavets » Sun Mar 24, 2013 10:18 pm

Javqui,

Thanks for the detailed explanationm of the Panoshoot timing profiles, and comparison to Papywizard's shooting sequence elements.

Very helpful.

I'm glad to see that Panoshoot Timing Profiles offer the equivalent of Papywizard's Pulse width high value. This is essential in order to be able to use the gentLED-TRIGGER device to trigger (via infrared) the shutter of cameras that do not support a wired remote control - for example most lower-end Nikon DSLRs.

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

Does Panoshoot have settings that differentiate between those cameras that require a shutter trigger for each shot in a bracketed exposure sequence and those cameras that will shoot an AEB sequence with a single shutter trigger?

[mediavets]

by mediavets » Sun Mar 24, 2013 10:28 pm

2. What happens if you set you an automatic repeat of a shoot? Do the initial and repeat shoots co-ordinate data get recorded in a single XML data file? If so, that wouldn't that be virtually useless with the APP/APG Papywizard Import wizard which is surely the reason to record the shooting co-ordinates in a data file?

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.

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?

[panoramicessentials.com]

by panoramicessentials.com » Sun Mar 24, 2013 10:48 pm

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?

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

[panoramicessentials.com]

by panoramicessentials.com » Sun Mar 24, 2013 11:00 pm

2. What happens if you set you an automatic repeat of a shoot? Do the initial and repeat shoots co-ordinate data get recorded in a single XML data file? If so, that wouldn't that be virtually useless with the APP/APG Papywizard Import wizard which is surely the reason to record the shooting co-ordinates in a data file?

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.

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?

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.

[mediavets]

by mediavets » Sun Mar 24, 2013 11:01 pm

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?

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?

[panoramicessentials.com]

by panoramicessentials.com » Sun Mar 24, 2013 11:08 pm

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?

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?

Astronomy. Its very very impractical for photography.

[mediavets]

by mediavets » Sun Mar 24, 2013 11:27 pm

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?

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

I think you'd end up with a 'mess'.

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?

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.

True.

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.

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.

[panoramicessentials.com]

by panoramicessentials.com » Sun Mar 24, 2013 11:59 pm

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?

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.

True.

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.

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.

I have to admit my ignorance in making that comment. Its been so long since i've created a pano using a long focal lenth or a pano of a featureless blue sky that I forgot about that problem. Thanks for reminding me and pointing out my mistake.

[mediavets]

by mediavets » Mon Mar 25, 2013 12:15 am

3. Can you post an example of an XML data file created by Panoshoot please?

http://panoshoot.javqui.com/forum/session.xml

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.

[panoramicessentials.com]

by panoramicessentials.com » Mon Mar 25, 2013 12:24 am

3. Can you post an example of an XML data file created by Panoshoot please?

http://panoshoot.javqui.com/forum/session.xml

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.

[mediavets]

by mediavets » Mon Mar 25, 2013 12:49 am

http://panoshoot.javqui.com/forum/session.xml

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.

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 dare say it does 'work fine' with the APP/APG Papywizard Import wizard as far as you are concerned.

Although it doesn't entirely. For example, the Papywizard Import wizard cannot read your title tag nor does it seem able to read your focal tag.

I think one could say it is partially compatible with the current implementation of the APP/APG Papywizard Import wizard; but that's not at all the same thing as saying it is Papywizard XML format data file compatible because it isn't.

[klausesser]

by klausesser » Mon Mar 25, 2013 1:13 am

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?

When you shoot a sphere repeatingly you only need one xml for all.

As a matter of fact i use to generate an xml for any lens i use and store them as kind of templates. I´m able to use this pre-written xml for all spherical shootings i do with the according lens.
So i often don´t even download the xml which the TC writes with every shooting.

So: i sometimes shoot a sphere multiple times - each time using another focus as example.

I take ONE xml for all spheres then - though each sphere is recorded.

best, Klaus

[klausesser]

by klausesser » Mon Mar 25, 2013 1:23 am

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.

Given you have sufficient mechanical precision you only need one xml when you shoot a sphere repeatingly. It´s needless to have an xml for each of the spheres.

If you do NOT have high mechanical precision then it doen´t make sense to shoot a sphere repeatingly and have an xml for each one of them: the xml will show differences which grow from sphere to sphere from what the head really shoots . . .

best, Klaus

[klausesser]

by klausesser » Mon Mar 25, 2013 1:37 am

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.

Which doesn´t matter at all in real use . . .

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.

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

[fma38]

by fma38 » Mon Mar 25, 2013 6:52 am

3. Can you post an example of an XML data file created by Panoshoot please?

http://panoshoot.javqui.com/forum/session.xml

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

[mediavets]

by mediavets » Mon Mar 25, 2013 9:27 am

http://panoshoot.javqui.com/forum/session.xml

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

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.

[mediavets]

by mediavets » Mon Mar 25, 2013 9:31 am

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

See: http://www.kolor.com/forum/p113721-today-08-27-43#p113721

[klausesser]

by klausesser » Mon Mar 25, 2013 11:27 am

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

Most of them definitely do!

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.

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

On the other hand using a Merlin doesn´t bring too much problems to your budget if it gets damaged or so. Mounting it to some hidden place or for recording a building´s
progress usually webcams are used. But having the Merlin shoot a 180° sequence every 6 hours over half a year using a better camera definitely makes sense for making
a hires timelapse.

best, Klaus

[klausesser]

by klausesser » Mon Mar 25, 2013 11:36 am

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

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.

What´s your problem? Look at the code (TC-generated):

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<papywizard version="c">
    <header>
        <general>
            <title>
             Start 12:01:02 22.03.2013  End 12:03:46 22.03.2013
            </title>
            <gps>
                                     
            </gps>
            <comment>
                Generated by PANONEED       
            </comment>
        </general>
        <shooting mode="preset">
            <headOrientation>
                up
            </headOrientation>
            <cameraOrientation>
               portrait
            </cameraOrientation>
            <stabilizationDelay>
                0.5
            </stabilizationDelay>
            <startTime>
              12:01:02 22.03.2013   
            </startTime>
            <endTime>
              12:03:46 22.03.2013   
            </endTime>
        </shooting>
        <camera>
            <timeValue>
                1.0
            </timeValue>
            <bracketing nbPicts="001"/>
            <sensor coef="1.0" ratio="3:2 "/>
       </camera>
        <lens type="rectilinear">
            <focal>
                35.0         
            </focal>
        </lens>
        <preset name="  Klaus 35mm  "/>
    </header>
    <shoot>
        <pict bracket="001" id="0001">
            <time>
                                   
            </time>
            <position pitch="-058.7" yaw="+000.0" roll="+090.0"/>
        </pict>
        <pict bracket="001" id="0002">
            <time>
                                   
            </time>
            <position pitch="-058.7" yaw="+036.0" roll="+090.0"/>
        </pict>
     
     
     ....................
     
     
        <pict bracket="001" id="0044">
            <time>
                                   
            </time>
            <position pitch="+053.1" yaw="+000.0" roll="+090.0"/>
        </pict>
        <pict bracket="001" id="0045">
            <time>
                                   
            </time>
            <position pitch="+090.0" yaw="+000.0" roll="+090.0"/>
        </pict>
    </shoot>
</papywizard>

best, Klaus

Last edited by klausesser on Mon Mar 25, 2013 11:46 am, edited 1 time in total.

[mediavets]

by mediavets » Mon Mar 25, 2013 11:39 am

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

Most of them definitely do!

best, Klaus

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

[klausesser]

by klausesser » Mon Mar 25, 2013 11:42 am

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

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.

But - as i also wrote: "On the other hand using a Merlin doesn´t bring too much problems to your budget if it gets damaged or so."



best, Klaus

[mediavets]

by mediavets » Mon Mar 25, 2013 11:54 am

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.

Quite.

Javqui was promoting these as examples of applications using the remote control features of the Panoshoot device.

Panoshoot currently only works with Panogear/Merlin.

That's why I said none of his proposed scenarios made any sense to me.