Closed Leiguo924 closed 7 months ago
Maybe you can share a screenshot with the left and right image. Some ASTER data have clouds and this can mess things up.
Ok, here is the snapshot of the images, they are basically cloud free. I just wonder why jitter_solve loaded 0 matches?
Hi Tristan,
Can you confirm if the dense match files produced from stereo is being passed to jitter solve correctly using match-file-prefix
flag? Jitter solve should not make matches itself, as it requires dense matches from stereo to run successfully. I ran into similar errors when there were slight variations in the name of the match file which is produced from stereo and the name which jitter_solve expects to decipher using the match-file-prefix
. If you share your commands, we can help debug this.
Thanks, Shashank
Indeed. There are detailed step-by-step instructions for how to create and copy match files. See for example https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html#id3, and the text above that for background.
I will also suggest doing all those plots done there, to ensure the residuals and errors are as expected.
Hi Both,
Indeed. There are detailed step-by-step instructions for how to create and copy match files. See for example https://stereopipeline.readthedocs.io/en/latest/tools/jitter_solve.html#id3, and the text above that for background.
I followed exactly the same workflow to test the jitter_solve
program. The .match file was copied from the output of parallel_stereo
and renamed to be input to jitter_solve
.
Hi Tristan, Can you confirm if the dense match files produced from stereo is being passed to jitter solve correctly using
match-file-prefix
flag?If you share your commands, we can help debug this.
I have confirmed again the name of the .match file, it should be correct when companied with the parameter set in match-file-prefix
flag. Also, the match file should be valid, since its size is ~5.9 mb.
Here is my command:
mkdir -p $tmp/jitter
cp $tmp/bm-run-disp-tmp-Band3N_proj__tmp-Band3B_proj.match $tmp/jitter/run-Band3N__Band3B.match
jitter_solve $tmp/tmp-Band3N.tif $tmp/tmp-Band3B.tif \
$tmp/ba-align-run-run-tmp-Band3N.adjusted_state.json \
$tmp/ba-align-run-run-tmp-Band3B.adjusted_state.json \
--max-pairwise-matches 100000 \
--num-lines-per-position 100 \
--num-lines-per-orientation 100 \
--max-initial-reprojection-error 20 \
--translation-weight 1000 \
--rotation-weight 0 \
--num-iterations 10 \
--robust-threshold 0.25 \
--match-files-prefix $tmp/jitter/run \
--heights-from-dem $ref_dem \
--heights-from-dem-weight 0.1 \
--heights-from-dem-robust-threshold 0.1 \
-o $tmp/jitter/run
Hi Tristan,
The issue is file path parsing.
I suggest 2 options. Rename your images and cameras without the tmp
prefix. So the new file names would be:
$tmp/Band3N.tif $tmp/Band3B.tif \
$tmp/ba-align-run-run-Band3N.adjusted_state.json \
$tmp/ba-align-run-run-Band3B.adjusted_state.json
Then the command will run, hopefully. Right now jitter solve does not know how to map with your currently provided prefix. Currently it would search probably for the match file to have the name like: jitter/run-tmp-Band3N__tmp-Band3B.match
. If you remove the tmp
letters from the images and cameras currently passed to jitter solve, it should be fine :)
Hi Shashank,
Thanks, now I understand, the prefix of the .match file much exactly match the file name of the images. This problem has been solved.
However, I encountered into another problem, the solution of jitter_solve
did not converge after reaching max iterations. So how could I refine this step? Like add --ip-per-image
option in the bundle_adjust
?
Error message: _Termination: NOCONVERGENCE (Maximum number of iterations reached. Number of iterations: 10.) Found a valid solution, but did not reach the actual minimum.
Don't worry about the solution not converging, the cost function goes down enough during the specified number of iterations to remove jitter. Plotting the results as mentioned in the rest of the tutorial prepared by Oleg would hopefully bring the improvement out :)
Thanks for your reply. Now I should close this issue as solved.
@TristanBlus , glad to hear you figured out the issue, and fine to close the github issue, but if you don't mind reporting back on your results (with a figure or two), we would really appreciate it. A lot of this was developed/implemented recently, and requires further testing and validation. And there may be lingering bugs or other issues that can need to be fixed. Thanks!
Of course. I will continue testing this program and see how it would improve the ASTER DEM generation. The figures will be uploaded later when I go through the whole procedure. Thanks.
I added a blurb to the error message about "Termination: NO_CONVERGENCE" and another small blurb to the error message about not finding matches to check for the naming convention. Also will explain the naming convention in the doc. (Will check this in soon.) Longer term this needs to be handled in a more integrated way.
Yes, looking forward to results and error plots.
Hello, I have been testing the new csm model for removing common jitters in the ASTER DEMs. I absolutely followed the same workflow described in Sec. 16.35.8. in the instructions, but used different images. However, the jitter_solve command failed due to no matches can be found.
error message: "Loaded 0 matches. Failed to build a control network. Check the bundle adjustment directory for clean matches. Or, consider removing all .vwip and .match files and increasing the number of interest points using --ip-per-image or --ip-per-tile, or decreasing --min-matches, and then re-running bundle adjustment."
So, which option should I tune for collecting sufficient interest points? And why?
Just for tesing, the source image I used: AST_L1A_00310162016041942_20230329121407_20863.zip