Clearing the myths about Panogear head

[javqui]

Clearing the myths about Panogear head

by javqui » Mon May 13, 2013 4:31 pm

This is a derivate work from our Panoshoot work and my humble contribution to the professional and enthusiast panorama community.
Comments are welcome.

http://panoshoot.javqui.com/panogear_myths.pdf


Summary
Current Panogear owners could be surprised and will have plenty of reasons to be happy after reveal the unpublished capabilities of their Panogear head investment.

Recently, Panogear has been incorrectly labeled as a low performance panoramic tripod head. There are several origins of these myths created around the Panogear, most due to limitations of the Papywizard software and others from 3rd parties who have ulterior motive.
In order to demystify these myths, let me introduce a brief metaphor. Panogear is a versatile Pano head with a wide range of capabilities, like a car with a powerful motor (engine), great transmission and sticky tires. The available car drivers to handle this great machine were limited to mostly old conservative drivers (papywizard) or new experimental/inexperienced drivers performing the wrong tasks.
The Panogear motor can accelerate quickly and reach high speeds, the transmission provide a large amount of drive condition options and the tires are sticky enough to grip to the equipment but with a minimum and required drift to protect the transmission.
Papywizard was a very well designed tool with many features for its time, but unfortunately it has not been updated for some time, given the space for the myths and unfounded speculative arguments.
The data and experience collected to prepare this document is a derivative work from the Panoshoot development project and comments related with Panoshoot are included in the demystification.


The Myths:
1. Panogear is slow.
2. Panogear is not accurate enough for giant Panos.
3. Panogear has a low weight equipment capacity.
4. Panogear is not easy to operate.



Javier
update document v1.1 rewording myth names at user suggestion..

Last edited by javqui on Mon May 13, 2013 8:37 pm, edited 1 time in total.

[mediavets]

by mediavets » Mon May 13, 2013 5:37 pm

The Myths:
1. Panogear is slow
2. Panogear is not accurate enough for professional jobs.
3. Panogear has a low weight equipment capacity
4. Panogear is not user friendly

Javier

1. The speed statistics you publish are interesting - you say they compare Panoshoot with similar settings for Papywizard but we don't get to see what settings you used in Papywizard nor what host platform you used to run Papywizard, nor what version of Papywizard you used, nor what type of connection you used between the Panogear/merlin mount and the Papywizard host.

2. I am not aware that anyone ever said that "Panogear is not accurate enough for professional jobs."

3. It's long been advised that heavy gear should be mounted at the centre of mass - nothing new there.

4. Panogear - in the sense of the Merlin mount - is neither friendly nor unfriendly to the user it's just a 'dumb' mechanical device . I presume you are instead referring to various means of controlling the Panogear/Merlin mount for pano shooting ? - Papywizard and the T&C touch controller or PandroidWiz. Like beauty user-frendliness seems to be in the eye of the beholder. I've never found papywizard hard to use but then I had a hand in the look-n-feel of the UI.

Last edited by mediavets on Mon May 13, 2013 9:55 pm, edited 1 time in total.

[tws7]

by tws7 » Mon May 13, 2013 5:55 pm

Ah Ive never had any of those problems and I get much better results than my manual head.(panoshoot is still a work in progress but is getting better)

[javqui]

by javqui » Mon May 13, 2013 7:11 pm

1. The speed statistics you publish are interesting - you say they compare Panoshoot with similar settings for Papywizard but we don't get to see what settings you used in Papywizard nor what host platform you used to run Papywizard, nor what version of Papywizard you used, nor what type of connection you used between the Panogear/merlin mount and the Papywizard host.

Probably you save a copy of the document and you will be able to re-open and read it again.
Could be interesting publish the real measurement of speed, resolution, accuracy and precision of your T&C head at the same conditions.

2. I am not aware that anyone ever said that "Panogear is not accurate enough for professional jobs."

It was the feedback that developers receive.

3. It's long been advised that heavy gear shoudl be mounted at the centre of mass - nothing new there.

The point is not about where and how install the heavy equipment. The myth is about capacity to handle heavy equipment. Panogear specifications show half of real capacity.
Additionally, some users are convinced that Panogear can't handle heavy equipment due the slip protection mechanism.

4. Panogear - in the sense of the Merlin mount - is neither friendly nor unfriendly to the user it's just a 'dumb' mechanical device . I presume you are instead referring to various means of controlling the Panogear/Merlin mount for pano shooting ? - Papywizard and the T&C touch controller or PandroidWiz. Like beauty user-frendliness seems to be in the eye of the beholder. I've never found papywizard hard to use but then I had a hand in the look-n-feel of the UI.

Panogear is not a "dumb" mechanical device. It has a dual microcontroller to handle the complexity of the movement that controls the acceleration, breaking system, positioning, constant speed, command interface, etc.
Probably if you thing that Panogear only understand move to, stop and give me the position, you could be right, but there are many other things that Panogear do, and that is part of the myth.
The user interface and features are one of the most important components when you evaluate a robotic head.
A head with a poor User interface will lock the capabilities of any head and will force the user to think on how to handle it the head instead focus on the real job.
Is more difficult create a new full graphics game if you are using a green text screen computer with a DOS.

[javqui]

by javqui » Mon May 13, 2013 9:15 pm

Hi tws7
Thanks for the feedback.

We collect several comments from Kolor forum, external forums and short talks with other Panogear distributors to find the critical points of Panogear and what need to be improved.

As the document mention, for most common Pano jobs, accuracy and precision are not relevant, due for years Pano users have been hidden the issue with large overlaps ratios (I was reading an external forum where some users use a default of 40% overlap without reason, just in case. It’s about 89% more pixels than the final panorama will have). For manual heads is OK, but if the user made an investment in a versatile robotic head, the idea is to use the capacity of the "robotic” word to improve the job and save time.

If you save the raw images for all Panos that you take, you will notice the issue quickly by looking the hard drives stack that probably you will start collecting.

Fortunately, large storage is economic up to some level, but time is highly valuable.
Shooting an indoor pano for a typical house with 4-5 rooms will take at least half the time when compare with current popular belief.
Some photographers didn't found a substantial difference in time and precision when compared the robotic head with a manual calibrated head. At the end, probably the manual head could be faster for an experienced photographer with large lens, large overlaps and tons of redundancy pixels when compared with low performance robotic head- user interface. This is a real myth and the truth is just the opposite.

Last edited by javqui on Mon May 13, 2013 9:24 pm, edited 1 time in total.

[klausesser]

by klausesser » Mon May 13, 2013 9:39 pm

The Myths:
1. Panogear is slow.
2. Panogear is not accurate enough for giant Panos.
3. Panogear has a low weight equipment capacity.
4. Panogear is not easy to operate.

1. = no myth - it IS slow . . i used it for two years and can state this "myth". Using a 105mm lens for example threatens your nerves. You will realize that immediately when you use a "modern" head.
2. = no myth also - i used it for two years and can state this "myth" when it come to long lenses. But you can use 50% overlap ofd course . .
3. = i guess nobody will put a very expensive - and usually heavy- and big camera on it.
4. = using the Nokia and BT i wouldn´t get it run these days (tried it some weeks ago - but forgot the procedere of conecting it via BT.)

Honestly: the Merlin is a great device. But nobody should expect too much from it´s mechanics and it´s electrics - it´s cost comes for a price . . . :cool:

best, Klaus

[mediavets]

by mediavets » Mon May 13, 2013 9:45 pm

1. The speed statistics you publish are interesting - you say they compare Panoshoot with similar settings for Papywizard but we don't get to see what settings you used in Papywizard nor what host platform you used to run Papywizard, nor what version of Papywizard you used, nor what type of connection you used between the Panogear/merlin mount and the Papywizard host.

Probably you save a copy of the document and you will be able to re-open and read it again.
Could be interesting publish the real measurement of speed, resolution, accuracy and precision of your T&C head at the same conditions.

And maybe you should read my post again. I am aware you have problems some with English but I think what I wrote was plain enough.

I read your PDF and nowhere do I see the settings you used in papywizard when producing the comparative timings, nor which version of Papywizard you used, nor which OS, nor the type of connection .... perhaps I failed to spot those details?

Last edited by mediavets on Mon May 13, 2013 9:52 pm, edited 1 time in total.

[klausesser]

by klausesser » Mon May 13, 2013 9:51 pm

A head with a poor User interface will lock the capabilities of any head and will force the user to think on how to handle it the head instead focus on the real job.

I fully agree! That´s why i took part in developing and now use the TC controller for a quite time first on Merlin and now on the Panoneed-head . . :cool: hardly possible to find a device which follows the KISS rule more rigid.

Is more difficult create a new full graphics game if you are using a green text screen computer with a DOS.

What one really NEEDS for shooting is a simple-and-straight device instead of a fancy colored one which you need studying a handbook to use . .

But these gadgets definitely look more attractive to beginners than a TC for example . .

But do they really do their job better? I definitely doubt

best, Klaus

[mediavets]

by mediavets » Mon May 13, 2013 9:51 pm

Panogear is not a "dumb" mechanical device.

It is compared to a Seitz VRDrive.

The real 'smarts', I think, lie in the various controllers - panoshoot, T&C touch controller, or papywizard.

A head with a poor User interface will lock the capabilities of any head and will force the user to think on how to handle it the head instead focus on the real job. Is more difficult create a new full graphics game if you are using a green text screen computer with a DOS.

True, but the UI is not in the mount it's in the controller.

Have you done any quantitative usability studies with any of the controllers?

Last edited by mediavets on Mon May 13, 2013 9:53 pm, edited 1 time in total.

[javqui]

by javqui » Mon May 13, 2013 9:58 pm

The Myths:
1. Panogear is slow.
2. Panogear is not accurate enough for giant Panos.
3. Panogear has a low weight equipment capacity.
4. Panogear is not easy to operate.

1. = no myth - it IS slow . . i used it for two years and can state this "myth". Using a 105mm lens for example threatens your nerves. You will realize that immediately when you use a "modern" head.
2. = no myth also - i used it for two years and can state this "myth" when it come to long lenses. But you can use 50% overlap ofd course . .
3. = i guess nobody will put a very expensive - and usually heavy- and big camera on it.
4. = using the Nokia and BT i wouldn´t get it run these days (tried it some weeks ago - but forgot the procedere of conecting it via BT.)

Honestly: the Merlin is a great device. But nobody should expect too much from it´s mechanics and it´s electrics - it´s cost comes for a price . . . :cool:

best, Klaus

Hi Klaus,
Thank you for the feedback.
You are confirming that all statements are myths and really active in the popular belief with your post.
1- panogear is slow, it's a myth due current drivers like Papywizard didn't use the capacity of Panogear that runs twice the speed at least (some applications up to 4 times faster). Please check how Panoshoot handle Panogear and you will notice that for years the Panogear was handled with the wrong commands.
2- Panogear is not accurate/precise. its a myth due previous software drivers use a highly simplified model of how calculate the angle and how to move Panogear. These mistakes result in a low precision measurement and movement resulting in very poor performance.
3- Nobody will put a very expensive equipment mainly for the lack of information about how need to be done, previous drivers use the improper heavy equipment handling (speed, acceleration, breaking) and the lack of information about why the slip protection mechanism is present.
4- poor user interface and portability,its a myth due Papywizard and other experimental drivers can't run on our modern devices properly, but the truth is the User interface runs in all modern portable devices with HTML5 support (almost all devices)

I wisely recommend read the paper in detail to demystify your point

[klausesser]

by klausesser » Mon May 13, 2013 10:03 pm

Some photographers didn't found a substantial difference in time and precision when compared the robotic head with a manual calibrated head. At the end, probably the manual head could be faster for an experienced photographer with large lens, large overlaps and tons of redundancy pixels when compared with low performance robotic head- user interface. This is a real myth and the truth is just the opposite.

FACT is: shooting indoor-panoramas usually people take fisheyes. Using fisheyes a manual head is at least not slower than a Merlin. But it´s more appropriate to use a manual head - or a Vr2, Rodeon or Panoneed - than a Merlin because of the Merlin´s HUGE base.
Panoneed takes about 40sec. to shoot a full sphere with 128MPx using a 5D2/15mm fisheye. I can do that also - maybe faster - using my modified Manfrotto SPH.

So: "myth"?

No somewhat experienced photographer in the world uses more than 20-25% overlap - even on a manual head - so "large overlaps and tons of redundancy pixels" definitely is a myth regarding manual heads.

best, Klaus

[klausesser]

by klausesser » Mon May 13, 2013 10:15 pm

The Myths:
1. Panogear is slow.
2. Panogear is not accurate enough for giant Panos.
3. Panogear has a low weight equipment capacity.
4. Panogear is not easy to operate.

1. = no myth - it IS slow . . i used it for two years and can state this "myth". Using a 105mm lens for example threatens your nerves. You will realize that immediately when you use a "modern" head.
2. = no myth also - i used it for two years and can state this "myth" when it come to long lenses. But you can use 50% overlap ofd course . .
3. = i guess nobody will put a very expensive - and usually heavy- and big camera on it.
4. = using the Nokia and BT i wouldn´t get it run these days (tried it some weeks ago - but forgot the procedere of conecting it via BT.)

Honestly: the Merlin is a great device. But nobody should expect too much from it´s mechanics and it´s electrics - it´s cost comes for a price . . . :cool:

best, Klaus

Hi Klaus,
Thank you for the feedback.
You are confirming that all statements are myths and really active in the popular belief with your post.
1- panogear is slow, it's a myth due current drivers like Papywizard didn't use the capacity of Panogear that runs twice the speed at least (some applications up to 4 times faster). Please check how Panoshoot handle Panogear and you will notice that for years the Panogear was handled with the wrong commands.
2- Panogear is not accurate/precise. its a myth due previous software drivers use a highly simplified model of how calculate the angle and how to move Panogear. These mistakes result in a low precision measurement and movement resulting in very poor performance.
3- Nobody will put a very expensive equipment mainly for the lack of information about how need to be done, previous drivers use the improper heavy equipment handling (speed, acceleration, breaking) and the lack of information about why the slip protection mechanism is present.
4- poor user interface and portability,its a myth due Papywizard and other experimental drivers can't run on our modern devices properly, but the truth is the User interface runs in all modern portable devices with HTML5 support (almost all devices)

I wisely recommend read the paper in detail to demystify your point

Hi Javier!

1) depends on how you define "slow". When i started to use the TC on Merlin and also using the accus Hosef provided - the Merlin was signifficantly faster. But it wasn´t "fast". "Fast" is what the Panoneed, VR2 or Rodeon are.
2) It´s obvious that the rather toy-like motors and gears in the Merlin CAN NOT provide the accuracy which Panoneed, VR2 or Rodeon can provide. That´s not questionable.
3) Be confident that someone who uses "very expensive equipment" usually has some experiences - and wouldn´t use a Merlin anyway for doing his work, sorry: no offense. I definitely wouldn´t.
4)

I wisely recommend gathering practical experience in real world doing professional, commercial work - indoors and outdoors, fisheye and 85mm spheres and 200/300mm mosaics with a Merlin . . :cool:

I did.

best, Klaus

[javqui]

by javqui » Mon May 13, 2013 10:18 pm

1. The speed statistics you publish are interesting - you say they compare Panoshoot with similar settings for Papywizard but we don't get to see what settings you used in Papywizard nor what host platform you used to run Papywizard, nor what version of Papywizard you used, nor what type of connection you used between the Panogear/merlin mount and the Papywizard host.

Probably you save a copy of the document and you will be able to re-open and read it again.
Could be interesting publish the real measurement of speed, resolution, accuracy and precision of your T&C head at the same conditions.

And maybe you should read my post again. I am aware you have problems some with English but I think what I wrote was plain enough.


I read your PDF and nowhere do I see the settings you used in papywizard when producing the comparative timings, nor which version of Papywizard you used, nor which OS, nor the type of connection .... perhaps I failed to spot those details?

How many pages do you read?
Press CTRL-END to go to the end of the document and start going back. You will find several images about the settings, including the answers to all your questions about versions and test conditions.
I will really appreciate handle the topic as a professional and respectfully to current users and all developers, before your destructive personal intention start doing the incorrect things and move into the wrong direction.

[mediavets]

by mediavets » Mon May 13, 2013 10:38 pm

1- panogear is slow, it's a myth due current drivers like Papywizard didn't use the capacity of Panogear that runs twice the speed at least (some applications up to 4 times faster). Please check how Panoshoot handle Panogear and you will notice that for years the Panogear was handled with the wrong commands.

Do I understand that you somehow gained access to information not available to the developers of other controllers?

2- Panogear is not accurate/precise. its a myth due previous software drivers use a highly simplified model of how calculate the angle and how to move Panogear. These mistakes result in a low precision measurement and movement resulting in very poor performance.

I have no idea what you are talking about here.

3- Nobody will put a very expensive equipment mainly for the lack of information about how need to be done, previous drivers use the improper heavy equipment handling (speed, acceleration, breaking) and the lack of information about why the slip protection mechanism is present.

Do you consider it wise to advocate loading the Merlin mount way beyond the max. load specified by the manufacturer? Might you be laying yourself open to litigation from people who follow you advise and have problems? Americans are a very litigious people.

4- poor user interface and portability,its a myth due Papywizard and other experimental drivers can't run on our modern devices properly, but the truth is the User interface runs in all modern portable devices with HTML5 support (almost all devices)

It is an interesting approach; of course HTML5 didn't exist when Papywizard was being developed. Nor did the various 'modern devices' you target today.

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

I am not saying Papywizard is better than Panoshoot - although it may be in some applications - but what really irritates me is the sweeping statements you are prone to making frequently unsupported by any evidence.

Your hyperbole arouses my suspicions. Perhaps it is just a clash of European and American sensibilities?

Last edited by mediavets on Mon May 13, 2013 10:54 pm, edited 1 time in total.

[mediavets]

by mediavets » Mon May 13, 2013 10:41 pm

I will really appreciate handle the topic as a professional and respectfully to current users and all developers, before your destructive personal intention start doing the incorrect things and move into the wrong direction.

I have no destructive personal intention I am just trying to get to the facts behind the hype.

I think it was you who implied that the developers of other controllers were stupid.

Last edited by mediavets on Mon May 13, 2013 10:43 pm, edited 1 time in total.

[klausesser]

by klausesser » Mon May 13, 2013 10:59 pm

Regarding to do a better job, I suggest measure the real speed, resolution, accuracy and precision of T&C with lab equipment.

We did.

Also I suggest compare side by side how easy is operate Panoshoot in whatever device, autonomously and with a smartphone that you carry in your pocket with a powerful graphics and touch interface.
Additionally I suggest compare the amount of parameters and requirements to run the T&C vs Panoshoot easy human fuzzy parameters.

We did. not to Panoshoot - but to VR2 and Rodeon.

You see: i definitely welcome a solution like yours in combination with the Merlin. I´m sure it will run very well - once the first phase is done.
The Merlin and your device surely is a fine low-cost solution for hobbyists - just as the Merlin with N8oo and TC is.

But i´m experienced enough in using Merlin/N800 and Merlin/TC to ask some questions regarding your xml-handling and so.
Here we still don´t have a clear statement!

Shooting panoramas you NEED to have a xml-file coming with EACH pano individually. You need to accompany EACH pano to it´s individual xml (aside from spheres).

Now: shooting 20-30 panos a day: will you get a individual xml file stored in your device? Can it easily be attached to the according shots when you come home and sort your work for being processed?

Besides all other things - mechanical and electrical shortcomings on a cheap device (as great as it is) - having a xml seperately attached to EACH pano i realized is essential . . . besides shooting spheres.

More: depending on the electrical and mechanical precision of the head you can do a preset-xml for each lens you use for spheres.
That´s why the mechanical precision is so important.: i let the head run "dry" recording a sphere with each of my preferred lenses.
Later i can use this xml for stitching the spheres. Thaanks to thje high precision of my head it works perfectly this way. But evertheless the TC writes xml for EACH pano seperately - whether i use it or not.

That´s what i think is really important: the strategy of handling the xml.

best, Klaus

Last edited by klausesser on Mon May 13, 2013 11:03 pm, edited 1 time in total.

[Markus W.]

by Markus W. » Mon May 13, 2013 11:08 pm

Javier,

is it possible to optimize the drivers for Allview too?

Regards

Markus

[javqui]

by javqui » Mon May 13, 2013 11:31 pm

Hi Javier!

1) depends on how you define "slow". When i started to use the TC on Merlin and also using the accus Hosef provided - the Merlin was signifficantly faster. But it wasn´t "fast". "Fast" is what the Panoneed, VR2 or Rodeon are.
2) It´s obvious that the rather toy-like motors and gears in the Merlin CAN NOT provide the accuracy which Panoneed, VR2 or Rodeon can provide. That´s not questionable.
3) Be confident that someone who uses "very expensive equipment" usually has some experiences - and wouldn´t use a Merlin anyway for doing his work, sorry: no offense. I definitely wouldn´t.
4)

I wisely recommend gathering practical experience in real world doing professional, commercial work - indoors and outdoors, fisheye and 85mm spheres and 200/300mm mosaics with a Merlin . . :cool:

I did.

best, Klaus

I agree with you Klaus. T&C and the other heads that you mention are great pieces of machinery.
The topic is about the Panogear specs:, the speed, the precision, the weight capacity and the promoted user interface.
The current and advertised panogear specifications do not correspond with the actual capabilities of the head and that is my point on the document.
Its about some years of incorrect behavior and advertised specs, and that's why I called "the myths".

I can't talk about a head that I never see, but according with the Panoneed pdf, it handles an accuracy of about 0.036 degrees.
Panogear –panoshoot build #100 handle an accuracy of about 0.025 degrees for non heavy equipment.

The web user interface is a clear advantage on how to handle the head.
Hope will be useful for current Panogear owners.

A similar behavior happen with all-view skywatcher from Celestron and other synta heads, but due the forum is about Kolor head, I just limit the myths to Panogear.

As a developer, will be interesting and challenging create an advanced user interface for panoneed with additional features like USB wifi camera control and wireless real time video feedback with a modern platform that we develop recently for other consumer electronic products. We are open to these options with a list of good ideas and we can provide our expertise to improve panoneed with novelty and high demand features, not present in Panoneed at this time.

Regarding my Pano experience, I'm working from the software and part of the hardware side with a group project to shoot the first ground level two Petapixel image in the world. In order to do that we are solving a lot of challenging issues and we are including some novel concepts to the project. You are welcome to the group in you want.


Regards
Javier

[mediavets]

by mediavets » Mon May 13, 2013 11:41 pm

How many pages do you read?
Press CTRL-END to go to the end of the document and start going back. You will find several images about the settings, including the answers to all your questions about versions and test conditions.

OK - I found the Annex which documents the settings used for the speed tests.

Unfortunately I have to say that I think that the examples you used are irrational.

The Mosaic mode of Papywizard is intended for shooting partial panos - that is panos with a FOV of less (typically much less) than 360 degrees on the H (yaw) axis and less (typically much less) that 180 degrees on the V (pitch) axis.

Papywizard's Mosaic mode computes a regular grid/matrix pattern which is not optimal for shooting Spherical panos - that is pano with an H (yaw) axis FOV of 360 and V (pitch) axis FOV of up to 180 degrees.

When shooting Spherical panos it is desirable to shoot fewer images per row as you approch the zenith and nadir, to avoid excessive overlapping and to reduce the number of shots taken. Papywizard's Preset mode is intended to used used for shooting Spherical panos.

You have set a Time value of 0.5s and bracketing of 3. In Papywizard the Time value has to be set to a value that at least allows for the longest expsoure of a bracketed sequence to be taken

The Obturator value set in panoshoot is 0.25 seconds; but I've frogoten what Obturator value refers to, and how it compares to the parameters used in Papywizard.

You have set a Stablisation delay of 0.5 seconds in Papywizard. You say there's some sort of built-in stabilisation delay in panoshoot but do not specifiy its duration.

Last edited by mediavets on Tue May 14, 2013 1:09 am, edited 1 time in total.

[javqui]

by javqui » Tue May 14, 2013 12:01 am

Javier,

is it possible to optimize the drivers for Allview too?

Regards

Markus

We actually did. We need validate the drivers.
Due the mechanical link and controller are different than panogear heads, (they only share a similar API) we are including more features and advantages.
Actually, we are searching how to get precise control of the huge amount of breaking power that All-view heads have in order to introduce additional features, not previously found on this head model. If somebody reading the forum have information about this topic and want to share here will be really useful.

Skywatcher improvements is a work in progress. I will announce the results as soon as I got data validation.

Regards
Javier

[klausesser]

by klausesser » Tue May 14, 2013 12:13 am

I can't talk about a head that I never see, but according with the Panoneed pdf, it handles an accuracy of about 0.036 degrees.
Panogear –panoshoot build #100 handle an accuracy of about 0.025 degrees for non heavy equipment.

When i have more time i´ll show you some pictures of how the motors and the gears (handmade worm-gear) in the Panoneed look like . . . :D
I think the Marlin´s hardware doesn´t justify any discussion . .

The web user interface is a clear advantage on how to handle the head.
Hope will be useful for current Panogear owners.

See - i´m a professional user. And i need it simple and straight - just doing for what it is designed. I don´t need a web-interface, i don´t need wireless, i don´t need images transmitted - for all this i have dedicatd devices if i need them. I NEED stability and reliability of the interface under ALL conditions as well as stability and reliability of the hardware under ALL conditions. Did you ever shoot in a surrounding where you´re not allowed to use wireless? What would you do then?
Did you ever work in a surrounding of heavy electronic interferences? Your device wouldn´t work there! How would you shoot? You can´t always know this in advance - sometimes you come to a site and are told not to use any wireless . . not even a cell-phone (i experienced that several times!).

What i read here so far can´t´t convince me at all

For example i´m still waiting for hard and reliable facts regarding my xml-questions!?

best, Klaus

[javqui]

by javqui » Tue May 14, 2013 12:36 am

….But i´m experienced enough in using Merlin/N800 and Merlin/TC to ask some questions regarding your xml-handling and so.
Here we still don´t have a clear statement!
Shooting panoramas you NEED to have a xml-file coming with EACH pano individually. You need to accompany EACH pano to it´s individual xml (aside from spheres).

Now: shooting 20-30 panos a day: will you get a individual xml file stored in your device? Can it easily be attached to the according shots when you come home and sort your work for being processed?

Starting build#97 you have two options: use a single file for all your panos or download all files individually.
We believe that future XML pano importers should support multi-panos XML files and read the head to help with the import processing.

Besides all other things - mechanical and electrical shortcomings on a cheap device (as great as it is) - having a xml seperately attached to EACH pano i realized is essential . . . besides shooting spheres.

More: depending on the electrical and mechanical precision of the head you can do a preset-xml for each lens you use for spheres.
That´s why the mechanical precision is so important.: i let the head run "dry" recording a sphere with each of my preferred lenses.
Later i can use this xml for stitching the spheres. Thaanks to thje high precision of my head it works perfectly this way.

I follow you up to this potin. Could you provide a sample case scenario or paraphrase the last sentence in order to understand you better and provide a better answer?.

But evertheless the TC writes xml for EACH pano seperately - whether i use it or not.

[mediavets]

by mediavets » Tue May 14, 2013 1:19 am

Starting build#97 you have two options: use a single file for all your panos or download all files individually.
We believe that future XML pano importers should support multi-panos XML files

Will Kolor create a new Panoshoot Import wizard that can handle a multi-pano XML file? If not how can these files be used?

and read the head to help with the import processing.

Could you please explain what this means.

Last edited by mediavets on Tue May 14, 2013 1:19 am, edited 1 time in total.

[javqui]

by javqui » Tue May 14, 2013 1:24 am

See - i´m a professional user. And i need it simple and straight - just doing for what it is designed. I don´t need a web-interface, i don´t need wireless, i don´t need images transmitted - for all this i have dedicatd devices if i need them. I NEED stability and reliability of the interface under ALL conditions as well as stability and reliability of the hardware under ALL conditions. Did you ever shoot in a surrounding where you´re not allowed to use wireless? What would you do then?
Did you ever work in a surrounding of heavy electronic interferences? Your device wouldn´t work there! How would you shoot? You can´t always know this in advance - sometimes you come to a site and are told not to use any wireless . . not even a cell-phone (i experienced that several times!).

Well, I understand you.
Probably you will need only a few set of features, other professional photographer will use another set of features and other group of video enthusiast will use another set of features.

The fact is that the web user interface had been simplified and designed to be easy to handle. All complexity is behind the scene, showing only high level parameters to setup your specific needs.
If you want a device with just a couple of buttons that execute a very specific task that you need, you can easily create a mini webpage and set as plug-in, done. You create a head with your own interface with just the features that you need, and the best part, it will looks just as you want, simple than that is very difficult to achieve. You have 100% control about what you put in the web page.

To create a web page, you can use word or a more decent Web design program. Just need the simple Panoshoot API (application program interface, just a few commands for simple tasks).
If you don’t want to do that, you can easily find somebody on internet and hire it for few bucks or search in your neighbor. They will create the web page in no time, due web interface programming is the most popular interface today, and everybody know how to do simple things with that.

Regarding the wireless interference and environment with Wi-Fi restriction, you should use the autonomous feature of Panoshoot. You don’t need a host device to run your default programming, just press the joystick button for 5 seconds and your complex Pano setup will start executing without anything more than that.
The Pano execution never runs on the host device (smartphone/tablet/pc). The host device is just a graphical user interface. Panoshoot execute all calculations, shooting and motion controller commands by itself without the help of an external device.

What i read here so far can´t´t convince me at all

If you describe what topic didn’t convince you, I will try my best to explain you.

For example i´m still waiting for hard and reliable facts regarding my xml-questions!?
best, Klaus

I wrote a post related to this topic, if you can post the answer I will reply to it.
Javier

[mediavets]

by mediavets » Tue May 14, 2013 1:47 am

Javqui,

I ran the two speed tests you report in the PDF for a 10mm rectilinear lens, bracketed and with no brackets and got a different result.

Not anywhere near as fast as your faster 'indoors' result for Panoshoot but faster than your reported result for Papywizard.

I used Papywizard 2.1.21, the same version as you used, but running on a Nokia Internet Tablet over a Bluetooth wireless connection (which yoiu might expect to produce a slower result than your test setup).

Your reported results are shown in the screenshot below.

My results - three runs each were as follows.

10mm 360x180 mosaic 66 shots (21 shots x 3 brackets). First run from zero/zero standard Home position, subsequent runs from end point of previous run.

Run 1: 6mins 22 secs.

Run 2: 6 mins. 43 secs.

Run 3: 6 mins 42 secs.


10mm 360x180 mosaic 21 shots . First run from zero/zero standard Home position, subsequent runs from end point of previous run.

Run 1: 4mins 51 secs.

Run 2: 5 mins. 13 secs.

Run 3: 5 mins 14 secs.

Last edited by mediavets on Tue May 14, 2013 7:01 am, edited 1 time in total.