Processing CTX example for jitter_solve still shows some remaining jitter

[swalterfub]

We have created a sample example for our study area using the new jitter_solve program. The results look quite good, improvements are clearly visible. We had to remove the num-lines-per-position and the num-lines-per-orientation to get any improvements over the plain bundle_adjust solutions, though.

So I would like to ask if there is still room for improvements through parameter tuning? We have created a repo for our example under https://github.com/planetary-fub/asp-jitter_solve-example.

Here are two figures from our resulting analysis:

We plan to submit this example for public discussion to the 6th PDW. Of course we would add you as co-author. Thanks for any suggestion or comments!

[oleg-alexandrov]

Thank you for playing with the tool. Yes, I can still see some residual jitter.

I looked at your script. The workflow is plausible. I am curious what would happen if one really use very fine sampling of poses, so putting back --num-lines-per-position and --num-lines-per-orientation, but instead of 1000 one could use 10-20 or so?

You can also look at the second example, further down, https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html#example-2-worldview-3-digitalglobe-images-on-earth. That one also uses --num-anchor-points-extra-lines to help at first and last lines.

Then, perhaps one could use more dense match points (--num-matches-from-disp-triplets) but that is guesswork.

Also, some of the remaining signal appears to have a non-jitter component too.

As to being a co-author, that is not a requirement in any way, of course. The tools are out there to be used and we're happy when they work.

[oleg-alexandrov]

I also see in the newly created DEM some artifacts which likely come from the jitter solver being a bit overzealous. It is not clear what the magnitude is, and if changing the sampling rate or other params may make it go away.

The danger with giving free reign to individual linescan poses is that they can overfit. In an ideal world one would have several other images with a different along-track trajectory, so then the artifacts that are parallel to the image rows would not be parallel to each other in different image pairs, which will constrain the problem. The tool does support more than two images but it becomes trickier to set up the problem as need pairwise matches for any two input images in the set.

[swalterfub]

Thanks for your suggestions! I tried some variations of the --num-lines-per-position and --num-lines-per-orientation parameters, but the results look rather scary (see Figures). By increasing the parameters to up to 200, the results get closer to the first one above, but don't really show an improvement - do you think it's worth doing more tests with higher values?

--num-lines-per-position 10 --num-lines-per-orientation 10

--num-lines-per-position 20 --num-lines-per-orientation 20

--num-lines-per-position 50 --num-lines-per-orientation 50

--num-lines-per-position 100 --num-lines-per-orientation 100

--num-lines-per-position 200 --num-lines-per-orientation 200

[oleg-alexandrov]

Giving it too much flexibility seems to be causing problems.

At the end of the day, this tool is meant to fix the worst problems. Having a side-by-side figure of intersection error before and after the tool, with same colorbar range, can give users a chance to judge if the performance of the tool is good enough for their goals. You do have such a plot earlier.

At least as important as the intersection error is if artifacts are introduced in the DEM, so one could try to quantify those somehow, maybe using a difference plot, as a hillshaded image may show artifacts but it may not be clear what the magnitude is.

[swalterfub]

Thank you for your valuable comments! We will try to continue with multiple coverage, as an outlook!

[oleg-alexandrov]

Sure. When I revisit jitter work I will play more with your example. Thanks again for trying out the tool. Maybe one day it will have some use.

[swalterfub]

It already has! Thanks for providing all these fantastic DTM-generation tools!