Image-stitching and virtual tour solutions My account Updates
It is currently Wed Sep 17, 2014 2:37 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Wed Nov 26, 2008 9:46 am 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
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 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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 9:55 am 
Offline
Member
User avatar

Joined: Wed Dec 07, 2005 6:21 pm
Posts: 5826
Location: Grenoble, France
Thanks for the explanations!

_________________
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 10:22 am 
Offline
Member

Joined: Wed Nov 14, 2007 2:12 pm
Posts: 13958
Location: Isleham, Cambridgeshire, UK.
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?

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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 11:02 am 
Offline
Member
User avatar

Joined: Sat Aug 30, 2008 4:46 pm
Posts: 778
Location: Bonn, Germany
AlexandreJ wrote:
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

_________________
Paul

close, but no cigar ... ... ...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 11:02 am 
Offline
Member

Joined: Tue Nov 25, 2008 10:54 am
Posts: 10
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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 1:27 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
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.

Paul wrote:
AlexandreJ wrote:
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.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 1:31 pm 
Offline
Member
User avatar

Joined: Wed Dec 07, 2005 6:21 pm
Posts: 5826
Location: Grenoble, France
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...

_________________
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 2:00 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 3:03 pm 
Offline
Member

Joined: Wed Nov 14, 2007 2:12 pm
Posts: 13958
Location: Isleham, Cambridgeshire, UK.
AlexandreJ wrote:
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.

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.



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


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

Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 3:52 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
mediavets wrote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 5:00 pm 
Offline
Member

Joined: Wed Nov 14, 2007 2:12 pm
Posts: 13958
Location: Isleham, Cambridgeshire, UK.
AlexandreJ wrote:
mediavets wrote:
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.

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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 5:44 pm 
Offline
Member
User avatar

Joined: Wed Dec 07, 2005 6:21 pm
Posts: 5826
Location: Grenoble, France
AlexandreJ wrote:
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...

_________________
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 26, 2008 6:36 pm 
Offline
Member
User avatar

Joined: Sat Aug 30, 2008 4:46 pm
Posts: 778
Location: Bonn, Germany
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.

_________________
Paul

close, but no cigar ... ... ...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group