Camera.cpp Distort() and Undistort() functions are commented out?
rgreid opened this issue · comments
Hi Scott, wondering why the Distort() and Undistort() functions are commented out in Camera.cpp?
Importantly, the MarkerDetector/MarkerDetectorImpl class calls LabelSquares(), which in turn calls the Camera class' non-functional Undistort() function?
Have I missed something in the documentation? Is a pre-rectified image expected? Looking at one of your nodes, the images received from ROS are not rectified before being passed to marker_detector.Detect(). Thanks.
After spending some more time looking at this, LabelSquares(), calls the Undistort() function to make straight lines actually straight when detecting squares. It later uses Distort() to transform the corners of each square back to pixel coordinates.
With the Distort/Undistort() code commented-out in the current release, it is trying to fit squares to a distorted image. For the wide field-of-view lens I'm using, this introduces a few pixels of error unnecessarily, which is certainly a bad thing.
Yes, originally, I think this was designed to be used with pre-rectified images. Ideally, there should be a parameter that specifies if you are using rectified or unrectified images that then either ignores or uses this code. If you address this, please submit a pull request.
—Scott
On Sep 28, 2015, at 3:55 AM, Rob Reid notifications@github.com wrote:
After spending some more time looking at this, LabelSquares(), calls the Undistort() function to make straight lines actually straight when detecting squares. It later uses Distort() to transform the corners of each square back to pixel coordinates.
With the Distort/Undistort() code commented-out in the current release, it is trying to fit squares to a distorted image. For the wide field-of-view lens I'm using, this introduces a few pixels of error unnecessarily, which is certainly a bad thing.
—
Reply to this email directly or view it on GitHub #65 (comment).
The Camera object subscribes to a cam_info_topic. Wouldn't a pre-rectified camera pass a cam_info message with distortion coefficients set to zero, making this a no-op?
Either way it doesn't make sense to comment these functions out. We want to fit squares to the normalized image.
My company won't let me do PRs :/ I plumbed Devernay's wide FOV model into this code instead, unfortunately I can't feed that back either. --Rob
I’m pretty sure the rectified camera messages still have the camera parameters filled in. Unfortunately, I don’t support this too actively anymore due to lack of time, and I don’t want to just uncomment things now and break this for other people. There are a few other co-maintainers — perhaps one of them will be able to crate a fix. Otherwise, it may not get done for some time. Even though you can’t submit a pull request, I’d suggest just fixing it for your personal copy and buidling from source.
—Scott
On Sep 29, 2015, at 5:04 PM, Rob Reid notifications@github.com wrote:
The Camera object subscribes to a cam_info_topic. Wouldn't a pre-rectified camera pass a cam_info message with distortion coefficients set to zero, making this a no-op?
Either way it doesn't make sense to comment these functions out. We want to fit squares to the normalized image.
My company won't let me do PRs :/ I plumbed Devernay's wide FOV model into this code instead, unfortunately I can't feed that back either. --Rob
—
Reply to this email directly or view it on GitHub #65 (comment).
So if I understand well, at the end what is used to compute the marker's poses is the rectified image? I had trouble with the accuracy of marker detection but then I realized using the P intrinsic matrix instead of K leads to better results. (P and K as defined here). If you confirm I could make a pull request to set P or K as a parameter.
This issue was moved to ros-perception#26