Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix in declared undistorted bounds #375

Merged
merged 1 commit into from
Dec 23, 2021
Merged

Conversation

oleg-alexandrov
Copy link
Contributor

@oleg-alexandrov oleg-alexandrov commented Dec 23, 2021

For haz_cam and perch cam the image dimensions are 224 and 171. Yet, the undistorted dimensions are declared to be 600 and 500. There's no way this is possible, since the distortion of these narrow-field-of-view cameras is small.

Such overestimation actually causes problems. Since the distortion model is given by a polynomial, when it is applied to pixels way outside its calibrated range, weird values can result. Hence, when creating a textured 3D model with the haz_cam image I get a plausible texture, but around it there is an empty ring corresponding to no pixels, followed by a halo of junk, corresponding to 3D points not normally seen in the camera yet which had the bad luck that after being put in camera's coordinate system, normalized, and passed through the distortion polynomial, managed to receive values that actually project into the camera.

After adjusting the undistorted dimensions these problems go away.

No such problems are seen for the nav or sci camera which have more sensible choices. But even for those however the undistorted bounds are too liberal. When undistorting it is preferable to err towards cutting off valid peripheral pixels than to keep all possible pixels with extra areas where no valid pixel values exist. I won't touch those as those undistorted dimensions are not so grossly off to cause issues.

For haz_cam and perch cam the image dimensions are 224 and 171. Yet, the undistorted dimensions are declared to be 600 and 500. There's no way this is possible, since the distortion of these narrow-field-of-view cameras is small.

Such overestimation actually causes problems. Since the distortion model is given by a polynomial, when it is applied to pixels way outside its calibrated range, weird values can result. Hence, when creating a textured 3D model with the haz_cam image I get a plausible texture, but around it there is an empty ring corresponding to no pixels, followed by a halo of junk, corresponding to 3D points not normally seen in the camera yet which had the bad luck that after being put in camera's coordinate system, normalized, and passed through the distortion polynomial, managed to receive values that actually project into the camera. 

After adjusting the undistorted dimensions these problems go away.

No such problems are seen for the nav or sci camera which have more sensible choices.  But even for those however the undistorted values are too liberal. When undistorting it is preferable to err towards cutting off valid peripheral pixels than to keep all possible pixels with extra areas where no valid pixel values exist. I won't touch those as those undistorted dimensions are not so grossly off to cause issues.
Copy link
Member

@bcoltin bcoltin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once tests pass we can squash and merge

@bcoltin bcoltin merged commit 52c1eaa into develop Dec 23, 2021
@oleg-alexandrov oleg-alexandrov deleted the oleg-alexandrov-patch-1 branch December 23, 2021 23:28
luisa-mao pushed a commit to luisa-mao/astrobee-1 that referenced this pull request Jul 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants