 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | You are not logged in.
I have several images where I can't get the CP editor to link them, even though there are many similar points and a lot of detail. I have found a stateful behavior in the CP editor:
set CP detector quality low, Select a region, add control points. No control points found.
set CP detector quality high, select a region (more or less the same as above), add control points. Control points found
Then go on to the next pair:
Keep CP detector quality high (ie don't change it), select a region (more or less the same as above), add control points. no control points found.
set CP detector quality low, Select a region, add control points. No control points found.
set CP detector quality high, select a region (more or less the same as above), add control points. Control points found.
< repeat as desired >
<test>
set CP detector quality low,
go to next pair of images.
don't change cp detector quality. Select a region, add control points. No control points found.
set CP detector quality high, select a region (more or less the same as above), add control points. Control points found
Offline
I cannot reproduce this behavior. When checking the code, the right detection quality is really passed to the control point detector ( I checked that inside this part ). So I'm sure the right quality is used. Now, you have perhaps some case where low quality is just not enough. Low is really low and can miss some large area with low details.
Offline
next time I find this, I'll upload the project.
This was very reproduceable. It may be related to the issue of different selection areas give different CPs, but I tried to make them the same.
So does "low" mean low quality points will be used (is the algorithm "sloppier" and lets more questionable areas through?)
Does "high" mean that the pixels around the CP must have a very small variation between the two images, or does it mean that APP tries harder to find CPs?
I'll check later--right now APP is positioning a 200 image handheld pano, has been working on it for four hours, and will probably go on for at least another four.
Offline
AlexandreJ wrote:
I cannot reproduce this behavior. When checking the code, the right detection quality is really passed to the control point detector ( I checked that inside this part ). So I'm sure the right quality is used. Now, you have perhaps some case where low quality is just not enough. Low is really low and can miss some large area with low details.
There may be some other statefull stuff. APP does not always give the same CPs. Are there any other initial conditions when you call the CP detector other than quality? Perhaps some table of coefficients or something calculated at run time based on other pictures in the pano?
Offline
hankkarl wrote:
So does "low" mean low quality points will be used (is the algorithm "sloppier" and lets more questionable areas through?)
Does "high" mean that the pixels around the CP must have a very small variation between the two images, or does it mean that APP tries harder to find CPs?
Low means, it will have a quick analysis of zones. It's all about density. Low : it will use images scaled down by 4. Std : scaled down by 2, High : no scale, it analyse full size. SIFT is too good, we need to reduce the size to prevent the creation of too much CPs.
For CPs creation, SIFT analyse a large area around the pixel itself, it's not just a pixel, it can be far from it.
Offline
So another word we could use is "fast" instead of "low", and "slow" instead of "high".
I guess that SIFT gives a number: Does APP uses a threshold to say if its a CP or not, or does APP just take the "n" points with the highest SIFT number? If its a threshold, then it may be worthwhile to allow the user to adjust this number also.
Perhaps scaling by 8 or even 16 will help in some cases. And how about an automatic mode--start at the lowest user selected level of detail, if no points found, try the next highest and if no points found, try the highest.
And an auto-refine mode--when using low, after you find the points, go back in and find which of the 16 pixels is the best (and possibly look at the eight surrounding blocks of 16 pixels).
Last edited by hankkarl (2007-10-19 18:29:29)
Offline
hankkarl wrote:
So another word we could use is "fast" instead of "low", and "slow" instead of "high".
Fast - Standard - High 
hankkarl wrote:
I guess that SIFT gives a number: Does APP uses a threshold to say if its a CP or not, or does APP just take the "n" points with the highest SIFT number? If its a threshold, then it may be worthwhile to allow the user to adjust this number also.
Perhaps scaling by 8 or even 16 will help in some cases. And how about an automatic mode--start at the lowest user selected level of detail, if no points found, try the next highest and if no points found, try the highest.
And an auto-refine mode--when using low, after you find the points, go back in and find which of the 16 pixels is the best (and possibly look at the eight surrounding blocks of 16 pixels).
When using Standard, if you are not happy with RMS I suspect the fastest method to improve it could be to launch a new detection using High quality (?)
Offline
GURL wrote:
When using Standard, if you are not happy with RMS I suspect the fastest method to improve it could be to launch a new detection using High quality (?)
I'm thinking of a case where all but one picture link correctly. So it would be just one or two pictures out of the pano that need special treatment.
And we can also have an option for the reverse--if high can't find a fit, try medium then low.
I'm specifically thinking of the last pano I did (360 x 180, 200 images) but some of the discussion by the guys who can't get a virtual tour to work may be a better argument for implementing something like this.
Offline
I move that to the future session.
Offline