Comments (6)
I quickly verified on the sample dataset that the non-CUDA version of the intensity based refinement generally does seem to work in the current state of the code. The following image shows a typical result from there, where the red point is the final result, the white point is the result after intensity-based refinement, and the gray point is the initial prediction:
It has been a while that I worked on this, but this matches with what I remember as the typical difference between the two methods. Nevertheless, the difference might be larger on other datasets. The main possible reason that I can think of at the moment is the following:
The implementation of the intensity-based refinement does not optimize the whole homography that it uses, instead it optimizes for a translation only. Perhaps the predicted homography is inaccurate in your dataset, such that optimizing the translation is not sufficient? The symmetry-based refinement, on the other hand, optimizes the whole homography, so it can "fix" an inaccurate initial guess of the homography.
from camera_calibration.
I am attempting to render the same pattern (8 star segments) as the one provided in your sample dataset.
from camera_calibration.
I realized, in my custom implementation, that I forgot to account for the fact that PatternIntensityAt requires coordinates from [-0.5, 0.5], with pixel center convention. After adding the necessary transform, I am able to render the pattern correctly.
from camera_calibration.
Thanks for the update - can this issue be closed, or are the results still unstable after the fix?
from camera_calibration.
Actually I did have more questions about the results.
I've un-commented all the debug code here and here and all the rendered and transformed patterns work fine.
I've added statements to track loss and while the intensity-based refinement appears to be converging (loss reduces significantly with each iteration, eventually "converges", in my example from 41181.1 to 3393.69), the final results differ wildly from the symmetry-based method.
I've included the features refined from both methods below, where the red signifies results from the intensity based matching, and green signifies results from symmetry.
As same predictions and transformations are used between both methods, do you have any insight into why the output from the methods would differ by such a huge degree?
Steps I have tried:
- Changing anti-aliasing sample #
- Changing window_half_extent values
Thank you so much for your time!
from camera_calibration.
You're right - the matching based refinement was working well, but as it's only optimizing for the translation shift, and the original homography was off, it predicts a feature that isn't accurate.
In my pipeline I feed the homography predicted from the symmetry based refinement into the matching based refinement and the results look great. Thank you so much, I really appreciate the time and effort you took to help me with this.
from camera_calibration.
Related Issues (20)
- How to implement binocular stereo distance measurement HOT 1
- Questions about undistortion of generic models HOT 2
- Question about calibrating a stereo camera HOT 1
- make[1]: *** [CMakeFiles/Makefile2:907: applications/camera_calibration/CMakeFiles/camera_calibration.dir/rule] Error 2 make: *** [Makefile:487: camera_calibration] Error 2 HOT 2
- Availability of datasets used in the paper HOT 1
- how to use the intrinsics0.yaml and how to run stere depth estimation correctly HOT 3
- How to use the camera_tr_rig.yaml file in stereo calibration? HOT 5
- Purpose of `3.f` offset in Pixel-Grid Point Conversions HOT 1
- Pose Estimation HOT 1
- central_opencv raise error with --num_pyramid_levels = 4 HOT 1
- feature extraction and .bin HOT 2
- Issue with linking boost HOT 4
- Convergence issue HOT 2
- Feature points not found
- Question: Solution Convariance/Uncertainty
- Issue with building HOT 1
- Don't optimize 3D pattern feature
- Failing Calibration Initialization
- Discrepancy Between OpenGV Calibration Results and Expected Accuracy
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from camera_calibration.