Touch control- custom 360x180?  

English support for Panogear kit
no avatar
andrewcochrane
Member
 
Posts: 11
Joined: Thu Jun 07, 2012 2:33 am

by andrewcochrane » Tue Jun 19, 2012 1:58 am

We use HDR spheres for all kinds of CG lighting needs, not everything needs a nadir but occasionally we do. I'll take a look into renting a 15mm to give it a try and see if it does a better job than the 8mm without adding too much time to acquisition, that's a good suggestion.

The Promote works well most of the time, and when it does act up a simple power cycle seems to fix things, but the built in bracketing on the 5Dm3 is definitely more reliable.

The Panoneed sounds interesting, can't wait for them to release it so we can give it a whirl.

-Andy

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 9:26 am

klausesser wrote:
mediavets wrote:One solution to the custom shooting pattern issue would be for T&C to offer the option of uploading and using Papywizard custom presets with the T&C Touch Controller.

I asked whether that might be possible recently on the forum.

No. Would be possible but we decided not to use it because it wouldn´t make any sense at all. Definitely no presets needed. TC calculates everything in real-time on the base of the informations about lens and sensor you stored at home in the menue.

Choosing the sphere-mode the TC knows it is 360x180° and computes all moves. So: why custom presets? The TC ALWAYS is custom pre-set: lens and sensorsize. Choosing a sphere result in
the adaequate settings automatically.

Believe me: it works great. I´m glad not to have to use generate presets for spheres as with my Nokia and PW.

best, Klaus

We've been here before.

I appreciate (and understand) that your view is that such a feature is unnecessary based on the notion that so long as the sphere is covered with adequate overlaps betwen images then that is sufficient. That's logical, the theory is sound and having the pano head calculate the shooting positions is convenient.

However my experience with a manual pano head is that some shooting patterns seem to stitch better than others in some circumstances/scenes. I don't know why, perhaps something to do with the internal workings of APP/APG.

So if it would be possible to add a feature to the T&C controller firmware - for both Panogear/Merlin and Panoneed - that allowed the use of Papywizard XML format custom presets (as well as, rather than instead of, the having thge head computer the shooting positions) then it would offer a potential commercial advantage by meeting the 'irrational' demands of awkward folk like me. A USP compared to rival robotic panop heads that don't offer such a feature.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
josefgraessle
Member
 
Posts: 20
Joined: Sat Nov 28, 2009 6:10 pm

by josefgraessle » Tue Jun 19, 2012 11:51 am

I hope that I can clarify the discussion. The TC uses a maximum down angle of 75 degree, as the footprint of the Orion/Merlin head has this size. For all lenses and camera combinations the TC calculates down angles, only for Fisheye in portrait mode I put 0 degree in as the calculations showed, that only a very small angle would be missed. And our stitching results with Autopano showed at 0 degree the best results for one row of pictures plus the zenit shoot. It would be easy to make this change to have a down angle for Fisheye too. The 8mm Fisheye has on a 1.6 crop camera approximatelly in portrait mode 140 degree, so the missing down angle would be 5 gegree. If some user will be happy to have this additional angle, I can change the software and make a special revision, that the TC uses a down angle for Fisheye in Portrait mode too. If you calculate the influence of this 5 degree for a tripod of 1 meter hight, it means 87 mm at the floor which you will miss. Is that importand? You can do a test , by moving the head 5 degree down manually and run then the sphere. Make the zenit manually and then stitch. Don't use the xml it will be incorrect.

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 12:25 pm

Josef,

I think the issue is perhaps less of a technical issue and more a conceptual issue.

Papywizard (in Preset mode) allows the user to define any arbitrary shooting sequence, this is regardless of whether that pattern is 'good, 'makes sense', 'bad', may cause the camera/lens to collide with the mount, and so on. It's an Open system that permits rather than restricts regardless of whether that is in the user's best interests.

Likewise in Papywizard's Mosaic mode the user can specifiy just about any possible option of matrix shooting pattern starting from any corner, and yaw first or pitch first, and returning at the end of a row/column or not. Alternatively a pano shoot may be defined in terms of desired pano FOV or number of rows and columns (computed around the user set zero/zero yaw/pitch reference point).

As I understand it the T&C controllers - and as far as I know other robotic head controllers - all take or more restrictive approach; taking a 'I know best' approach to the shooting pattern options available to the user.

This makes for ease of use and convenience and arguably protects users from themsleves, but it is more restrictive and less Open.

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

'All' I was asking was whether it might be viable to add a new feature to the T&C controllers firmware that would allow the use of Papywizard XML format custom presets as well as, rather than instead of, the T&C controllers fully automatic shooting pattern computations.
.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
klausesser
Member
 
Posts: 7858
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany

by klausesser » Tue Jun 19, 2012 12:42 pm

mediavets wrote:
klausesser wrote:
mediavets wrote:One solution to the custom shooting pattern issue would be for T&C to offer the option of uploading and using Papywizard custom presets with the T&C Touch Controller.

I asked whether that might be possible recently on the forum.

No. Would be possible but we decided not to use it because it wouldn´t make any sense at all. Definitely no presets needed. TC calculates everything in real-time on the base of the informations about lens and sensor you stored at home in the menue.

Choosing the sphere-mode the TC knows it is 360x180° and computes all moves. So: why custom presets? The TC ALWAYS is custom pre-set: lens and sensorsize. Choosing a sphere result in
the adaequate settings automatically.

Believe me: it works great. I´m glad not to have to use generate presets for spheres as with my Nokia and PW.

best, Klaus

We've been here before.

I appreciate (and understand) that your view is that such a feature is unnecessary based on the notion that so long as the sphere is covered with adequate overlaps betwen images then that is sufficient. That's logical, the theory is sound and having the pano head calculate the shooting positions is convenient.

Hi Andrew!

Not the head calculates the positions but the controller does. Different from the Merlin - wich is a "dumb" device - the Panoneed communicates bi-directionally with the controller all the time.

Basically always there´s only ONE way to shoot a sphere: shoot a sphere ;) Relating to focal length and sensor size there´s only one optimal position for every image. This the TC calculates on the base of it´s stored informations about lens/sensor and tells it to the head, the head gives a feedback to the controller when it reached the position and the controller releaes the camera.

That´s in no way different as you would calculate it at home and write an xml to feed the head - but stop . . it IS different: it´s more precisely because of the interaction between head and TC. Due to the head constantly tells the TC where he is and what he does the TC´s "sees" the "real thing in real-time" when it calculates the positions . . . instead of blindly following a pre-defined script not "seeing" what happens in real-time.

There really is no need at all for defining presets before - they´re defined in real-time. I talked to Josef some minutes ago - it´s possible to add such a function per software-update. But it complicates things unnecessairily and - again - doesn´t make any real sense. It´s like using Tippex on a display . . . ;):cool:

mediavets wrote:However my experience with a manual pano head is that some shooting patterns seem to stitch better than others in some circumstances/scenes. I don't know why, perhaps something to do with the internal workings of APP/APG.

There´s always only ONE optimal pattern for shooting a sphere - related to lens/sensor which works optimal. That is also with manual heads. The more precisely the values which APG gets the better it can position the images in the stitch. I guess modern manual heads does well it by configuring the clicks - that´s their pattern.

mediavets wrote:So if it would be possible to add a feature to the T&C controller firmware - for both Panogear/Merlin and Panoneed - that allowed the use of Papywizard XML format custom presets (as well as, rather than instead of, the having thge head computer the shooting positions) then it would offer a potential commercial advantage by meeting the 'irrational' demands of awkward folk like me. A USP compared to rival robotic panop heads that don't offer such a feature.

Please understand that you see this item from the view of a Merlin-user. Here NO bi-directional communication takes place between the head and it´s control unit - whatever it is.

The Panoneed head has two processors - one for hor. and one for vert. They communicate with each other and with the controller. Josef had a hard time to do the speed-mode in a way which meets his high demands for precision: it´s not only "speedy" but also very precise - and writes xml for positioning nevertheless. Don´t know whether the other heads write xml when running in speed (continuously spinning) mode . . . ?

To not making things more complicated than they need to be Josef decided not to use PapyWizard-like presets. If somebody feels an "irrational" need for it he can get it on special order.

But again: it´s completely needless. The TC already has it all - and in a far better way.

best, Klaus
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
klausesser
Member
 
Posts: 7858
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany

by klausesser » Tue Jun 19, 2012 1:04 pm

mediavets wrote:Josef,

I think the issue is perhaps less of a technical issue and more a conceptual issue.

Papywizard (in Preset mode) allows the user to define any arbitrary shooting sequence, this is regardless of whether that pattern is 'good, 'makes sense', 'bad', may cause the camera/lens to collide with the mount, and so on. It's an Open system that permits rather than restricts regardless of whether that is in the user's best interests.

Let me drop in here again, Andrew: why at all using something that doesn´t "make sense" or even is "bad" ?? Toying around is not the goal. The goal must be getting best results!!

mediavets wrote:As I understand it the T&C controllers - and as far as I know other robotic head controllers - all take or more restrictive approach; taking a 'I know best' approach to the shooting pattern options available to the user.

No, no, no. Besides the sphere -mode there´s no difference at all in use from PW:
In mosaic-mode: you aim to an upper left point, store it and aim to a point bottom right and store it. Then you start. Is this in any way different from your use of your Nokia/PW? I guess - basing on my own use of it - : no.
In angle-mode: you aim the camera to an objekt. You tell the TC: "i want to photograph a 90°x45° FOV from the lens-axis left and right" This way you can exactly aim to your motive without defining an up-left and down-right point.
The head starts -45° hor. and -22,5° vert. basing on the TC´s calculation for shooting 90x45°. This is very comfortable - you can judge what you shoot before you shoot . . . just like you do with "usual" photography.

mediavets wrote:'All' I was asking was whether it might be viable to add a new feature to the T&C controllers firmware that would allow the use of Papywizard XML format custom presets as well as, rather than instead of, the T&C controllers fully automatic shooting pattern computations.
.

It´s possible - but, sorry, completely useless. So: why doing it at all?

But i´m sure that Josef would implement it specially for you!

:cool:

Klaus
Last edited by klausesser on Tue Jun 19, 2012 1:10 pm, edited 1 time in total.
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 1:14 pm

klausesser wrote:Not the head calculates the positions but the controller does. Different from the Merlin - which is a "dumb" device - the Panoneed communicates bi-directionally with the controller all the time.

I think you'll find there is bi-directional communication between a Panogear/Merlin mount and Papywizard too.

Basically always there´s only ONE way to shoot a sphere: shoot a sphere ;) Relating to focal length and sensor size there´s only one optimal position for every image. This the TC calculates on the base of it´s stored informations about lens/sensor and tells it to the head, the head gives a feedback to the controller when it reached the position and the controller releaes the camera.

This is where we disagree. There is obviously more than one shooting pattern that could be adopted to cover a 360x180 pano FOV even with an 8MM fisheye on a fullframe sensor, and the number of alternative possible shooting patterns increases with focal length.

My simple experiments using a DX Nikon and Nikkor 10.5mm fisheye demonstrate - to my satisfaction - that depending on the nature of the scene (such as small domestic interiors vs. outdoor or larger spaces) one pattern produces a better stitch than another. I don't know why this should be but the effect/difference is consistent and repeatable, perhaps it's related to the internal algorithms of APP/APG.

There really is no need at all for defining presets before - they´re defined in real-time. I talked to Josef some minutes ago - it´s possible to add such a function per software-update. But it complicates things unnecessairily and - again - doesn´t make any real sense. It´s like using Tippex on a display . . . ;):cool:

This presupposes that there is only one optimal shooting pattern for any particular sensor size/focal length combination. That's what I dispute. It may be true in theory, my experiments suggest it's not true in the real world of hardware and software.

I may be mistaken of course - but hey why not permit me to follow my stupid ideas? Am I not to be allowed the possibility of 'shooting myself in the foot'. ;)

mediavets wrote:However my experience with a manual pano head is that some shooting patterns seem to stitch better than others in some circumstances/scenes. I don't know why, perhaps something to do with the internal workings of APP/APG.

There´s always only ONE optimal pattern for shooting a sphere - related to lens/sensor which works optimal. That is also with manual heads. The more precisely the values which APG gets the better it can position the images in the stitch. I guess modern manual heads does well it by configuring the clicks - that´s their pattern.

Please understand that you see this item from the view of a Merlin-user. Here NO bi-directional communication takes place between the head and it´s control unit - whatever it is.

I amd sure the Panoneed robotic head is wonderful and much more sophisticated than the Panogear/Merlin mount, but I believe there is some bi-directional communication between the Merlin/Panogear mount and Papywizard.

To not making things more complicated than they need to be Josef decided not to use PapyWizard-like presets.

That's what I mean by T&C (and other robotic head controller manufacturers) adopting a restrictive 'I know best' attitude vs. the Open system approach taken by Frederic with Papywizard. It's a conceptual issue rather than a technical issue.

Again I'm not suggesting the use of Papywizard XML format custom presets instead of the automatic positioning computation offered currently, I am suggesting that it could be an alternative/additional feature for those who choose to work this way in some instances.

If somebody feels an "irrational" need for it he can get it on special order.

So Andy Cochrane could make a special order for support of Papywizard XML format custom presets? If so I'm sure he'll be thrilled.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
klausesser
Member
 
Posts: 7858
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany

by klausesser » Tue Jun 19, 2012 1:57 pm

mediavets wrote:
klausesser wrote:Not the head calculates the positions but the controller does. Different from the Merlin - which is a "dumb" device - the Panoneed communicates bi-directionally with the controller all the time.

I think you'll find there is bi-directional communication between a Panogear/Merlin mount and Papywizard too.

Basically always there´s only ONE way to shoot a sphere: shoot a sphere ;) Relating to focal length and sensor size there´s only one optimal position for every image. This the TC calculates on the base of it´s stored informations about lens/sensor and tells it to the head, the head gives a feedback to the controller when it reached the position and the controller releaes the camera.

This is where we disagree. There is obviously more than one shooting pattern that could be adopted to cover a 360x180 pano FOV even with an 8MM fisheye on a fullframe sensor, and the number of alternative possible shooting patterns increases with focal length.

My simple experiments using a DX Nikon and Nikkor 10.5mm fisheye demonstrate - to my satisfaction - that depending on the nature of the scene (such as small domestic interiors vs. outdoor or larger spaces) one pattern produces a better stitch than another. I don't know why this should be but the effect/difference is consistent and repeatable, perhaps it's related to the internal algorithms of APP/APG.

Andrew: a sphere is a sphere. Everywhere, always and under all circumstances . . :cool: Having set-up your camera/lens/head to the optimal configuration there´s the very same shooting-parameters in your shower and in your dancing hall.
Algos in APP/APG follow this. They don´t know about where you shoot - they just "see" a geometrical configuration: a sphere. And there´s only one way to handle it: as a sphere. The more precisely you take your shots the less problems APG has to stitch them. Ideally using xml.

mediavets wrote:
There really is no need at all for defining presets before - they´re defined in real-time. I talked to Josef some minutes ago - it´s possible to add such a function per software-update. But it complicates things unnecessairily and - again - doesn´t make any real sense. It´s like using Tippex on a display . . . ;):cool:

This presupposes that there is only one optimal shooting pattern for any particular sensor size/focal length combination. That's what I dispute. It may be true in theory, my experiments suggest it's not true in the real world of hardware and software.

I may be mistaken of course - but hey why not permit me to follow my stupid ideas? Am I not to be allowed the possibility of 'shooting myself in the foot'. ;)

In the real world of hard-/software things depend heavily on the precison of gadgeds: setting up the NPP precisely, moving the head precisely and position the images precisely.
When the controller knows every step the head makes and can calculate the next step basing on that - wouldn´t you agree that this definitely is the best way to gain precision?

mediavets wrote:However my experience with a manual pano head is that some shooting patterns seem to stitch better than others in some circumstances/scenes. I don't know why, perhaps something to do with the internal workings of APP/APG.

There´s always only ONE optimal pattern for shooting a sphere - related to lens/sensor - which works optimal. That is also with manual heads. The more precisely the values which APG gets the better it can position the images in the stitch. I guess modern manual heads does well it by configuring the clicks - that´s their pattern.

mediavets wrote:
Please understand that you see this item from the view of a Merlin-user. Here NO bi-directional communication takes place between the head and it´s control unit - whatever it is.

I amd sure the Panoneed robotic head is wonderful and much more sophisticated than the Panogear/Merlin mount, but I believe there is some bi-directional communication between the Merlin/Panogear mount and Papywizard.

You´re right! I puzzled that. The communication between the Panoneed and the TC is more sophisticated - but there´s also one between Merlin and PW.

mediavets wrote:
To not making things more complicated than they need to be Josef decided not to use PapyWizard-like presets.

That's what I mean by T&C (and other robotic head controller manufacturers) adopting a restrictive 'I know best' attitude vs. the Open system approach taken by Frederic with Papywizard. It's a conceptual issue rather than a technical issue.

Again I'm not suggesting the use of Papywizard XML format custom presets instead of the automatic positioning computation offered currently, I am suggesting that it could be an alternative/additional feature for those who choose to work this way in some instances.

If somebody feels an "irrational" need for it he can get it on special order.

So Andy Cochrane could make a special order for support of Papywizard XML format custom presets? If so I'm sure he'll be thrilled.

I asked Josef to drop in here for that.

best to you, Klaus
Last edited by klausesser on Tue Jun 19, 2012 1:58 pm, edited 1 time in total.
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
josefgraessle
Member
 
Posts: 20
Joined: Sat Nov 28, 2009 6:10 pm

by josefgraessle » Tue Jun 19, 2012 2:48 pm

To work with presets is very easy from the point of software developing for a controller, if something is wrong in the stitch, then it is the user's blame not the controllers. The controller has not to make calculations, it is just positioning the head to the preset coordinates. The controller is not deciding magic thinks, it is just geometric calculation. When you select the focal length and the camera sensor size, the controller can calculate the horizontal and vertical angle. ( to store the camera size and the focallength is like storing a preset, but in different form ). The user selects the overlapping, which is used by the controller to reduce the horizontal and vertical angle by this amount. Then the controller calculates how many pictures will fit in vertically and horizontally. If this calculation has fractions in vertical, one row is added and for the horizontal if there are fractions, 1 column is added. This is to make shure that you really have full coverage of the image area and in all directions the desired overlapping as a minimum. If you play around with overlapping, I am shure you get for some settings the same pattern you would prefere with presets. But you can always be shure to get always the right pattern for your selected camera/lens combination and the whole sphere will be covered when you calculate the pattern regarding your camera/lens combination by the controller. I think the calculating controller is much userfriendlier than presets, as you do not have to define in trial and error which is the best pattern for your camera/lens combination and you do not have to remember which presets are for which camera/lens combination. If you make mosaik or angle mode pictures too, presets make even less sense.

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 3:31 pm

Josef,

I agree that the calculating controller is more user friendly for shooting spheres, than creating custom presets in Papywizard, that's not in dispute.

Yes, Papywizard style custom presets are mostly of use when shooting spheres; that's not news either.

Where I disagree with Klaus is that he states that there a single unique optimal shooting pattern for a sphere - that calculated by the T&C controller - for any particular specific sensor-size/lens/camera orientation combination regardless of the pano scene.

My experience with a DX Nikon in portrait orientation, the Nikkor 10.5mm fisheye and NN5L pano head and APG is that a pattern of two rows of 6-around at approx. -15 and +50 pitch stitches consistently and significantly better when shooting small domestic interiors than the alternative pattern of a single row of 6-around at approx. -15 pitch plus one or two 'zenith' shots at approx. +65 pitch which is typically fine for exteriors. I never use +90 pitch zenith shots with this setup because too often there are no matching features for automatic control point detection between the main row and the zenith if I do.

Both of these patterns provide adequate overlaps between adjacent images but I find one (two rows of 6-around) works consistently and significantly better than the other for typical domestic interiors.

I don't know why this should be. Perhaps because the seams fall in 'better' places in relation to features such as the junction of ceiling and walls, and tops of window and door frames, or something like that? Or perhaps it has something to do with the CP detection, blending and antighost algorithms employed by Kolor's APP/APG? Or a combination of the two?

I don't know whether the T&C calculating controller(s) would offer either of these patterns either with Panogear/Merlin or Panoneed?

I am given to understand that the choice of shooting sequence in Mosaic mode can be relevant depending on the scene, in other words there may be instances where shooting by column (pitch) will be preferable to shooting by row (yaw).
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 4:49 pm

josefgraessle wrote:To work with presets is very easy from the point of software developing for a controller, if something is wrong in the stitch, then it is the user's blame not the controllers. The controller has not to make calculations, it is just positioning the head to the preset coordinates. The controller is not deciding magic thinks, it is just geometric calculation.

Exactly so. So in theory it should not be too difficult to add a feature to the T&C controllers firmware which would enable users to choose Papywizard XML format custom presets, instead of having the controller calulate the shooting pattern.

I would envisage that most of the time users would choose to have the controller calculate the pattern, but sometimes they would prefer to choose their own pattern.

I think the calculating controller is much userfriendlier than presets

Yes, the calculating controller is more user friendly; but it takes a degree of control away from the user.

as you do not have to define in trial and error which is the best pattern for your camera/lens combination

There are many ways to work this out - even a calculator tool for spheres which can provide a 'head start' for making a custom preset - and of course one can share a Papywizard XML format custom preset file with other users. It's not 'rocket science' and if custom presets are important to a user (aka 'control freak') he/she won't baulk at creating one to suit their needs. Again it will perhaps be a minority interest, I am not proposing that such a feature should replace the T&C automatic calculating mode.

and you do not have to remember which presets are for which camera/lens combination.

I feel that it wouldn't be too difficult to assign a name - within the XML format file? - and have the T&C controller display a list from which the user can select.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
klausesser
Member
 
Posts: 7858
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany

by klausesser » Tue Jun 19, 2012 5:37 pm

mediavets wrote:
josefgraessle wrote:To work with presets is very easy from the point of software developing for a controller, if something is wrong in the stitch, then it is the user's blame not the controllers. The controller has not to make calculations, it is just positioning the head to the preset coordinates. The controller is not deciding magic thinks, it is just geometric calculation.

Exactly so. So in theory it should not be too difficult to add a feature to the T&C controllers firmware which would enable users to choose Papywizard XML format custom presets, instead of having the controller calulate the shooting pattern.

I would envisage that most of the time users would choose to have the controller calculate the pattern, but sometimes they would prefer to choose their own pattern.

I think the calculating controller is much userfriendlier than presets

Yes, the calculating controller is more user friendly; but it takes a degree of control away from the user.

as you do not have to define in trial and error which is the best pattern for your camera/lens combination

There are many ways to work this out - even a calculator tool for spheres which can provide a 'head start' for making a custom preset - and of course one can share a Papywizard XML format custom preset file with other users. It's not 'rocket science' and if custom presets are important to a user (aka 'control freak') he/she won't baulk at creating one to suit their needs. Again it will perhaps be a minority interest, I am not proposing that such a feature should replace the T&C automatic calculating mode.

and you do not have to remember which presets are for which camera/lens combination.

I feel that it wouldn't be too difficult to assign a name - within the XML format file? - and have the T&C controller display a list from which the user can select.

Andrew - besides playing around: what might be a reasonable reason ;) to use a customer preset when in the end it´s anyway the same as the TC calculates - because there always is only one optimal way?

What´s the goal: perfect usability or toying around feeling mucho "experimental"?

You see: it´s easy when you shoot 5+1 for a sphere. But what about shooting 200 pics for a sphere? Would you prefer to edit an xml with 200 positions instead of letting the controller calculate them more precisely than you ever could?

As someone who does several spherical panoramas every week with 48 and 200 pics actually i swear: it would be definitely not what i would like . . ;):D:cool:

Having a set of 5 lenses from which you choose several ones on site: would you like to feed the presets with every change? Don´t you think it 1) costs valuable time and 2) errors will most likely happen in stressy situations?

Choosing/changing a lens now takes me exactly two touches on the screen. How would i be loading a new extra preset or choosing from pre-defined presets?

What about using a brand-new lens? Now i just have to tell the TC that it exists. That´s all. Takes about 1 minute. How long would i take to generate a new preset first? Only to get an inferior precision than i get from the TC´s calculatings? Look: how precise your generated custom preset really is you can only see afterwards. Then it´s too late. The TC calculates perfectly all the time! Either it works - then it works perfectly - or it doesn´t work (from which reason ever). Fact is: you know what you get on the spot.

Really Andrew: sorry, but i mean customizing presets is completely absurd when you have a device which already does it all perfectly in real-time.

Andy Cochrane i mean either made a mistake in handling his setup or he overstimated the capabilities of the Merlin. No customized presets would have helped him out here!

best, Klaus
Last edited by klausesser on Tue Jun 19, 2012 5:40 pm, edited 1 time in total.
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
andrewcochrane
Member
 
Posts: 11
Joined: Thu Jun 07, 2012 2:33 am

by andrewcochrane » Tue Jun 19, 2012 6:34 pm

josefgraessle wrote:I hope that I can clarify the discussion. The TC uses a maximum down angle of 75 degree, as the footprint of the Orion/Merlin head has this size. For all lenses and camera combinations the TC calculates down angles, only for Fisheye in portrait mode I put 0 degree in as the calculations showed, that only a very small angle would be missed. And our stitching results with Autopano showed at 0 degree the best results for one row of pictures plus the zenit shoot. It would be easy to make this change to have a down angle for Fisheye too. The 8mm Fisheye has on a 1.6 crop camera approximatelly in portrait mode 140 degree, so the missing down angle would be 5 gegree. If some user will be happy to have this additional angle, I can change the software and make a special revision, that the TC uses a down angle for Fisheye in Portrait mode too. If you calculate the influence of this 5 degree for a tripod of 1 meter hight, it means 87 mm at the floor which you will miss. Is that importand? You can do a test , by moving the head 5 degree down manually and run then the sphere. Make the zenit manually and then stitch. Don't use the xml it will be incorrect.

Josef- YES PLEASE!!!!!

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 6:42 pm

Klaus,

Let's agree to disagree?

For me it hinges on your asertion that there is only one otpimal pattern to shoot aspehre with a particulat combination of sensor size/lens/camera orienattion. I don't agree.

As for useability - I've never proposed replacing the existing T&C controllers automatic calculating modes; I would just wish to add the option of using Papywizard XML format custom presets for those members of the awkward squad who would like to be able to use a shooting pattern of their own devising for whatever reason. If as Josef suggests this would be easy to implement why not just do it?

You might find it a 'pain' to create custom presets, and no-one would wish to force you to do so; but those really who want to use one would of course be willing to do it.

As for selecting custom presets during a shoot - I don't feel that woudl be complex. I envisage all my required persts would be pre-installed on the T&C controller and I'd just select the one I wanted from a list.

The precision of custom preset shooting pattern would be no more or less precise in terms of positioning than an automatically calculated shooting pattern. The custom pattern might be '####' but that's not the same as precision of positioning. Is it the moral duty of a robotic pano head manufacturer to prevent users from behaving iin ways you consider foolish?

Adding a new lens to a system would not be an issue. In the first instance the user could use the automatically calculated pattern. Later if desired he/she could develop a custom preset.

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

Let's revisit the Andy Cochrane scenario, this time from a marketing perspective. Rightly or wrongly he wanted to be able to shoot a certain pattern using a robotic pano head with a T&C controller. He can't do that with the T&C controller so he's considering going (back) to using a less convenient manual pano head.

If I was in the market for another better robotic pano head I too would like to be able to choose one of two different particular patterns which work for me to shoot spheres with one my camera/lens setups.

Now there may be many more people considering a robotic pano head who have previously developed workflows based on a particular shooting pattern that works for them with a manual pano head.

If they discover that the Panogear/Merlin+T&C controller and/or the Panoneed+T&C controller cannot reproduce their familar shooting pattern(s) they may well look elsewhere. That's a sale lost when if the option existed of using Papywizard XML format custom presets on T&C controllers you would have been able to get a sale.

It may well be when they came to use their new robotic head + T&C controller they'd find they preferred using the automaticaly calculated mode but they would never get to find out because they'd have rejected the head during pre-purchase research because it couldn't reproduce a shooting pattern they were familiar with.

If, as it seems, it is relatively simple to implement a feature to enable the use of Papywizard XML format custom presets which would overcome such objections from potential purchasers then from a marketing perspective it would seem sensible to do it.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
klausesser
Member
 
Posts: 7858
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany

by klausesser » Tue Jun 19, 2012 8:26 pm

mediavets wrote:Klaus,

Let's agree to disagree?

Of course! Anytime! :cool:

mediavets wrote:For me it hinges on your asertion that there is only one otpimal pattern to shoot aspehre with a particulat combination of sensor size/lens/camera orienattion. I don't agree.

I see. But from the geometrical sight it´s reality! There is ONE NPP. So there is ONE setting for it. So there is ONE optimal configuration for camera/lens on the head. So there is ONE decision to make related the the overlap.
Choosing, let´s say, 25% then there is ONE ideal pattern to match the sphere´s geometry. The closer the shooting pattern is to this mathematical/geometrical pattern the less effort the stitcher has.

mediavets wrote:As for useability - I've never proposed replacing the existing T&C controllers automatic calculating modes; I would just wish to add the option of using Papywizard XML format custom presets for those members of the awkward squad who would like to be able to use a shooting pattern of their own devising for whatever reason. If as Josef suggests this would be easy to implement why not just do it?

The TC is a very small device. Though it has lots of fuctions. But it has limited memory. The memory is used for 50 camera/lens configurations, time-stamp, xml files for being exportet and some. I don´t know how much is left for in fact needless functions - Josef must decide that.
In my eyes it´s more important to store a sufficiet amount of xml from the shootings, timing, cameras/lenses and so on and - most important: valuable and variable functionality like nearly endless bracketing, wait-times, sensors for vibrating, electronic bubble-level, switchable 1 and 4 Newton-meter and some cute things. And not to forget: variable speed-mode with xml writing.

mediavets wrote:You might find it a 'pain' to create custom presets, and no-one would wish to force you to do so; but those really who want to use one would of course be willing to do it.

I´d name it "priorities".

mediavets wrote:As for selecting custom presets during a shoot - I don't feel that woudl be complex. I envisage all my required persts would be pre-installed on the T&C controller and I'd just select the one I wanted from a list.

The precision of custom preset shooting pattern would be no more or less precise in terms of positioning than an automatically calculated shooting pattern. The custom pattern might be '####' but that's not the same as precision of positioning. Is it the moral duty of a robotic pano head manufacturer to prevent users from behaving iin ways you consider foolish?

Adding a new lens to a system would not be an issue. In the first instance the user could use the automatically calculated pattern. Later if desired he/she could develop a custom preset.

When did you make a preset for 50-200 image-sphere the last time?

mediavets wrote:Let's revisit the Andy Cochrane scenario, this time from a marketing perspective. Rightly or wrongly he wanted to be able to shoot a certain pattern using a robotic pano head with a T&C controller. He can't do that with the T&C controller so he's considering going (back) to using a less convenient manual pano head.

Honestly: he COULD have done it. I myself did it several times: he just would have to tilt the camera on it´s screw. You see: using a fisheye and especially an 8mm one means you don´t need an xml file for positioning at all. The angle is wide enough always to see anything in the picture. Agree? I think so.
My experience is that APG did a perfect stitch with this tilt. BUT: using a fullframe-camera with 8mm lens tilted on a Merlin means just enlarging the Merlins base even more!! It doesn´t do ANY good!

The Merlin definitely isn´t the real thing when you use an 8mm on a fullframe . . . customized pattern or not: you always have that very huge base limiting your down-angle when you use such a short lens.
Tilting the camera only shows more of the base instead of more of the ground.

Every experienced user knows that - and uses other combinations.

mediavets wrote:If I was in the market for another better robotic pano head I too would like to be able to choose one of two different particular patterns which work for me to shoot spheres with one my camera/lens setups.

Now there may be many more people considering a robotic pano head who have previously developed workflows based on a particular shooting pattern that works for them with a manual pano head.

If they discover that the Panogear/Merlin+T&C controller and/or the Panoneed+T&C controller cannot reproduce their familar shooting pattern(s) they may well look elsewhere.

If they think this way would mean they don´t really know how things really work . . . they have the opportunity to learn. Holding on tight to procedures which became overcome isn´t very wise!
Josef decided to add the speed-mode - ok. I told my opinion several times regarding it . . . ;):cool: Typical for Josef: he designed it very, very elaborated with impressing features - without
lifting the price by selling it only as an option.

mediavets wrote:That's a sale lost when if the option existed of using Papywizard XML format custom presets on T&C controllers you would have been able to get a sale.

I guess people buying a TC controller want to shoot panos. In a way they couldn´t do before so easily and effortlessly. I don´t think they want to hazzle around customizing pre-sets when it´s done already by the
TC in a perfect way. They just have to combine the right devices - using a Merlin with an 8mm fisheye on a fullframe definitely doesn´t represent an appropriate combination because of the Merlins huge base.
And honestly: another pattern wouldn´t change that. Andy could find out by tilting the camera on the screw - he will see that nothing gets better besides the base gets even bigger.

So: my view of things is from the angle of an intense all-day user who is used to do rather complicated things with pano-devices. So i think i have a clear view on what is possible to do, what is clever to do . . and what
is not so clever to do - because i did it already and know the results . . . . . :cool:

mediavets wrote:It may well be when they came to use their new robotic head + T&C controller they'd find they preferred using the automaticaly calculated mode but they would never get to find out because they'd have rejected the head during pre-purchase research because it couldn't reproduce a shooting pattern they were familiar with.

If, as it seems, it is relatively simple to implement a feature to enable the use of Papywizard XML format custom presets which would overcome such objections from potential purchasers then from a marketing perspective it would seem sensible to do it.

Yes - maybe. But i don´t think so - usually people are clever enough to find out what they REALLY need. And being able to get that for an appropriate price will make them decide clever also.

I discussed with Joef to implement different kinds of starting a shoot: initial spinning left or right, starting with the ground or in the sky and so on. Those items really are important - i realized it when shooting on a construction site:
there were moving cranes. They used to stop for some minutes - but i never knew WHEN. So i needed to start the pano up in the sky - where the canes move instead of starting with the ground as usual.

Georg mentioned being able to choose the initial direction of panning - start with left-pan or right-pan - due to people aproaching or cloud moving.

All this quick changes of the head´s behavior for matching an actual situation woudn´t be possible to change when you use a pre-defined, customized preset!! You´re not able to decide in seconds what´s the best way.

This are only a few points that indicates the rather theory-oriented than practical perspective of your arguments, Andrew. ;):cool:

best to you, Klaus

P.S.: i guess i sometimes mixed Merlin- and Panoneed versions of the TC . . .
Last edited by klausesser on Tue Jun 19, 2012 8:32 pm, edited 1 time in total.
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 10:11 pm

klausesser wrote:
mediavets wrote:For me it hinges on your asertion that there is only one otpimal pattern to shoot aspehre with a particulat combination of sensor size/lens/camera orienattion. I don't agree.

I see. But from the geometrical sight it´s reality! There is ONE NPP. So there is ONE setting for it. So there is ONE optimal configuration for camera/lens on the head. So there is ONE decision to make related the the overlap.
Choosing, let´s say, 25% then there is ONE ideal pattern to match the sphere´s geometry. The closer the shooting pattern is to this mathematical/geometrical pattern the less effort the stitcher has.

A fisheye lens does not have a single NPP. However as I understand it for most practical purposes we can configure our setups as if it does.

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

Just for 'fun' can you send me the XML data files generated by the Panogear/Merlin+T&C controller and by the Panoneed+T&C controller - perfoming 'simulated' shoots for my Nikkor D40 DX+ Nikkor 10.5mm fisheye and Nikon D40 DX + Sigma 8mm f3.5 setups.

Then I can see what shooting pattern is automatically calculated in each case. And I can convert these data files to custom presets and try them out here with Merlin and Papywizard.

I'd also be interested to see what the T&C controllers - in both Panoneed and Panogear/Merlin configurations - propose for D40+35mm and D40+50mm rectilinear lenses in terms of shooting patterns for spheres. I have Papywizard custom presets for these camera/lens configurations with camera in portrait orientation and it would be interesting to compare. Again the XML data files are all I'd need.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
mediavets
Moderator
 
Posts: 14163
Joined: Wed Nov 14, 2007 2:12 pm
Location: Isleham, Cambridgeshire, UK.

by mediavets » Tue Jun 19, 2012 10:27 pm

klausesser wrote:The TC is a very small device. Though it has lots of fuctions. But it has limited memory. The memory is used for 50 camera/lens configurations, time-stamp, xml files for being exportet and some. I don´t know how much is left for in fact needless functions - Josef must decide that.
In my eyes it´s more important to store a sufficient amount of xml from the shootings, timing, cameras/lenses and so on and - most important: valuable and variable functionality like nearly endless bracketing, wait-times, sensors for vibrating, electronic bubble-level, switchable 1 and 4 Newton-meter and some cute things. And not to forget: variable speed-mode with xml writing.

So no plans to offer support for removable memory - USB memory stick, or SD/CF card?

I think the Seitz VR2 has support for USB memory stick?

........

I discussed with Joef to implement different kinds of starting a shoot: initial spinning left or right, starting with the ground or in the sky and so on. Those items really are important - i realized it when shooting on a construction site:
there were moving cranes. They used to stop for some minutes - but i never knew WHEN. So i needed to start the pano up in the sky - where the canes move instead of starting with the ground as usual.

Georg mentioned being able to choose the initial direction of panning - start with left-pan or right-pan - due to people aproaching or cloud moving.

All this quick changes of the head´s behavior for matching an actual situation woudn´t be possible to change when you use a pre-defined, customized preset!! You´re not able to decide in seconds what´s the best way.

This all sounds good - but it's not clear to me whether these features are currently implemented or just on a wish list.
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.

no avatar
klausesser
Member
 
Posts: 7858
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany

by klausesser » Wed Jun 20, 2012 1:55 am

mediavets wrote:So no plans to offer support for removable memory - USB memory stick, or SD/CF card?

I think the Seitz VR2 has support for USB memory stick?

No need for that. Neither with Merlin nor with Panoneed. The TC can be connectet to a PC via USB for configuration, xml export and firmware-update. It stores more xml files than you´re able to shoot in a week :cool:

You´ll find it surprisingly simple - but it´s very mighty nevertheless. I can state that on the base of practical use - for example:
http://www.360impressions.de/ArchivSchadowplatz/
http://www.schloss-drachenburg.de/content/virtueller_rundgang/virtueller_rundgang.html
http://gigapan.com/gigapans/97639
http://www.360impressions.de/GrecoPan/
http://www.360impressions.de/Wandelhalle

Done with Panoneed and the TC controller. Would you need more?
........

I discussed with Joef to implement different kinds of starting a shoot: initial spinning left or right, starting with the ground or in the sky and so on. Those items really are important - i realized it when shooting on a construction site:
there were moving cranes. They used to stop for some minutes - but i never knew WHEN. So i needed to start the pano up in the sky - where the canes move instead of starting with the ground as usual.

Georg mentioned being able to choose the initial direction of panning - start with left-pan or right-pan - due to people aproaching or cloud moving.

All this quick changes of the head´s behavior for matching an actual situation woudn´t be possible to change when you use a pre-defined, customized preset!! You´re not able to decide in seconds what´s the best way.

mediavets wrote:This all sounds good - but it's not clear to me whether these features are currently implemented or just on a wish list.

It´s getting tested and optimized actually.

best, Klaus
Last edited by klausesser on Wed Jun 20, 2012 1:58 am, edited 1 time in total.
Simplicity is the keynote of all true elegance. Coco Chanel

Previous

Return to Panogear

Who is online

Users browsing this forum: No registered users and 2 guests