 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | You are not logged in.
Hello Everyone,
I wonder if anyone can explain to me what is going "wrong" when I do a gigapan import? The first screenshot shows what happens when I load the same images in two ways. First, in Group 8, I have imported my images as a gigapan. Second, in Group 9, I loaded the images in the normal way and set the stitcher running. Of course the results will be different because AP can't stitch the sky.
What concerns me is the quality of the stitching in the images that do stitch. As you can see from the screenshot the RMS is vastly superior when gigapan import is not used. I believe there is a kludge in the import in the sense that AP "needs" to have all images linked so if it can't find sutiable control points then it makes some up. Links between these invented control points often have a very bad RMS and that gives the overall image a bad RMS when in fact the stitch is fine.
But things are different in this case. As you can see from the screenshot of the CPE for the gigapan import, the imaginary control points have green links and it is the stitched images that have the bad links. On the other hand, it's clear from the last screenshot that these images stitch together with a low RMS when not imported as a gigapan.
Two ideas occur. First, there is an error in the calculation (and/or display) of RMS values in imported gigapans. Second, importing gigapans creates worse stitches.
Does anyone else have experience of this type of problem? Or any theories about what is going on? Workarounds? In the bast I have resorted to stitching without importing then using a script to modify the .pano file to put the orphaned images back in at the right place. I do know from experience that the gigapan importer often gives very poor results because it does not seem to use the information that the images form a regular grid - well, it does, but more as a kind of hint rather than a strict requirement - so my preferred theory is number 2.
Aeris
Last edited by Aeriscera (2010-08-14 18:29:29)
Offline
Hi,
The experts might be able to give more details but to me it is logical the gigipan import works better in this case.
Certainly because of all the sky in the panorama.
Using gigapan import you tell APP that the photos are shot in rows+columns structure which makes it much easier for APP.
Did you use the "Assume row/column shooting" option on group 9? If not, try it and see if it helps
Cheers,
Hans
Offline
Thanks for the reply but I'm not sure you understand my point. The "good" stitch is Group 9. You seem to imply that it is the "bad" one because there is no sky, but that's not the point.
A
Offline
With your group 8, you have far too many links. Get rid of the long ones.
1. eliminate the links where the colored box with the RMS value falls over the circle with the picture number in it.
2. eliminate any links that are not at 0 degrees, 45 degrees, 90 degrees, or 135 degrees.
then reoptimize.
Offline
hankkarl wrote:
With your group 8, you have far too many links. Get rid of the long ones.
1. eliminate the links where the colored box with the RMS value falls over the circle with the picture number in it.
2. eliminate any links that are not at 0 degrees, 45 degrees, 90 degrees, or 135 degrees.
then reoptimize.
I feel that you are perhaps missing the point.
If you are shooting hi-res mosaics comprising many tens or hundreds of images you do not want to be editing links and CPs at all.
The desired goal/capability of the Import wizards/filters got the various robotic panoheads (Gigapan, Merlin/Panogear, Rodeon and so on) is to position the images so well automatically that one gets a perfect (or 'good enough') stitch with no additional user intervention. Any lesser result is really not much use.
This is not an unrealistic expectation because some of the supported robotic heads record the position of the head for each shot and that data can be made available to APP/APG, and (even) in the case of the Gigapan heads one knows that the layour of the images is a regular matrix.
Aeriscera's point is that the Gigapan Import wizard/filter does not seem to be giving sufficient weight to the fact that the images form a regular matrix when creating links.
Last edited by mediavets (2010-08-15 14:19:26)
Offline
Perhaps APP needs something like this: http://www.autopano.net/forum/t2394-rem … r-distance or this http://www.autopano.net/forum/t6594-bad-link-finder
Offline
Aeris,
How good or bad is the end result, after rendering?
Cheers,
Hans
Offline
hankkarl wrote:
Perhaps APP needs something like this: http://www.autopano.net/forum/t2394-rem … r-distance or this http://www.autopano.net/forum/t6594-bad-link-finder
I had a look at those links but I don't think they would help with the gigapan problem. But 'yes' something like it eg an editor mode that doesn't show links between invented control points and/or doesn't include them in the RMS calculation. Having said that, I suspect that each type of APP user would like their own specialised editor :-)
I think the problem is that the gigapan import is not written in the best way. What you see here is a *good* example of APP's gigapan import. Mostly the stitches are badly distorted around the edges (because there are no CPs for it to use and it doesn't use the grid information). Sometimes they are utterly laughable - or it would be if I hadn't paid £200 for the software.
Another problem is that none of the devs are contributing to this thread. Are they all on holdiay?
Aeris.
Offline
HansKeesom wrote:
Aeris,
How good or bad is the end result, after rendering?
Cheers,
Hans
It depends very much on the images in question. For this particular image each layer stitched ok but the three layers (I bracketed) did not align :-(
Other image sets are thrown together so badly that I wouldn't use the word "stitched" at all, so rendering is pointless. And then again, sometimes APP will stitch 1500+ images as a bracketed gigapan import perfectly.
The general problem is - as mentioned above - that the gigapan import just doesn't work very well (tm). If that can't be fixed then the problem CPE does not work well with the current kludge for gigapan imports.
A
Offline
Okay, this is an interesting remark. Good point Aeriscera.
The difference between both mode RMS comes from the way they are working.
- In gigapan mode, we suppose a row/column structure. To optimize such layout, an algorithm has been developed that creates false CP ( one CP links ) between images that don't have any link. This tip is good because when real links with real cps are moving, it will drive all the images through that grid of links.
- Without gigapan mode, you don't have such false link, so only real links have an influence. And it appears in your case, the bottom is doing that.
So why the issue with this case ?
For me, it's a problem when having 360° gigapan. We do a column / row angle sampling. We would need to check that sampling method if we detect that it's a 360°.
If you have a 360° panorama, the angle between column is know directly : 360° / NbRow = angle between column. Our sampling seems to give a slight different result, that's why the sky is green and not the ground in the screenshot using gigapan import.
Offline
BTW : that's issue 170.
Offline
AlexandreJ wrote:
BTW : that's issue 170.
Is there an index of Issues (or a link to the releavant thread) so I can compare what I/you have been saying with the issue as raised?
Thanks for your feedback,
Aeris
Offline
Offline
