Nick Fan wrote:Any one has a comparison of performance between the Merlin and other more precise motorized head ? Is the stitching speed affected in regard to "creation of templates for automated detention and stitching"?

There is 3 parts in this question : 1. Comparison of panorama heads ( more or less precise )2. How a motorized panorama heads is used in autopano3. Templating ( which is a bit separate because templating works also without a motorized panorama head )

1. Panorama head comparison :

There are several kind of course, more or less accurate, that can handle more weight ( means longer focal ).For autopano, we can separate them in two categories :Type 1 - Panorama heads that creates a log file with shooting position ( merlin, clauss, pixorb )Type 2 - Panorama heads that don't create any log file ( gigapan )( I don't know how to classify other panorama head )

Accuracy can change between panorama head, but it's not important in fact.

2. How a motorized panorama heads is used in autopano

Let's first talk about the first type of panorama head with a log file.We parse the log file and extract positions. By using image focal and location, we can calculate overlapping zone and thus we can create a list of pictures pair that should be linked. We do detection on them. Some will have control point, some won't ( becaus full blue sky ).The optimizer did it's job by combining both information : CPs and approximate location given by the head. So even unlinked pictures will have directly a quite good location.In this phase, I've noticed a bit shift with some panorama head which gives for example a value and the calculation gives another value. I do'nt ge the time yet to give a general trend.

The second kind of panorama without log file is handled this way.We only know how the shoot has been done, but we don't have any location. With the structure in the shooting, we can have a potential list of pair of image linked too. That's easy. We do detection on them. The optimizer do a standard optimization without coping with unlinked picture. The remaining unlinked picture are then patched with the knowledge of the structure in the shooting stage ( we don't have the location, we have relative information : this image is on the top of this one which is linked : for example ). It's harder to patch but it works many time.

3. Templating

For the moment, templating in autopano works this way :You have a panorama that you find a great candidate as a standard kind of shooting you are used to do. Right click on save and you'll get a "save as template". This button saves the .pano in a special folder in the autopano installation folder called template. The name of the .pano is the name of the template.Let say you have a typical 6+1 fisheye job ( 6 in a row at -15° and the nadir, always in this order ).In a group, when you already have this setup, you just say in the group setting, use the same template. What does it do :It will use the links in the template to prepare a list of possible candidate in the new panorama. In the 6+1 fisheye case, it will prepare ( 1-2, 2-3, 3-4, 4-5, 5-6, 6-1, 1-7, 2-7, 3-7, 4-7, 5-7, 6-7). With the list, the detection starts and try to find some relation. So with the template you will not be able to find a link between 2-4 for example because it doesn't exist in the template. But even if a link between 1-2 was found in the template doesn't mean it will found one in the current group. We don't transfer CP yet from templates, we prefer to give a higher priority to image analysis.That's the current implementation. In the future, this solution will give us many more possibilities because we rely on the full .pano as a template :- we could transfer CPs,- we could transfer distortion,- we could transfer color correction.That's planned too, but after the final 2.0 release. We prefer to concentrate on the creation of a strong background that has many potential evolution than doing directly everything on a weak base.

AlexandreJ wrote:The second kind of panorama without log file is handled this way.We only know how the shoot has been done, but we don't have any location. With the structure in the shooting, we can have a potential list of pair of image linked too. That's easy. We do detection on them. The optimizer do a standard optimization without coping with unlinked picture. The remaining unlinked picture are then patched with the knowledge of the structure in the shooting stage ( we don't have the location, we have relative information : this image is on the top of this one which is linked : for example ). It's harder to patch but it works many time.

What do you do in the case where the user has paused the shoot and moved the head back in the sequence to reshoot at one or more shooting positions?

Thanks for the detailed explanation. I want to know if the detention is limited to e.g. 20x20 px for more precise head or 200x200 px for less precise head, will there be a great difference in stitching speed?

mediavets wrote:What do you do in the case where the user has paused the shoot and moved the head back in the sequence to reshoot at one or more shooting positions?

For the second case of panorama, the current algorithm should work even in this case ( I think that the gigapan stitching solution doesn't handle such case because of a strong matrix assumption in the shooting ).BTW : If you have a sample set to share, I can check that.

I mean in this case, it does not mention wether the head is motorized or not.

If there is a way that a user could input some basics of the shooting pattern it must be helpful to shorten the detection.

Like:x by y rowssequence column by column or row by row, bottom up or top downmovement zigzaged or not direction from left to right or right to leftspherical or not

There's 2 solutions for that :1. Have first shoot with the pattern you need, stitch it normally, fix it, then save as a template.Next stitching job will be done with that template as input2. I will add later a generic matrix plugin to handle that : you will say how many row/colunm, the order of shooting, etc, and I'll use that to generate a good panorama. It's not coded yet, but will be based on an customizable gigapan import plugins : for the gigapan, everything is fixed, for the generic one, you have the freedom to change any setting.

Nick Fan wrote:I want to know if the detetion is limited to e.g. 20x20 px for more precise head or 200x200 px for less precise head, will there be a great difference in stitching speed?

No at all. The detection is not area based, so the full size of both images are always analysed. There is no differences at all in detection speed. It could change a little the optimization stage, but perhaps you'll get 5% quickier in this stage, but you'll never get 50% quickier.

AlexandreJ wrote:For the second case of panorama, the current algorithm should work even in this case ( I think that the gigapan stitching solution doesn't handle such case because of a strong matrix assumption in the shooting ).BTW : If you have a sample set to share, I can check that.

I think you can just duplicate some entries in the xml file from the project I sent you, and also duplicate the related images as well (in the same order than in the xml file)...

But if Andrew can send you such complete project, it will be better, as the reshot images will be a little bit different...

mediavets wrote:What do you do in the case where the user has paused the shoot and moved the head back in the sequence to reshoot at one or more shooting positions?

For the second case of panorama, the current algorithm should work even in this case ( I think that the gigapan stitching solution doesn't handle such case because of a strong matrix assumption in the shooting ).BTW : If you have a sample set to share, I can check that.

9x4 mosaic matrix - but there are 50 images in the set because I used the Papywizard Rewind/Forward features. So some shooting postions will have more than one image, also the images will not (all) be in normal matrix shooting sequence order. H overlap 33%; V overlap 30%.

Note:I did not intend to include the first three images in the set - they were setting up shots to establish WB and focus taken by hand before starting the Papywizard shoot so the Papywizard data file will not include data for them.

Screenshot shows stitch produced by APP 1.4.2 on WinXP......I think you should have a Merlin/Papywizard system - you'd love it.

Last edited by mediavets on Wed Nov 26, 2008 5:06 pm, edited 1 time in total.

AlexandreJ wrote:( I think that the gigapan stitching solution doesn't handle such case because of a strong matrix assumption in the shooting ).

The gigapan stitcher can be forced to do it by renumbering any pic sequence, just renaming files in the regular shoot sequence.The stitcher arranges the cols and rows by the sequence of their names.

As my robots standard pattern is row by row, L to R, bottom up, I rename the files and shuffle them into the gigapan stitcher and it works fine.I prefer that because most time movements are in the bottom rows, so I can relax when they are shot until alll pics are done. And I often only reshoot the bottom row for exchanging ghost pics.