Panoshoot Wireless Control Module for Panogear

[mediavets]

by mediavets » Mon Mar 25, 2013 12:00 pm

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

I have no problem with the XML files generated by the T&C controller for Panogear/Merlin and Panoneed after Josef made some changes following our discussion elsewhere.

Here I am addressing problems with the XML files generated by the Panoshoot.

Compare this with T&C generated XML files, Papywizard generated XML files, and the Papywizard XML data file definition and see what you think:

Code: Select all

<?xml version="1.0" encoding="utf-8" ?>
<panoshoot xml_revision="1">
    <header>
        <sessionInfo>
            <title/>
            <Author/>
            <Comments/>
            <totalPictures>24</totalPictures>
            <totalPicpoints>6</totalPicpoints>
            <startTime>2013-02-24 19:28:37.2</startTime>
            <endTime>2013-02-24 19:29:06.2</endTime>
            <yawSweep min="-5.00" max=" 2.71" sweep=" 7.71"/>
            <pitchSweep min="-1.11" max=" 16.99" sweep=" 18.10"/>
            <location/>
        </sessionInfo>
        <profile id="0" type="mosaic">
            <name>default profile</name>
            <cameraInfo>
                <calculated_fieldOfView horizontal="8.58" vertical="12.84"/>
                <cameraOrientation>portrait-left</cameraOrientation>
                <lens type="rectilinear" focal="50" opticalMulti="2"/>
                <sensor ratio="3:2" coef="1.60" resolution="16"/>
            </cameraInfo>
            <timing>
                <stabilizationPause>0.5</stabilizationPause>
                <obturatorTime>0.30</obturatorTime>
                <afterShootPause>0.40</afterShootPause>
            </timing>
        </profile>
        <mosaic>
            <nbPicts horizontal="2" vertical="3"/>
            <Overlap minimum="20"/>
        </mosaic>
    </header>
    <shoot>
    <pict id="1" bracket="1">
        <time>2013-02-24 19:28:37.2</time>
        <position yaw="-5.00" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="2" bracket="2">
        <time>2013-02-24 19:28:37.9</time>
        <position yaw="-5.00" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="3" bracket="3">
        <time>2013-02-24 19:28:38.6</time>
        <position yaw="-5.00" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="4" bracket="4">
        <time>2013-02-24 19:28:39.3</time>
        <position yaw="-5.00" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="5" bracket="1">
        <time>2013-02-24 19:28:42.8</time>
        <position yaw=" 2.71" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="6" bracket="2">
        <time>2013-02-24 19:28:43.5</time>
        <position yaw=" 2.71" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="7" bracket="3">
        <time>2013-02-24 19:28:44.2</time>
        <position yaw=" 2.71" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="8" bracket="4">
        <time>2013-02-24 19:28:44.9</time>
        <position yaw=" 2.71" pitch="-1.11" roll="0"/>
    </pict>
    <pict id="9" bracket="1">
        <time>2013-02-24 19:28:48.0</time>
        <position yaw=" 2.71" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="10" bracket="2">
        <time>2013-02-24 19:28:48.7</time>
        <position yaw=" 2.71" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="11" bracket="3">
        <time>2013-02-24 19:28:49.4</time>
        <position yaw=" 2.71" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="12" bracket="4">
        <time>2013-02-24 19:28:50.1</time>
        <position yaw=" 2.71" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="13" bracket="1">
        <time>2013-02-24 19:28:53.5</time>
        <position yaw="-4.94" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="14" bracket="2">
        <time>2013-02-24 19:28:54.2</time>
        <position yaw="-4.94" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="15" bracket="3">
        <time>2013-02-24 19:28:54.9</time>
        <position yaw="-4.94" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="16" bracket="4">
        <time>2013-02-24 19:28:55.6</time>
        <position yaw="-4.94" pitch=" 8.18" roll="0"/>
    </pict>
    <pict id="17" bracket="1">
        <time>2013-02-24 19:28:58.7</time>
        <position yaw="-4.94" pitch=" 16.99" roll="0"/>
    </pict>
    <pict id="18" bracket="2">
        <time>2013-02-24 19:28:59.4</time>
        <position yaw="-4.94" pitch=" 16.99" roll="0"/>
    </pict>
    <pict id="19" bracket="3">
        <time>2013-02-24 19:29:00.1</time>
        <position yaw="-4.94" pitch=" 16.99" roll="0"/>
    </pict>
    <pict id="20" bracket="4">
        <time>2013-02-24 19:29:00.8</time>
        <position yaw="-4.94" pitch=" 16.99" roll="0"/>
    </pict>
    <pict id="21" bracket="1">
        <time>2013-02-24 19:29:04.1</time>
        <position yaw=" 2.69" pitch=" 16.99" roll="0"/>
    </pict>
    <pict id="22" bracket="2">
        <time>2013-02-24 19:29:04.8</time>
        <position yaw=" 2.69" pitch=" 16.99" roll="0"/>
    </pict>
    <pict id="23" bracket="3">
        <time>2013-02-24 19:29:05.5</time>
        <position yaw=" 2.69" pitch=" 16.99" roll="0"/>
    </pict>
    <pict id="24" bracket="4">
        <time>2013-02-24 19:29:06.2</time>
        <position yaw=" 2.69" pitch=" 16.99" roll="0"/>
    </pict>
    </shoot>
</panoshoot>

[klausesser]

by klausesser » Mon Mar 25, 2013 3:20 pm

I have no problem with the XML files generated by the T&C controller for Panogear/Merlin and Panoneed after Josef made some changes following our discussion elsewhere.

Here I am addressing problems with the XML files generated by the Panoshoot.

Well - either it works or it does not work ! As long as it works fluent in APG and PTGui: who cares about being "by the books" or not . . .
DOES the Panoshoot´s code work fluently in APG´s PW-importer?

For example: "overlap" isn´t read in the importer at all afaik. That would be useless anway: the overlap results from the angles related to the values for focal/sensor.
So there is no need to seperetely take "overlap" in account as a value in APG - it´s already in the head´s xml.

best, Klaus

[mediavets]

by mediavets » Mon Mar 25, 2013 3:34 pm

I have no problem with the XML files generated by the T&C controller for Panogear/Merlin and Panoneed after Josef made some changes following our discussion elsewhere.

Here I am addressing problems with the XML files generated by the Panoshoot.

Well - either it works or it does not work ! As long as it works fluent in APG and PTGui: who cares about being "by the books" or not . . .
DOES the Panoshoot´s code work fluently in APG´s PW-importer?

No, it doesn't.

It doesn't read and display any of the values I've highlighted in Papywizard XML file definition screenshot below.

Panoshoot records some of those values but not in the correct format so the Import wizard cannot read them.

And that's why I nag about conforming to the published standard definition.

The alternative for Panoshoot is to work with Kolor to develop a Panoshoot-specific Import Wizard.

[klausesser]

by klausesser » Mon Mar 25, 2013 3:45 pm

I have no problem with the XML files generated by the T&C controller for Panogear/Merlin and Panoneed after Josef made some changes following our discussion elsewhere.

Here I am addressing problems with the XML files generated by the Panoshoot.

Well - either it works or it does not work ! As long as it works fluent in APG and PTGui: who cares about being "by the books" or not . . .
DOES the Panoshoot´s code work fluently in APG´s PW-importer?

No, it doesn't.

It doesn't read and display any of the values I've highlighted in Papywizard XML file definition screenshot below.

Panoshoot records some of those values but not in the correct format so the Import wizard cannot read them.

And that's why I nag about conforming to the published standard definition.

The alternative for Panoshoot is to work with Kolor to develop a Panoshoot-specific Import Wizard.

You DID shoot using the Panoshoot for controlling the Merlin and you DID import it´s xml for stitching?

best, Klaus

[mediavets]

by mediavets » Mon Mar 25, 2013 3:51 pm

Well - either it works or it does not work ! As long as it works fluent in APG and PTGui: who cares about being "by the books" or not . . .
DOES the Panoshoot´s code work fluently in APG´s PW-importer?

No, it doesn't.

It doesn't read and display any of the values I've highlighted in Papywizard XML file definition screenshot below.

Panoshoot records some of those values but not in the correct format so the Import wizard cannot read them.

And that's why I nag about conforming to the published standard definition.

The alternative for Panoshoot is to work with Kolor to develop a Panoshoot-specific Import Wizard.

You DID shoot using the Panoshoot for controlling the Merlin and you DID import it´s xml for stitching?

best, Klaus

I requested a sample of a Panoshoot generated XML file and used that with the APP/APG Papywizard Import wizard, and it's clear that it's not fully compatible as I have pointed out.

But you only have to take a look at the Panoshoot XML file content and compare it to XML files generated by Papywizard, or the T&C controller, to see that.

[klausesser]

by klausesser » Mon Mar 25, 2013 4:13 pm

No, it doesn't.

It doesn't read and display any of the values I've highlighted in Papywizard XML file definition screenshot below.

Panoshoot records some of those values but not in the correct format so the Import wizard cannot read them.

And that's why I nag about conforming to the published standard definition.

The alternative for Panoshoot is to work with Kolor to develop a Panoshoot-specific Import Wizard.

You DID shoot using the Panoshoot for controlling the Merlin and you DID import it´s xml for stitching?

best, Klaus

I requested a sample of a Panoshoot generated XML file and used that with the APP/APG Papywizard Import wizard, and it's clear that it's not fully compatible as I have pointed out.

But you only have to take a look at the Panoshoot XML file content and compare it to XML files generated by Papywizard, or the T&C controller, to see that.

So you did NOT shoot a sequence, exported the xml from Panoshoot to your computer and imported it into APG? You took some shots from your Nokia-controlled Merlin and imported the images into APG using the Panoshoot´s xml files?

How can you tell the Merlin did what Panoshoot would have wanted it to do?

For evaluating Panoshoot´s xml you need to have it control your Merlin and do a shooting. After that you need to export the xml which the Panoshoot recorded and import it into APG.

Otherwise i doubt you can judge how it works in real, i´m afraid.

best, KLaus

Last edited by klausesser on Mon Mar 25, 2013 4:14 pm, edited 1 time in total.

[mediavets]

by mediavets » Mon Mar 25, 2013 5:46 pm

So you did NOT shoot a sequence, exported the xml from Panoshoot to your computer and imported it into APG? You took some shots from your Nokia-controlled Merlin and imported the images into APG using the Panoshoot´s xml files?

How can you tell the Merlin did what Panoshoot would have wanted it to do?

For evaluating Panoshoot´s xml you need to have it control your Merlin and do a shooting. After that you need to export the xml which the Panoshoot recorded and import it into APG.

Otherwise i doubt you can judge how it works in real, i´m afraid.

best, KLaus

No, No..... No!

You have failed to read and understand what I wrote.

I asked the Panoshoot developers to provide me with a sample of an XML file generated by Panoshoot.

And that's what I am referring to.

I am not sure why you feel compelled to 'defend' Panoshoot so vehemently.

[javqui]

by javqui » Mon Mar 25, 2013 6: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?

We run a standard mosaic grid test on papywizard and Panoshoot.
I will publish all details of the test this week with comparative graphics of resolution, precision and speed.
Overall, mass=820 grams (like your Nikon D40 with 35mm lens and battery), 12V DC input, 25% overlap, 11x2 pictures, bracketing:3, half sec pause (all parametric, firmware version, driver settings, etc available in final report).

Overall results, just quick figures:
Papywizard (alternate drive) complete the shooting session in 5 minutes 28 seconds.
Panoshoot with speed/Accuracy=100% (speed favor) complete the exact same test in 2 minutes 31 seconds (acceptable precision for many indoor aplications)
Panoshoot with 1% (accuracy favor) needs under 7 minutes but the precision is about 10 times better than papywizard (for most applications is not neccesary this amount of precision)
around the middle trade-off, in under 4 minutes with equivalent precision of the same papywizard secondary loop control system.

Other tests with full LiPo battery 16V (faster running motors ) and intermediate values of speed/accuracy will be included in the report.
For this test we use the panoshoot build#95 that will be available this week.

Last edited by javqui on Mon Mar 25, 2013 6:10 pm, edited 1 time in total.

[klausesser]

by klausesser » Mon Mar 25, 2013 6:20 pm

I am not sure why you feel compelled to 'defend' Panoshoot so vehemently.

I have no need to defend somebody - i just want to understand what you´re talking about EXACTLY!

best, Klaus

[mediavets]

by mediavets » Mon Mar 25, 2013 6:30 pm

I am not sure why you feel compelled to 'defend' Panoshoot so vehemently.

I have no need to defend somebody - i just want to understand what you´re talking about EXACTLY!

best, Klaus

Well, I don't know whether I can spell it out more exactly..... how about the XML data files generated by Panoshoot are not Papywizard compatible.

You can see for yourself - just compare the coding in this Panoshoot generated XML file with a Papywizard generated XML file or a T&C controller generated XML file:

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

[mediavets]

by mediavets » Mon Mar 25, 2013 6:36 pm

We run a standard mosaic grid test on papywizard and Panoshoot.
I will publish all details of the test this week with comparative graphics of resolution, precision and speed.
Overall, mass=820 grams (like your Nikon D40 with 35mm lens and battery), 12V DC input, 25% overlap, 11x2 pictures, bracketing:3, half sec pause (all parametric, firmware version, driver settings, etc available in final report).

I look forward to seeing your detailed report.

IUn the meantime a few quick questions:

Which version of Papywizard did you use and on which OS platform?

Which Bluetooth adapters did you use on the Panogear/Merlin mount, and on the host platform, when controlling the mount using Papywizard?

Which shooting pattern within the grid did you use with both setups?

[klausesser]

by klausesser » Mon Mar 25, 2013 6:41 pm

I am not sure why you feel compelled to 'defend' Panoshoot so vehemently.

I have no need to defend somebody - i just want to understand what you´re talking about EXACTLY!

best, Klaus

Well, I don't know whether I can spell it out more exactly..... how about the XML data files generated by Panoshoot are not Papywizard compatible.

Yes - i just wanted to know your procedere.

best, Klaus

[mediavets]

by mediavets » Mon Mar 25, 2013 7:00 pm

I have no need to defend somebody - i just want to understand what you´re talking about EXACTLY!

best, Klaus

Well, I don't know whether I can spell it out more exactly..... how about the XML data files generated by Panoshoot are not Papywizard compatible.

Yes - i just wanted to know your procedere.

best, Klaus

I downloaded the sample Panoshoot XML dat file from the link provided by Panoshoot developers:

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

Then I loaded that into the Papywizard Import filter in APG 3.0.5 32-bit version running on Windows XP Pro.

To inspect the XML data file coding I viewed the file with WordPad.

Is that enough information?

[javqui]

by javqui » Mon Mar 25, 2013 7:03 pm

...Of course this raises another question. How do you expect users to work out the co-ordinates of a series of shots to create an optimal pattern for shooting spherical panos, wher it is desirable to reduce the number of shots per row as you approach the zenith and nadir to avoid excessive overlaps?

Are asking or are you explaining what is a spherical pano?
a spherical pano is just a simple optimization of a planar Mosaic. It can be done very easily on a spreadsheet. We will include the checkbox in the Mosaic to simplify the job.

...B*llocks is the first word that comes to mind. My bullsh*t detector just went off the scale. It sounds to me that you just didn't think about it.

I think that you are going too fast. Probably you will need recalibrate your bullsh*t detector.

From a software developer point of view, is a lot easier handle XML files than CSV "human oriented" files. In XML everything is specified (that's why a lot of redundancy) and is a lot easier to "quiz" what data is coming. There many libraries to handle XML files, and if the user make a mistake, the developer just send a message “invalid markup” and done, the problem is on the user side, the developer job end here.

We want to simplify the format (not related with the photographic job, inefficient and complex to handle by humans) to introduce more features (related with the photographic job). We put a lot of hours to design a flexible structure.
Panoshoot handle several preset types. We only talk about the classic yaw-pitch (we call it STD or standard presets). Panoshoot handle many others including FHD (full high definition coordinates up to micro degrees with asymmetric timing and other features), GEO for semi-automatic outdoor panos , CEL for celestial coordinates, VID for video panning patterns , etc.)

It's not difficult to hand code a Papywizard-compatible preset in any text editor...

Maybe, but only for very simple and short presets that in the case of a plain text is even easier. Try to edit a large XML file with multiple fields manually. Without the appropiate tool (available in computers and not good in smartphones) there are a high change to invalidate the XML file just due you miss a slash or a markup.

The difficulty is working out what the co-ordinates of the shooting positions should be! Choosing a CSV format - rather than the Papywizard-compatible XML format definition for presets - doesn't help with that.

And more to the point, as I tried to explain there are many tools to automate the process of creating Papywizard-compatible presets. So had you adopted that definition your user could have used those tools too.

We are expanding and simplifying the preset concept.
Could you provide us with a case where will be important include the XML reading?

You only need a preset for shooting spherical panos; typical partial panos can be handled using a regular grid/matrix pattern ath Panoshoot can compute on-the-fly.

We was using a similar criteria to assign the priority of spherical optimization in our To-Do list (it can be done easily with a spreadsheet). Due you raise the importance, we will activate the check box in a eraly release.

[mediavets]

by mediavets » Mon Mar 25, 2013 7:23 pm

...Of course this raises another question. How do you expect users to work out the co-ordinates of a series of shots to create an optimal pattern for shooting spherical panos, wher it is desirable to reduce the number of shots per row as you approach the zenith and nadir to avoid excessive overlaps?

Are asking or are you explaining what is a spherical pano?
a spherical pano is just a simple optimization of a planar Mosaic. It can be done very easily on a spreadsheet. We will include the checkbox in the Mosaic to simplify the job.

I am not asking nor exlaining what spehrical pano is. Perhaps English is not your first language?

I merely stated the (blindingly) obvious that an optimised shooting pattern to cover a pano FOV of 360 x180 requires fewer shots per row as you approach the zenith and nadir if you are to maintain a similar overlap between adjacent images. Excessive overlapping is undesirable because it can confuse the stitching software and requires that you take more shots than are necessary.

Some robotic pano heads can calculate such a pattern automatically on demand - for example the T&C controller for Panogear/Merlin and Panoneed.

Papywizard does not do this - instead it relies on the user providing a suitable pattern as an XML formatted Preset file.

User's often found it difficult to work out optimised patterns for longer focal length lenses for shooting spherical panos.

There are some Preset generator programs available to assist users in creating Papywizard compatible optimised presets.

Panoshoot does not calculate optimised shooting patterns for spherical panos on demand - it relies on Preset patterns which can be loaded if in CSV format.

I was asking how you envisaged your Panoshoot users might create such optimised preset for shooting spehrical panos, because they would not be able to use the Preset generator developed for Papywizard because you chose to use CSV format, rather than adopting the XML format defined for Papywizard Presets.

[mediavets]

by mediavets » Mon Mar 25, 2013 7:30 pm

...B*llocks is the first word that comes to mind. My bullsh*t detector just went off the scale. It sounds to me that you just didn't think about it.

I think that you are going too fast. Probably you will need recalibrate your bullsh*t detector.

From a software developer point of view, is a lot easier handle XML files than CSV "human oriented" files. In XML everything is specified (that's why a lot of redundancy) and is a lot easier to "quiz" what data is coming. There many libraries to handle XML files, and if the user make a mistake, the developer just send a message “invalid markup” and done, the problem is on the user side, the developer job end here.

We want to simplify the format (not related with the photographic job, inefficient and complex to handle by humans) to introduce more features (related with the photographic job). We put a lot of hours to design a flexible structure.
Panoshoot handle several preset types. We only talk about the classic yaw-pitch (we call it STD or standard presets).

If that's the only type you talk about then that's the only sort I can comment on.

Panoshoot handle many others including FHD (full high definition coordinates up to micro degrees with asymmetric timing and other features), GEO for semi-automatic outdoor panos , CEL for celestial coordinates, VID for video panning patterns , etc.)

I feel blinded by science. I haven't a clue what you are talking about. Do any of these have any application in panoramic photography? If so, what and how?

[mediavets]

by mediavets » Mon Mar 25, 2013 7:35 pm

The difficulty is working out what the co-ordinates of the shooting positions should be! Choosing a CSV format - rather than the Papywizard-compatible XML format definition for presets - doesn't help with that.

And more to the point, as I tried to explain there are many tools to automate the process of creating Papywizard-compatible presets. So had you adopted that definition your user could have used those tools too.

We are expanding and simplifying the preset concept.
Could you provide us with a case where will be important include the XML reading?

I'm sorry but I don't understand your question.

You only need a preset for shooting spherical panos; typical partial panos can be handled using a regular grid/matrix pattern ath Panoshoot can compute on-the-fly.

We was using a similar criteria to assign the priority of spherical optimization in our To-Do list (it can be done easily with a spreadsheet). Due you raise the importance, we will activate the check box in a eraly release.

I think that's wise. I look forward to seing your spreadsheet tool to do this.

[klausesser]

by klausesser » Mon Mar 25, 2013 7:38 pm

Well, I don't know whether I can spell it out more exactly..... how about the XML data files generated by Panoshoot are not Papywizard compatible.

Yes - i just wanted to know your procedere.

best, Klaus

I downloaded the sample Panoshoot XML dat file from the link provided by Panoshoot developers:

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

Then I loaded that into the Papywizard Import filter in APG 3.0.5 32-bit version running on Windows XP Pro.

To inspect the XML data file coding I viewed the file with WordPad.

Is that enough information?

Let me try to point out what i mean - i insist because you mentioned "PapyWizard compatibility" many times already relating to the T&C . .

What is the goal: to be "compatible" by the books or being compatible in real life, doing real work?

Let´s talk about spheres:
Using PW on the Nokia i guess was the "most compatible" kind of using PW . . Right?
As i remember we needed to calculate a pattern first for being able to shoot a sphere. You helped me several times generating such a pattern (thanks again).
This pattern came as an xml file, right? So we shot a sphere for which the pattern gave the commands to the head (Merlin).

Which kind of XML are you using for importing it into APG for stitching actually?

best, Klaus

Last edited by klausesser on Mon Mar 25, 2013 7:39 pm, edited 1 time in total.

[javqui]

by javqui » Mon Mar 25, 2013 7:43 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.

Thanks for the feedback. I will consider your perspective profile for further approaches in order to optimize our communication level.

[javqui]

by javqui » Mon Mar 25, 2013 7:57 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?

Simple and intuitive building blocks (parameters) for the pulse provide you an easy way to synthesize and adjust the pulse(s) for the application.

off the topic, for extravagant and complex mixed pulses a Panoshoot multiprofile with FHD presets is the option (just to create new combinations for original jobs).
We will develop a documentation chapter about this topic soon. We don't want extend this topic at this moment.

[mediavets]

by mediavets » Mon Mar 25, 2013 10:02 pm

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?

Simple and intuitive building blocks (parameters) for the pulse provide you an easy way to synthesize and adjust the pulse(s) for the application.

That statement wins no awards for Plain English.

Is that 'Yes' or 'No'?

off the topic, for extravagant and complex mixed pulses a Panoshoot multiprofile with FHD presets is the option (just to create new combinations for original jobs).

'FHD'?

We will develop a documentation chapter about this topic soon. We don't want extend this topic at this moment.

I hope it will be more intelligible than your response above.

[mediavets]

by mediavets » Mon Mar 25, 2013 10:45 pm

Let me try to point out what i mean - i insist because you mentioned "PapyWizard compatibility" many times already relating to the T&C . .

What is the goal: to be "compatible" by the books or being compatible in real life, doing real work?

If you don't understand by now perhaps I should give up. I feel like I'm flogging a dead horse, as the saying goes.

The 'point' of definitions, standards and compliance is to ensure interoperability.

For example, standards and compliance with standards are why you can use the same Compact Flash card in different brands of camera and card reader; why WiFi equipment from different manufacturers can be mixed and matched; why TVs from different manufactuers can all receive and display the same standard signal from a broadcaster.

Let´s talk about spheres:
Using PW on the Nokia i guess was the "most compatible" kind of using PW . . Right?

Yes, Frederic devised the Papywizard XML format data file definition and implemented the capabilty for Papywizard to generate compliant files some time before Kolor developed the APP/APG Papywizard Import wizard. In doing so Kolor complied with the Papywizard 'standard'/ definition.

As i remember we needed to calculate a pattern first for being able to shoot a sphere. You helped me several times generating such a pattern (thanks again).

It seems like a long time ago now.

This pattern came as an xml file, right?

Correct; and the format of the file complied with the Papywizard standard/definition.

So we shot a sphere for which the pattern gave the commands to the head (Merlin).

The file contains co-ordinate data that the Papywizard program uses to position the head. The T&C controller, in contrast, calculates an optimised shooting pattern on demand and does not (and cannot) use Presets.

Which kind of XML are you using for importing it into APG for stitching actually?

I'm using an XML format data file generated by Panoshoot (and provided by the Panoshoot developers, I don't have a Panoshoot device) in relation to the discussion in this thread.

Presets are XML formatted input files created by the user; XML formatted data files are output files generated by the pano head controller (later used as input to APP/APG Import wizards).

[klausesser]

by klausesser » Mon Mar 25, 2013 11:03 pm

The 'point' of definitions, standards and compliance is to ensure interoperability.

Right. And when "interoperability" is already there because everything works fine: what´s the problem?

I'm using an XML format data file generated by Panoshoot (and provided by the Panoshoot developers, I don't have a Panoshoot device) in relation to the discussion in this thread.

Presets are XML formatted input files creatd by teh user; XML formatted data files are output files generated by the pano head controller (later used as input to APP/APG Import wizards).

No images involved at all? That was my question. So how do you recognize whether it works well or not when you didn´t import images which the xml put into position? (excuse me for being dumb)

Did i miss something?

best, Klaus

[javqui]

by javqui » Tue Mar 26, 2013 12:02 am

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?

Simple and intuitive building blocks (parameters) for the pulse provide you an easy way to synthesize and adjust the pulse(s) for the application.

That statement wins no awards for Plain English.

Is that 'Yes' or 'No'?

I misunderstood your question. In Plain English, probably the question should be "will AEB sequence generate multiple XML records for a single shoot?"
Papywizard insert dumb records (time approximations of the AEB sequence) in the XML report.
Panoshoot insert one record in the XML report for each effective pulse.

We will add a check box to include the dumb records in the XML report as papywizard do.
Some photographers prefer keep the same picture number (ID) with different bracket identification.

Thanks for the suggestion.

off the topic, for extravagant and complex mixed pulses a Panoshoot multiprofile with FHD presets is the option (just to create new combinations for original jobs).

'FHD'?.

A brief description of the different Panoshoot preset types including FHD- presets was answered previously in your own post chain.
According with your own feedback, FHD presets will not be a big advantage for your specific application.

We will develop a documentation chapter about this topic soon. We don't want extend this topic at this moment.

I hope it will be more intelligible than your response above.

We try our best and will continue improving the user experience and expanding the features with this multi-purpose wireless device as we did for the CES2013 where Panoshoot was awarded as one of the best implementations of highly integrated Wi-Fi embedded technology by our Wireless technology provider.

[mediavets]

by mediavets » Tue Mar 26, 2013 12:04 am

The 'point' of definitions, standards and compliance is to ensure interoperability.

Right. And when "interoperability" is already there because everything works fine: what´s the problem?

I'm not talking about T&C particularly in this Thread. I'm talking specifically about Panoshoot which is much less compliant..

If you consider that all that's required to be Papywizard-compatible is to record Y/P/R co-ordinates according to the Papywizard dat file definition then you file may 'work' with the APP/APG Papywizard Import wizard but it is probably not fully compliant with the Papywizard XML data file definition. The best you could say is that it's partially complaint with that definition and 'works' with the APP/APG Papywizard Import wizard. If you still don't understand the difference I shall be forced to give up.

Now suppose that Kolor, PTGui or some other software, decided to make use of other data defined in the papywizard XML data file definition, and your XML file didn't record that data in the same way, your file would no 'longer 'work with the software. But if your file had fully complied with the standard it would still work.

As things stand there are data values in the header section of the Paywizard XML data file definition that the Papywizard Import filter does read and report to the user. Some of these don't exist at all in the panoshoot data files, and some do but not in the correct format so the Import wizard cannot read them.

Hence, in my book, Panoshoot XML data files do not 'work' with the APP/APG Paywizard Import wizard.

There are at least obvious solutions:

1. Panoshoot makes their XML files fully compliant with tyhe papywizard XML data file definition - probably impossible since they have different terminology and a different approach to some 'stuff'

2. Panoshoot increases the partial compatibility of their XML data files so that the recordings of those data values that the APP/APG Papywizard Import wizard uses are made compliant.

3. Panoshoot contiunues with their own XML data file definition and works with Kolor to create a new Import wizard for Panoshoot. I think this may be the best approach for Panoshoot and their users. Seitz took this path after initially having taken the partial Papywizard compliant approach.

I'm using an XML format data file generated by Panoshoot (and provided by the Panoshoot developers, I don't have a Panoshoot device) in relation to the discussion in this thread.

Presets are XML formatted input files creatd by teh user; XML formatted data files are output files generated by the pano head controller (later used as input to APP/APG Import wizards).

No images involved at all? That was my question. So how do you recognize whether it works well or not when you didn´t import images which the xml put into position? (excuse me for being dumb)

Did i miss something?

best, Klaus

I wasn't provided with images. That doesn't matter, the wizard was able to read the shooting position co-ordinates.

What it could not read in the Panoshoot XML data files were values in the header section that were either entirely absent or incorrectly formatted.