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:mediavets wrote:
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.
mediavets wrote:
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.
mediavets wrote:
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)
mediavets wrote:
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:mediavets wrote:
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.
mediavets wrote:
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.
mediavets wrote:
3. Can you post an example of an XML data file created by Panoshoot please?
http://panoshoot.javqui.com/forum/session.xmlmediavets wrote:
…. 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:mediavets wrote:
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:
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).
mediavets wrote:
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.
mediavets wrote:
3. For how long is the Snap connector contact closed - is it the Obturator Time value?
Yes.
mediavets wrote:
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:mediavets wrote:
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.)
Login
Register
FAQ
Search
