Panohead comparison of performance with template detection

[AlexandreJ]

Panohead comparison of performance with template detection

by AlexandreJ » Wed Nov 26, 2008 9:46 am

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

[fma38]

by fma38 » Wed Nov 26, 2008 9:55 am

Thanks for the explanations!

[mediavets]

by mediavets » Wed Nov 26, 2008 10:22 am

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?

[Paul]

by Paul » Wed Nov 26, 2008 11:02 am

Type 2 - Panorama heads that don't create any log file ( gigapan )

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 rows
sequence column by column or row by row, bottom up or top down
movement zigzaged or not
direction from left to right or right to left
spherical or not

[Nick Fan]

by Nick Fan » Wed Nov 26, 2008 11:02 am

Hi AlexandreJ,


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?



Nick

[AlexandreJ]

by AlexandreJ » Wed Nov 26, 2008 1:27 pm

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.

Type 2 - Panorama heads that don't create any log file ( gigapan )

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 rows
sequence column by column or row by row, bottom up or top down
movement zigzaged or not
direction from left to right or right to left
spherical 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 input
2. 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.

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.

[fma38]

by fma38 » Wed Nov 26, 2008 1:31 pm

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

[AlexandreJ]

by AlexandreJ » Wed Nov 26, 2008 2:00 pm

No fma38. It's not the same because you have a log and gigapan don't. So stopping such kind of matrix doesn't create a new entry.

[mediavets]

by mediavets » Wed Nov 26, 2008 3:03 pm

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.

Alexandre,
Here you are:
http://www.three60views.org.uk/kolor/kolor-mosaic-merlin.zip (approx. 38MB)

Shot on Merlin with Nikon D40 and 18-55mm kit zoom, set at 35mm (52.5mm 35mm equiv.). Shot at lowest res. (1000x1504 pixels) to reduce file sizes. No bracketing. ISO 400, F8, 1/5 sec.

Papywizard 1.4.0 running on Windows 2000.

Papywizard output data file included in the ZIP archive.

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]

by AlexandreJ » Wed Nov 26, 2008 3:52 pm

I think you should have a Merlin/Papywizard system - you'd love it.

I have one. Never got the time yet to play with it I'm currently playing with our Clauss Rodeon only.

[mediavets]

by mediavets » Wed Nov 26, 2008 5:00 pm

I think you should have a Merlin/Papywizard system - you'd love it.

I have one. Never got the time yet to play with it I'm currently playing with our Clauss Rodeon only.

If you wish to spend more time with the Merlin I'd be happy to take the Rodeon off your hands.

If you want more test image sets shot with the Merlin/Papywizard just let me know.

[fma38]

by fma38 » Wed Nov 26, 2008 5:44 pm

No fma38. It's not the same because you have a log and gigapan don't. So stopping such kind of matrix doesn't create a new entry.

Yes, you're right; I didn't read carefully...

[Paul]

by Paul » Wed Nov 26, 2008 6:36 pm

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