Panoshoot Wireless Control Module for Panogear

[panoramicessentials.com]

Panoshoot Wireless Control Module for Panogear

by panoramicessentials.com » Thu Mar 21, 2013 7:22 am

Hey everyone,

Yesterday Kolor launched the sale of Panoshoot a wireless control module designed and developed by Javier Quintata and myself (Adam Shehadeh). You can get information from our website http://www.panoshoot.com. I will make myself available at most hours of the day for the next few days to answer any questions or concerns you may have about Panoshoot.

Adam

[mediavets]

by mediavets » Thu Mar 21, 2013 9:07 am

Hey everyone,

Yesterday Kolor launched the sale of Panoshoot a wireless control module designed and developed by Javier Quintata and myself (Adam Shehadeh). You can get information from our website http://www.panoshoot.com. I will make myself available at most hours of the day for the next few days to answer any questions or concerns you may have about Panoshoot.

Adam

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

[mediavets]

by mediavets » Thu Mar 21, 2013 9:32 am

Hey everyone,

Yesterday Kolor launched the sale of Panoshoot a wireless control module designed and developed by Javier Quintata and myself (Adam Shehadeh). You can get information from our website http://www.panoshoot.com. I will make myself available at most hours of the day for the next few days to answer any questions or concerns you may have about Panoshoot.

Adam

There's no shortage of alternative controllers for the Panogear/Merlin mount now.

I note that you state on your Web site:

"Although it is initially designed for Kolor's Panogear, Panoshoot will soon be available for other motorized mounts. "

Can you share any insights into your meaning of 'soon' and 'other motorized mounts'?

[mediavets]

by mediavets » Thu Mar 21, 2013 9:32 am

This seems a bit 'clunky' but maybe I don't quite understand it?:

[mediavets]

by mediavets » Thu Mar 21, 2013 1:52 pm

What is the minimum size and resolution of diplay required to use a mobile or tablet device with Panoshoot?

What is the practical minimum size of display and resolution of display required on a touch orientated device.

Does the UI scale with the size and resolution of the display.

Can you change UI orientation between portrait and landscape on the fly? Does the layout change at all when you do?

Do you an online emulator fpr the Panohoot device so that potential customers could get a feel for how the system operates before purchasing the hardware?

[javqui]

by javqui » Thu Mar 21, 2013 8:51 pm

What is the minimum size and resolution of diplay required to use a mobile or tablet device with Panoshoot??

A- with a HTML5 browser, no minimum resolution or screen size restrictions. Standard smartphone screen sizes are ok for touch interface (finger size), Smaller screen size are ok if you have a pointing device smaller than regular touch finger area.
To avoid horizontal scrolling, a minimum horizontal resolution of 320 is recommended.
To easily access the joystick, a minimum vertical resolution of 460 pixels is recommended.

What is the practical minimum size of display and resolution of display required on a touch orientated device.

A- Standard smartphone screen size is ok.
Large screens (tablets, PCs, large smartphones) will show the joystick controller and main screen simultaneously.
For small screens will be better use Panoshoot in vertical (portrait) orientation.
The mobile device browser will scale and adjust the size and orientation to fit the UX in the screen automatically
You can zoom-in and zoom-out like other regular web site.
We recommend lock the orientation to avoid switching between accidentally, particularly If you use the Panoshoot spatial motion controller (it require the accelerometers, gyro and magnetic compass sensors from your portable device)

Can you change UI orientation between portrait and landscape on the fly? Does the layout change at all when you do?

A- The browser will adjust the size at load. The UX layout will adjust at load. if you want to change the orientation with the same layout, just turn your device. If you want change the orientation and change the layout just rotate your device and refresh.
On large screen without orientation sensors (PCs) the layout will adjust to the current browser window size at load (browser window width).

Do you an online emulator fpr the Panohoot device so that potential customers could get a feel for how the system operates before purchasing the hardware?

A- A Panoshoot emulator will be available soon. Additionally, a real demo (panoshoot+panogear+camera) connected directly to internet could be available for a limited time.

[gkaefer]

by gkaefer » Fri Mar 22, 2013 12:58 am

This seems a bit 'clunky' but maybe I don't quite understand it?:

you dont miss something...
some lines lower an Addition note explains that you can immediateley can start a new session by overwriting the existing XML...

lol

[Rami]

by Rami » Fri Mar 22, 2013 10:05 am

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

[mediavets]

by mediavets » Fri Mar 22, 2013 10:21 am

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 » Fri Mar 22, 2013 10:23 am

Bounce...for Adam and/or javqui...

Hey everyone,

Yesterday Kolor launched the sale of Panoshoot a wireless control module designed and developed by Javier Quintata and myself (Adam Shehadeh). You can get information from our website http://www.panoshoot.com. I will make myself available at most hours of the day for the next few days to answer any questions or concerns you may have about Panoshoot.

Adam

There's no shortage of alternative controllers for the Panogear/Merlin mount now.

I note that you state on your Web site:

"Although it is initially designed for Kolor's Panogear, Panoshoot will soon be available for other motorized mounts. "

Can you share any insights into your meaning of 'soon' and 'other motorized mounts'?

[panoramicessentials.com]

by panoramicessentials.com » Fri Mar 22, 2013 2:42 pm

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?

We will offer support through our Support Ticket System and through the live chat when we are available.

[panoramicessentials.com]

by panoramicessentials.com » Fri Mar 22, 2013 2:44 pm

Bounce...for Adam and/or javqui...

Hey everyone,

Yesterday Kolor launched the sale of Panoshoot a wireless control module designed and developed by Javier Quintata and myself (Adam Shehadeh). You can get information from our website http://www.panoshoot.com. I will make myself available at most hours of the day for the next few days to answer any questions or concerns you may have about Panoshoot.

Adam

There's no shortage of alternative controllers for the Panogear/Merlin mount now.

I note that you state on your Web site:

"Although it is initially designed for Kolor's Panogear, Panoshoot will soon be available for other motorized mounts. "

Can you share any insights into your meaning of 'soon' and 'other motorized mounts'?

As with any product development you don't want to give a solid date because nothing is ever guaranteed to work out the way we plan but I can safely say that sometime in April 2013 we should have Skywatcher compatibility.

[mediavets]

by mediavets » Fri Mar 22, 2013 3:01 pm

As with any product development you don't want to give a solid date because nothing is ever guaranteed to work out the way we plan but I can safely say that sometime in April 2013 we should have Skywatcher compatibility.

Is there a Skywatcher mount that would be capable of rotating a camera/lens around the No Parallax Point (aka Entry Pupil)?

[panoramicessentials.com]

by panoramicessentials.com » Fri Mar 22, 2013 3:08 pm

As with any product development you don't want to give a solid date because nothing is ever guaranteed to work out the way we plan but I can safely say that sometime in April 2013 we should have Skywatcher compatibility.

Is there a Skywatcher mount that would be capable of rotating a camera/lens around the No Parallax Point (aka Entry Pupil)?

The Skywatcher Allview mount specifically, I forgot that Skywatcher is a broad term. I am not sure if it is used for panoramas. I currently sell the Allview mount and most of my sales have gone to astronomy and videographers. From my perspective the Allview mount is too bulky for panoramic photography especially if you are a landscape photographer who has to carry it out into the field.

[mediavets]

by mediavets » Fri Mar 22, 2013 3:16 pm

As with any product development you don't want to give a solid date because nothing is ever guaranteed to work out the way we plan but I can safely say that sometime in April 2013 we should have Skywatcher compatibility.

Is there a Skywatcher mount that would be capable of rotating a camera/lens around the No Parallax Point (aka Entry Pupil)?

The Skywatcher Allview mount specifically, I forgot that Skywatcher is a broad term. I am not sure if it is used for panoramas. I currently sell the Allview mount and most of my sales have gone to astronomy and videographers. From my perspective the Allview mount is too bulky for panoramic photography especially if you are a landscape photographer who has to carry it out into the field.

Oh....I had understood that the AllView mount was 'plug-compatible' with the Panogear/Merlin mount for control using, say, Papywizard.

Perhaps I am mistaken?

See: http://www.kolor.com/forum/f45-allview

[panoramicessentials.com]

by panoramicessentials.com » Fri Mar 22, 2013 3:40 pm

Is there a Skywatcher mount that would be capable of rotating a camera/lens around the No Parallax Point (aka Entry Pupil)?

The Skywatcher Allview mount specifically, I forgot that Skywatcher is a broad term. I am not sure if it is used for panoramas. I currently sell the Allview mount and most of my sales have gone to astronomy and videographers. From my perspective the Allview mount is too bulky for panoramic photography especially if you are a landscape photographer who has to carry it out into the field.

Oh....I had understood that the AllView mount was 'plug-compatible' with the Panogear/Merlin mount for control using, say, Papywizard.

Perhaps I am mistaken?

See: http://www.kolor.com/forum/f45-allview

Initial testing showed that it wasn't completely compatible. Movements and camera trigger worked from the manual joystick but using the software to send commands will require some adjustments. It was a big surprise for us.

[mediavets]

by mediavets » Sat Mar 23, 2013 2:51 pm

Presets and PicPoints:

I am familiar with the creation and use of Presets with Papywizard.

The Panoshoot approach to Presets seems particularly badly thought out :

1. The idea of using the Panshoot UI to build presets by moving the head under program control and then setting a PicPoint is ludicrous, quite impracatical in my opinion.

2. The alternative offered is to import a list of shooting co-ordinates in CSV format. Why didn'y you adopt the existing Preset XML definition/format creatd for Papywizard presets? There are several preset buolding tools for that format.

3. What happens during a shoot if a preset includes co-ordinates that lie outside the user-defined Yaw and Pitch limits set in Panoshoot?

4. Several robotic pano head systems - amongst others the T&C controller for Merlin and Panoneed, and the Seitz VRDrive2 - can calculate an optimal shooting pattern for spherical panos on-the-fly, ie. not a regular grid/matrix. Papywizard does not, instead it uses presets, data files that describe/define a pattern of shooting co-ordinates. Why did you choose to adopt the less user-friendly preset approach rather than have the program calculate a pattern on-the-fly using the camera and lens data you have already stored in the system?

[mediavets]

by mediavets » Sat Mar 23, 2013 3:07 pm

XML format data files:

1. Why can you not store more than one XML data file at a time on the Panoshoot device? As I understand it you must download the XML data file after each panorama shoot before you can shoot another panorama, unless you choose to overwrite the first XML data file. Or have I misunderstoofd the decsription in the User Manual?

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?

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

[mediavets]

by mediavets » Sat Mar 23, 2013 3:22 pm

Panoshoot Timing profiles:

1. I'm not sure I really understand what the various fields/values in the Timing Profiles mean (screenshot from manual below).

Are the Stabilization Pause, Obturator Time and After Shot Pause additive?

2. Obturator is such an unsual word - why did you choose it? I am particularly confused by what it represents and how it should be calculated. (And yes, I've watched the tutorial videos).

3. For how long is the Snap connector contact closed - is it the Obturator Time value?

3. The Speed/Accuracy trade off is intriguing. Can you say more about how this wroks and the implications of choosing higher speed over accuracy in the real world of pano shooting and stitching?

[mediavets]

by mediavets » Sat Mar 23, 2013 4:05 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.

[gkaefer]

by gkaefer » Sat Mar 23, 2013 6:32 pm

XML format data files:

1. Why can you not store more than one XML data file at a time on the Panoshoot device? As I understand it you must download the XML data file after each panorama shoot before you can shoot another panorama, unless you choose to overwrite the first XML data file. Or have I misunderstoofd the decsription in the User Manual?

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?

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

ad 1.
I prognosticate that this is no deficit, because you Need to have connected an note/net/ultra-book/andoid/idevice whichever Java/browser capable devcice to get directly connected to the builtin webserver of the device to Access the UI. So if you have your device connected via wlan to the panoshoot device to use the device than the download of the one XML file should be done automatically...

Georg

Last edited by gkaefer on Sat Mar 23, 2013 6:33 pm, edited 1 time in total.

[mediavets]

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

XML format data files:

1. Why can you not store more than one XML data file at a time on the Panoshoot device? As I understand it you must download the XML data file after each panorama shoot before you can shoot another panorama, unless you choose to overwrite the first XML data file. Or have I misunderstoofd the decsription in the User Manual?

ad 1.
I prognosticate that this is no deficit, because you Need to have connected an note/net/ultra-book/andoid/idevice whichever Java/browser capable devcice to get directly connected to the builtin webserver of the device to Access the UI. So if you have your device connected via wlan to the panoshoot device to use the device than the download of the one XML file should be done automatically...

Georg

Yes, but it appears from the manual that it is not automatic.

[javqui]

by javqui » Sun Mar 24, 2013 7:58 pm

Hi Andrews,
Sorry for the answers delay, I was a little busy with a particular family event these days.
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.
Apologize if we miss something or we didn’t understand some part of your questions. We will try our best to satisfy your requirements.

Presets and PicPoints:

1. The idea of using the Panshoot UI to build presets by moving the head under program control and then setting a PicPoint is ludicrous, quite impracatical in my opinion.

We believe that is not the primary intention of this feature. The intention is to edit PicPoints on the field or set a few Picpoints for a quick job on the field, not to load a complete set of PicPoints as we mention in an early post. Just image load something like 2000 PicPoints manually, one by one, it’s ridiculously crazy.

2. The alternative offered is to import a list of shooting co-ordinates in CSV format. Why didn'y you adopt the existing Preset XML definition/format creatd for Papywizard presets? There are several preset buolding tools for that format.

The import PicPoints mechanism is not the alternative, is the main and practical method to load PicPoints data.
XML is a format to interchange data between computers that can be read by humans but difficult to write by humans. You can easily be lost in complex and large XML files without the help of specialized XML formatter app. XML is a nice format for non tabular data, but the cost is a lot of redundancy with file size increase and extra processing.

Simple Comma-delimited format is a lot easier and natural to handle by humans, standard between different platforms and supported for all calc programs like Spreadsheets (excel, open office), math lab and many others. You can type a tabular data easily on whatever platform with a simple text editor (even with a Smartphone) without worry about type all marker rules for each row, column or element. You need validate the XML file to check that you don’t miss any mandatory element delimiter that could invalidate the file.

Probably we didn’t have enough time to evaluate all preset building tools that you mention, but some of them use spreadsheets as the main calc tool. If you have a specific case, we will do our best to create a spreadsheet equivalent. (Users will not need install extra apps in computers and learn extra tools)

In short XML is extremely inefficient with highly structure data (it was not its primary design goal [url][url]http://en.wikipedia.org/wiki/XML#Criticism[/url] )[/url] and PicPoints (including advanced modes) and Papywizard use a highly structured tabular data. We want to simplify the Panoshoot programming to permit end user be focus in the specific details of their application, not in the details of XML rules.

3. What happens during a shoot if a preset includes co-ordinates that lie outside the user-defined Yaw and Pitch limits set in Panoshoot?

Before run a program (runner) , Panoshoot validate the data and compute the limits of the complete session to handle the progress website feedback. If the limits are out of the bounds, it will not start the session. On current version (build #94, web 1.94) you can define the limits for pitch and yaw for each profile, but the protection check is not active, yet. It will be active in next update. (Limit calculations for UX feedback are active and working in current version)

4. Several robotic pano head systems - amongst others the T&C controller for Merlin and Panoneed, and the Seitz VRDrive2 - can calculate an optimal shooting pattern for spherical panos on-the-fly, ie. not a regular grid/matrix. Papywizard does not, instead it uses presets, data files that describe/define a pattern of shooting co-ordinates. Why did you choose to adopt the less user-friendly preset approach rather than have the program calculate a pattern on-the-fly using the camera and lens data you have already stored in the system?

A-. The spherical pattern is one of the hundred options that you can use. A planar Mosaic grid is the easiest and most intuitive pattern. Custom movement patterns can be created with the spreadsheet –PicPoints preset mechanism. The Panoshoot concept is to simplify the interface and standardize the patterns as much as possible.
A check box with spherical mosaic pattern optimization is available on Mosaic menu but is not active on current version (build #94, web 1.94). As you request, we will raise the priority to release this Mosaic optimization option soon.

XML format data files:

1. Why can you not store more than one XML data file at a time on the Panoshoot device? As I understand it you must download the XML data file after each panorama shoot before you can shoot another panorama, unless you choose to overwrite the first XML data file. Or have I misunderstoofd the decsription in the User Manual?

Probably the term “download XML” and “do not overwrite” are not the most appropriated, but probably are the intuitive terms in the internet jargon.
All session XML logs are saved in the user device for post-processing in Autopano image stitching software, not in Panoshoot. The original Panoshoot was designed to save the XML session file in your device after each session if you are connected to Panoshoot or before start a new one if you decide to “do not overwrite” that means “remember me if I want to save or not the session log” to avoid save multiple logs of preliminary test runs. We agree with you that it’s not fully intuitive and it will require some polish terminology. We will explore a better solution and mechanism to be transparent to the end user and avoid misunderstood it.

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.

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

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

…. About XML download. …..Yes, but it appears from the manual that it is not automatic.

The download of previous session is automatic when you start a new session (when you have the option “do not overwrite”). We will include an automatic save (or “download”) at the end of the session to provide better functionality in next update and change the wording to be more user-friendly.



Panoshoot Timing profiles:

1. I'm not sure I really understand what the various fields/values in the Timing Profiles mean (screenshot from manual below).
Are the Stabilization Pause, Obturator Time and After Shot Pause additive?

Here is a more detail description of the terms (sorry, I tried format as a table with BBCode but didn't work)

Code: Select all

Stabilization Pause:
-range:0 to 25 seconds
-resolution (step increments):100 ms (0.1 s)
-description:Time between the head movement and the first shoot. This time is related to robotic head-camera inertia stabilization.

Obturator time:
-range:0 to 46 hours
-resolution (step increments):10 ms (0.01 s)
-description:Time of “shutter signal” ON. Small values define the minimum time that the camera needs to understand a valid pulse.
Large values are useful to shoot very long exposure images (close to 2 days for astronomy photography).

After shot pause
-range:0 to 46 hours
-resolution (step increments):10 ms (0.01 s)
-description:Pause between shoots in a multiple-shoot or bracketing mode and before next movement. Small values define the minimum time that the camera needs to process the image before accept the next shoot. Large values are useful for time-lapse images.

Once one event happen, the next one is immediately consecutive to the previous one, so the times are additive as you correctly mention.

Differences with Papywizard:
Stabilization pause: papywizard execute this pause before each shoot. Panoshoot execute this pause after each head movement. (We consider that if the head is not moving, there is no reason to execute a stabilization pause on every multi-shoot or bracketing).
“Obturator Time”- “After shot pause” in Panoshoot simplifies and expands the definition of “Pulse width high”, “Pulse width low” and “Time value” in papywizard.
The time in Panoshoot is precisely handled by the internal microcontroller timing clock and doesn’t have the external host and link (Bluetooth /serial/Ethernet interface) limitations.

Just want to complement that Panoshoot can operate fully offline (all logic, timing and functionality are embedded internally). It means that Panoshoot does not require the host (user device) to start and/or run a session (you can start a session with a 5 seconds single push of the joystick).

2. Obturator is such an unsual word - why did you choose it? I am particularly confused by what it represents and how it should be calculated. (And yes, I've watched the tutorial videos).

The first reason was to avoid confusion with the papywizard shutter time definitions.
The second reason was the fact that the term obturator has a Multilanguage interpretation: Obturator (or camera shutter, valid in English), obturador (Spanish, Portuguese, Catalan, Gallego ), obturateur (French) and a little different in Italian otturatori.
There is no other reason.

3. For how long is the Snap connector contact closed - is it the Obturator Time value?

Yes.

4. The Speed/Accuracy trade off is intriguing. Can you say more about how this wroks and the implications of choosing higher speed over accuracy in the real world of pano shooting and stitching?

As you know, “TRON” movements are only possible in a virtual world with mass=0. In a real world we need to deal with the inertia of body mass. In a real world, there is a trade-off between precision and speed. You can reduce (but never cancel it) the trade-off range with strong motors, gears and breaks like automobiles do (formula 1/expensive cars vs. economic cars/bicycles).
Panoshoot compute and maximize the initial movement speed according with the trade-off speed/accuracy in order to reach an “acceptable stop point” in the minimum time possible. In some applications with an overlap of 25%-35%, a position deviation of some degrees is not relevant. Other applications require a more precise position before shoot.

If your application doesn’t require any precise position you should use 100% for the speed-accuracy trade-off to reduce the session time and finish it as soon as possible with acceptable image overlaps. If your application requires a very high position precision, you should use 1% for the speed-accuracy trade-off.

A middle point of 50% will produce an intermediate result between speed and accuracy.

The mechanism of how Panoshoot compute the initial speed and final position is a little complex and it depends on several factors, including inertia, status of other axis, input voltage, maximum prorated acceptable error, prorated speed range of head and previous experiences, between others, all defined by a single and intuitive user parameter “speed/accuracy trade-off” . Without wishing to introduce complexity and extend this post, Panoshoot try to reduce the position error as a prorated scale related with the image overlap and a fixed error parameter by maximizing the speed according with the head inertia and previous experience (self learning). When the precision requirement is high (means a low speed/accuracy parameter), Panoshoot could introduce a secondary micro movement, (better known as overshoot in control systems) to reduce the approximation time and reduce the final position error. The Panoshoot API provides the capacity to configure the overall behavior.

in short, the simple term “speed/accuracy trade-off” is the main input for the fuzzy algorithms implemented in Panoshoot to resemble the intuitive human interpretation of things like “a little more”, “faster”, “better”, ”cold”, “warm”, “hot”, “a pinch of salt” that doesn’t provide a computer parametric exact value.

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

[mediavets]

by mediavets » Sun Mar 24, 2013 9:20 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?

[mediavets]

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

Presets and PicPoints:

1. The idea of using the Panshoot UI to build presets by moving the head under program control and then setting a PicPoint is ludicrous, quite impracatical in my opinion.

We believe that is not the primary intention of this feature. The intention is to edit PicPoints on the field or set a few Picpoints for a quick job on the field, not to load a complete set of PicPoints as we mention in an early post. Just image load something like 2000 PicPoints manually, one by one, it’s ridiculously crazy.

2. The alternative offered is to import a list of shooting co-ordinates in CSV format. Why didn'y you adopt the existing Preset XML definition/format creatd for Papywizard presets? There are several preset buolding tools for that format.

The import PicPoints mechanism is not the alternative, is the main and practical method to load PicPoints data.
XML is a format to interchange data between computers that can be read by humans but difficult to write by humans. You can easily be lost in complex and large XML files without the help of specialized XML formatter app. XML is a nice format for non tabular data, but the cost is a lot of redundancy with file size increase and extra processing.

That's more sensible. I think you should change the emphasis in the User Manual accordingly.

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?

Simple Comma-delimited format is a lot easier and natural to handle by humans, standard between different platforms and supported for all calc programs like Spreadsheets (excel, open office), math lab and many others. You can type a tabular data easily on whatever platform with a simple text editor (even with a Smartphone) without worry about type all marker rules for each row, column or element. You need validate the XML file to check that you don’t miss any mandatory element delimiter that could invalidate the file.

Probably we didn’t have enough time to evaluate all preset building tools that you mention, but some of them use spreadsheets as the main calc tool. If you have a specific case, we will do our best to create a spreadsheet equivalent. (Users will not need install extra apps in computers and learn extra tools)

In short XML is extremely inefficient with highly structure data (it was not its primary design goal [url][url]http://en.wikipedia.org/wiki/XML#Criticism[/url] )[/url] and PicPoints (including advanced modes) and Papywizard use a highly structured tabular data. We want to simplify the Panoshoot programming to permit end user be focus in the specific details of their application, not in the details of XML rules.

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.

It's not difficult to hand code a Papywizard-compatible preset in any text editor. 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.

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.