[GSoC] robust function for affine transform estimation#6615
[GSoC] robust function for affine transform estimation#6615hrnr wants to merge 101 commits intoopencv:masterfrom
Conversation
Save method should save, instead trying to run inkview
|
I don't have any idea why this fails OpenCL perf test. It does not make any sense to me. Is that some bug in |
|
added |
| between 0.95 and 0.99 is usually good enough. Values too close to 1 can slow down the estimation | ||
| significantly. Values lower than 0.8-0.9 can result in an incorrectly estimated transformation. | ||
|
|
||
| The function estimates an optimal 2D affine transformation with 5 degrees of freedom limited to |
There was a problem hiding this comment.
do you mean 4 dof? 1 rotation + 1 scale + 2 translation?
|
added perf test for both functions. Here are my results:
|
|
Is it normal that perf test fails on a first run? It fails with It does not happen locally. |
|
added regression data in opencv/opencv_extra#296. Hope that it will make build bot happy. |
|
I have experimented with using eigenval decomposition instead of SVD in eba30a8 (+ trick to make the matrix symmetric), but it is not any faster. From my POV I consider this feature complete. If we convice the buildbot to use the new generated regression data I can rebase and this could be the first thing to go in. Since this blocks #6609, I will focus on parallel feature finding subtask for now and continue with affine registration in sttiching pipeline once this will go in. |
|
Basically looks ok to me. the test size of (100000, 5000, 100) is different from what you have in the sanity sheet in opencv/opencv_extra#296. Do you need to regenerate it? |
|
Thanks for noticing, I have regenerated the data. Hope that buildbot will be happy now. I have rebased my commits. |
|
Buildbot is failing to merge opencv_extra with my regression data. Is there anything I can do to convice buildbot to use the generated data? |
|
You should use the same name for branch in opencv_extra: |
|
Thanks, reopened as opencv/opencv_extra#297 with correct branch name. Rebased against newest master to force builtbot run. |
|
All green. For me this is good to go in. |
|
incorporated fix from #6768 EDIT: I pushed a commit into my branch, but this PR is not updating. Hopefully it will update soon. |
estimates affine transformation using robust RANSAC method. * uses RANSAC framework in calib3d * includes accuracy test * uses SVD decomposition for solving 3 point equation
estimates limited affine transformation * includes accuracy test
test Calib3d_EstimateAffineTransform rename to Calib3d_EstimateAffine3D. This is more descriptive and prevents confusion with estimateAffine2D tests.
tests both estimateAffine2D and estimateAffinePartial2D
* incorporates fix from opencv#6768
|
this PR will be reopened because of CI issues |
|
estimateAffinePartial2D and estimateAffine2D seems to be buggy. Fails for int input values. Returned values are cast to int so results makes not sens. |
|
In case estimateAffine* functions get something different than floats, inputs are converted to floats and then algorithm works the same. Returned matrix is always doubles. estimateAffine* uses Levenberg-Marquart as final refinement step. Do you get expected results when you call it with |
|
I tried with |
|
Thanks for report, I will take a look on that. There might be some degenerate points configuration not catched by tests. I see you are now storing |
|
std::vectorcv::Point p1s,p2s and results are: and std::vectorcv::Point2f p1s,p2s; and correct results: |
|
You are right, there is a stupid bug in estimateAffine* affecting conversion of inputs. I will fix that (please give me a few days, I'm quite busy now). Thank you for reporting this, we should have probably more tests to cover also conversions. |
implements
estimateAffine2D. estimates affine transformation using robust RANSAC method.things to consider:
I plan to write perf test to see if make sense to do some tricks and solve with EIGEN val decomp. Checking for coplanar points seems to work well for me. I adapted the check from estimateAffine3D, estimateRigidTransform have some addition checks (checking if points are not too close), but I'm not sure if it is worth to implement those.
I will implement also
estimateAffinePartial2Dthat will estimate transformation using only rotation, translation an scaling (similar toestimateRigidTransform). I'm only not sure about the nameestimateAffinePartial2D, any ideas welcome.cc: @prclibo