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

Improve distortion-mesh interpolator #297

Open
russell-taylor opened this issue Jan 22, 2017 · 11 comments
Open

Improve distortion-mesh interpolator #297

russell-taylor opened this issue Jan 22, 2017 · 11 comments

Comments

@russell-taylor
Copy link
Contributor

For at least one set of distortion parameters that look smooth when plotted, the resulting distortion correction has tearing that makes it appear as if incorrect points are being used for interpolation along a couple columns of distortion correction. See the 1/22/2017 internal distortion document for more info.

@russell-taylor
Copy link
Contributor Author

Making a finer mesh of points when generating the distortion mesh for rendering just makes the torn regions smaller, and turns some of them into wormholes.

@russell-taylor
Copy link
Contributor Author

Locating one of the points causing trouble and removing it from the distortion-mesh specification turned the region around it into a larger region of torn/wormholed space.

@russell-taylor
Copy link
Contributor Author

Changing the size of the local mesh search region when constructing the mesh did not help -- it does not appear to be missing the local points to compare against.

@russell-taylor
Copy link
Contributor Author

We are not getting degenerate normals in the interpolation. Changing the point used to solve for D in the interpolation does not make a difference.

It was never the case that interpolateNearestPoints did not find three points.

@russell-taylor
Copy link
Contributor Author

Removing 2/3 of the left-edge points on left column of the input caused the mesh to push far towards the edge (and even beyond it). It looks like we're extrapolating rather than interpolating for some or many of the points.

@russell-taylor
Copy link
Contributor Author

Added code to do interpolation rather than extrapolation when possible. This is still missing the cases that are failing.

Taking a closer look at one of the failure cases, it appears that uneven spacing of the samples in angle space after they are projected into texture space is causing cases where the first two points closest to the location we're looking for are collinear and to one side of the point; the point to the other side is further away due to nonuniform spacing. Starting with these two points, there is not a good solution. This means that the assumption that we can start with the nearest two points and then find one that leads to a good solution is not true in general.

@russell-taylor
Copy link
Contributor Author

Modifying to avoid making the first two points in the same direction avoids extrapolation except past the boundaries of the mesh and at the hand-inserted (0,0) point. There are still artifacts around the points on the second line. They appear to be reasonably spaced from looking at the generated Json file. The code is now finding points that enable us to interpolate to find values near them. There must be something going awry in the neighbor-picking code that is selecting points that do interpolate but which are not the nearest ones to use.

@russell-taylor
Copy link
Contributor Author

Every point except the origin has three points, so it is returning an interpolated point for them.

@russell-taylor
Copy link
Contributor Author

The interpolator is using 3D geometry for the interpolation, but the two spatial dimensions are not commensurate with the value dimension, so it is possible that interpolation in this distorted space is not behaving correctly? Not sure why this would happen only in specific locations, but perhaps the local spatial derivative is changing rapidly, so the slopes from the two sides don't match.

@russell-taylor
Copy link
Contributor Author

Nope -- scaling the values by up to 1000 larger or smaller on the way in and the inverse on the way out makes no difference. Not the interpolator.

@russell-taylor
Copy link
Contributor Author

Removing half the mesh points along the boundary reduced the frequency of tearing. It looks like we're picking different sets of three points, where all three sets are interpolators for a given region. Because we're picking the two nearest from one column and different ones from the next column we appear to be getting inconsistent interpolations.

Avoiding this will require using a consistent tessellation of the space by the unevenly-spaced points for all points we are trying to look up for the regular-grid distortion mesh. This will ensure C0 continuity for points across space.

It could also be reduced/avoided by having a finer grid of points, so that selection of different ones does not change the outcome.

@russell-taylor russell-taylor changed the title Check distortion-mesh interpolator Improve distortion-mesh interpolator Jun 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant