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