CORRELATION interrupted

[zhaomumu233]

I use two stereo satellite images to generate DEM, and the dense matching algorithm I choose is asp_sgm.

When I use a stereo satellite image with a smaller area, I can successfully generate a better quality DEM, but when I use a satellite image with a larger area, the program breaks at the correlation stage.

Through the information output from the terminal, I found that the program is interrupted after processing all sub-blocks. Open the last subfolders in the folder such as "1-68640_54080_1385_1686", there are a total of 22 files in it.

The "Too many open files (code = 4)" error had previously appeared for larger areas of satellite imagery, but was resolved by using the latest version of ASP. Do you have any good suggestions for interruptions in the "correlation" phase?

Thank you very much.

The asp version I am using is as follows：

(base) hipeson@hipeson-Super-Server:~$ /home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux/bin/parallel_stereo --version NASA Ames Stereo Pipeline 3.0.1-alpha Build ID: e8809e32 Build date: 2022-04-14

Built against: NASA Vision Workbench 3.0.0 Build ID: 63a66938 USGS ISIS 5.0.1 Boost C++ Libraries 106800 GDAL 2.4.1 | 20190315

The commands and parameters I use are as follows:

/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux/bin/parallel_stereo fwd.tif nad.tif result/1 --threads 16 -t rpc -s 300-SGM-stereo.default

PREPROCESSING alignment-method affineepipolar ip-detect-method 1 ip-per-tile 200 individually-normalize CORRELATION cost-mode 4 stereo-algorithm 1 corr-kernel 7 7 corr-tile-size 2080 corr-memory-limit-mb 6000

The error message of the terminal is as follows:

[ 2022-Apr-17 14:32:27 ] : CORRELATION FINISHED stereo_corr: elapsed=37:35.09 ([hours:]minutes:seconds), memory=5762104 (kb)

--> Setting number of processing threads to: 8 Using stereo file SGM-stereo.default. Writing log info to: try1/1-12480_54080_2080_1686/12480_54080_2080_1686-log-stereo_corr-04-17-1407-23970.txt Using session: rpc. Loading camera model: block-fwd.tif Loading camera model: block-nad.tif Distance between camera centers in meters: 12616.5. --> Using no pre-processing filter with stereo algorithm: asp_sgm Stage 1 --> CORRELATION --> Full-res search range based on D_sub: (Origin: (-1237, -341) width: 2637 height: 1441) Kernel size: Vector2(7,7) Search range: (Origin: (-1237, -341) width: 2637 height: 1441) Cost mode: 4 Writing: try1/1-12480_54080_2080_1686/12480_54080_2080_1686-D.tif

--> Correlation :[................................................] 0% --> Correlation :[................................................] 2% …… --> Correlation :[****.] 99% --> Correlation :[] Complete!

[ 2022-Apr-17 14:32:36 ] : CORRELATION FINISHED stereo_corr: elapsed=24:53.89 ([hours:]minutes:seconds), memory=3997736 (kb)

--> Setting number of processing threads to: 8 Using stereo file SGM-stereo.default. Writing log info to: try1/1-14560_54080_2080_1686/14560_54080_2080_1686-log-stereo_corr-04-17-1408-24313.txt Using session: rpc. Loading camera model: block-fwd.tif Loading camera model: block-nad.tif Distance between camera centers in meters: 12616.5. --> Using no pre-processing filter with stereo algorithm: asp_sgm

[ 2022-Apr-17 14:08:04 ] : Stage 1 --> CORRELATION --> Full-res search range based on D_sub: (Origin: (-1237, -341) width: 2637 height: 1441) Kernel size: Vector2(7,7) Search range: (Origin: (-1237, -341) width: 2637 height: 1441) Cost mode: 4 Writing: try1/1-14560_54080_2080_1686/14560_54080_2080_1686-D.tif --> Correlation :[................................................] 0% --> Correlation :[................................................] 2% …… --> Correlation :[****.] 99% --> Correlation :[] Complete!

[ 2022-Apr-17 14:32:36 ] : CORRELATION FINISHED stereo_corr: elapsed=24:35.27 ([hours:]minutes:seconds), memory=2202424 (kb)

Traceback (most recent call last): File "/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux/libexec/parallel_stereo", line 1013, in spawn_to_nodes(step, settings, parallel_args) File "/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux/libexec/parallel_stereo", line 522, in spawn_to_nodes asp_system_utils.generic_run(cmd, opt.verbose) File "/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux/libexec/asp_system_utils.py", line 480, in generic_run raise Exception('Failed to run: ' + cmd_str) Exception: Failed to run: parallel --will-cite --env ASP_DEPS_DIR --env PATH --env LD_LIBRARY_PATH --env ASP_LIBRARY_PATH --env PYTHONHOME -u -P 10 -a /data/image/150/tmp_nftxqkn "/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux/bin/python /home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux/libexec/parallel_stereo block-fwd.tif block-nad.tif try1/1 -t rpc -s SGM-stereo.default --skip-low-res-disparity-comp --processes 10 --threads-multiprocess 8 --entry-point 1 --stop-point 2 --work-dir /data/ image /150 --isisroot /home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-14-x86_64-Linux --tile-id {}"

[oleg-alexandrov]

Your search range is outrageous, meaning the last two numbers on this line:

Full-res search range based on D_sub: (Origin: (-1237, -341) width: 2637 height: 1441)

Likely you have either high mountains, or clouds, or some outlier somewhere, or bad alignment. You can try opening both aligned images in stereo_gui like this:

stereo_gui --single-window result/1-L.tif result/1-R.tif

and toggle one of them on and off, and see just how different they are. If you see little changes in some places but huge changes in other places that means the alignment did the job but it was not enough. Then you can try using mapprojected images and some options to reduce the search range, per this: https://stereopipeline.readthedocs.io/en/latest/tutorial.html#handling-clouds and https://stereopipeline.readthedocs.io/en/latest/next_steps.html#mapproj-example.

(BTW, in the last days or so I managed to introduce a crash in in the --ip-filter-using-dem option which I caught a bit later, so if you have the bad luck or running into it you'd need to either not use this with your build or update it to the latest, which is 2022-04-17-daily-build.)

[zhaomumu233]

glad to have your advice.

I do have high mountains in the right area of my image. Due to some characteristics of my experimental images, vertical disparity cannot be eliminated as well as traditional satellite imagery through image alignment. Therefore, on the epipolar image, the same pixel has horizontal disparity and vertical disparity.

The traditional dense matching method based on epipolar 1D search doesn't work for my images, but ASP's automatic estimated search range works well, which I think is great.

Based on your suggestion, the next step is to use the mappproject tool to geo-project the image, use the ASP of 2022-04-17-daily-build, and add the --ip-filter-using-dem option. Then generate a DEM to see if it can be successful

In addition to that, I would like to ask you some conjectures.

1. Since the whole image is not well aligned, is it possible to use the local_epipolar alignment method while increasing the value of ip-per-tile to get more matching points. Does this make the search range smaller and more precise?

2. Change corr-seed-mode to 2, which is Low-resolution disparity from an input DEM. Use the Copernicus 30 m DEM or a better resolution open source DEM. Does this method narrow the search range compared to corr-seed-mode 1?

Thank You~

[zhaomumu233]

When I use the mapproject tool for image projection, the program breaks. My image resolution is about 1m, so I set mpp to 1, and the open source DEM is Copernicus 30m DEM. According to the error message, it should be because the image is too large. How to successfully project in this case?

The command entered in the terminal is as follows：

mapproject -t rpc --mpp 1 COP30.tif nad.tif map-nad.tif --tif-compress LZW --threads 20

The error message of the terminal is as follows：

Image box: (Origin: (0, 0) width: 181523 height: 91054) Output image size: (width: 181523 height: 91054) Writing: map-nad.tif [.........................................................................] 0%terminate called after throwing an instance of 'vw::ArgumentErr' what(): Refusing to allocate an image larger than 79999 pixels on a side (you requested 108651 x 280)

[oleg-alexandrov]

1. Since the whole image is not well aligned, is it possible to use the local_epipolar alignment method while increasing the value of ip-per-tile to get more matching points. Does this make the search range smaller and more precise?

This should work in moderately steep terrain. For very steep terrain the mapprojection option should work better.

2. Change corr-seed-mode to 2, which is Low-resolution disparity from an input DEM. Use the Copernicus 30 m DEM or a better resolution open source DEM. Does this method narrow the search range compared to corr-seed-mode 1?

The --corr-seed-mode 2 option is good when you cannot get a good initial disparity, maybe because of noise in images. But if your terrain is truly steep, rather than having clouds which just artificially increase the range, this option cannot reduce the search range more than what the terrain says it should be.

So mapprojection still looks like the better option.

mapproject -t rpc --mpp 1 COP30.tif nad.tif map-nad.tif --tif-compress LZW --threads 20

The error message of the terminal is as follows：

Image box: (Origin: (0, 0) width: 181523 height: 91054) Output image size: (width: 181523 height: 91054) Writing: map-nad.tif [.........................................................................] 0%terminate called after throwing an instance of 'vw::ArgumentErr' what(): Refusing to allocate an image larger than 79999 pixels on a side (you requested 108651 x 280)

I spent quite a bit of time trying to reproduce this, and with no luck. I tried even bigger data than yours, and each time the software was breaking up the images into small tiles, rather than failing as above. Here's what I think the tool should be doing:

mapproject -t rpc --mpp 0.01 copernicus.tif left.tif left.map.tif --tif-compress LZW --threads 20 mapproject_single --query-projection copernicus.tif left.tif left.map.tif -t rpc --mpp 0.01 --tif-compress LZW --threads 20 --> Setting number of processing threads to: 20 Using session: rpc. Loading camera model: left.tif Image box: (Origin: (0, 0) width: 1826875 height: 1364328) Output image size: (width: 1826875 height: 1364328) Query finished, exiting mapproject tool.

Output image size is 1826875 by 1364328 pixels. Splitting into 357 by 267 tiles.

Can you try to type " mapproject --version", and see what you get? Hopefully it is a recent date. If the date is recent, you can also try adding '--tile-size 2048' to the command, but normally such a thing should happen automatically for recent versions of the software.

[zhaomumu233]

Sorry I was using ASP2.7 before, so I got the previous error.

When I read the ASP documentation, the parameter "--mpp" is interpreted as "Set the output file resolution in meters per pixel". My image resolution is about 1m, so I set it to "--mpp 1", but I see the suggested command you gave is "--mpp 0.01". Am I misunderstanding, or are you testing the feasibility of outputting a very large pixel image?

I used the 2022-04-17 version of ASP and successfully geoprojected the image using the mapproject tool. But there are still some small problems such as missing image on the right side of the image.

The command entered in the terminal is as follows：

/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-17-x86_64-Linux/bin/mapproject -t rpc --mpp 1 COP30.tif block-nad.tif map-nad.tif --tif-compress LZW --threads 20

The error message of the terminal is as follows：

0ERROR 4: ./map-nad_tif_tiles/tile_20480_0_25600_5120.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_20480_0_25600_5120.tif. Skipping it ..ERROR 4:./map-nad_tif_tiles/tile_15360_5120_20480_10240.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_15360_5120_20480_10240.tif. Skipping it .10ERROR 4: ./map-nad_tif_tiles/tile_15360_10240_20480_15360.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_15360_10240_20480_15360.tif. Skipping it ..ERROR 4:./map-nad_tif_tiles/tile_15360_15360_20480_20480.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_15360_15360_20480_20480.tif. Skipping it .20.ERROR 4: ./map-nad_tif_tiles/tile_15360_20480_20480_25600.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_15360_20480_20480_25600.tif. Skipping it ..ERROR 4:./map-nad_tif_tiles/tile_10240_25600_15360_30720.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_10240_25600_15360_30720.tif. Skipping it 30.ERROR 4: ./map-nad_tif_tiles/tile_10240_30720_15360_35840.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_10240_30720_15360_35840.tif. Skipping it ..ERROR 4:./map-nad_tif_tiles/tile_10240_35840_15360_40960.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_10240_35840_15360_40960.tif. Skipping it 40.ERROR 4: ./map-nad_tif_tiles/tile_5120_40960_10240_46080.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_5120_40960_10240_46080.tif. Skipping it ERROR 4:./map-nad_tif_tiles/tile_10240_40960_15360_46080.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_10240_40960_15360_46080.tif. Skipping it ..50ERROR 4: ./map-nad_tif_tiles/tile_5120_46080_10240_51200.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_5120_46080_10240_51200.tif. Skipping it ..ERROR 4:./map-nad_tif_tiles/tile_5120_51200_10240_56320.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_5120_51200_10240_56320.tif. Skipping it .60ERROR 4: ./map-nad_tif_tiles/tile_5120_56320_10240_61440.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_5120_56320_10240_61440.tif. Skipping it ..ERROR 4:./map-nad_tif_tiles/tile_0_61440_5120_66560.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_0_61440_5120_66560.tif. Skipping it ERROR 4: `./map-nad_tif_tiles/tile_5120_61440_10240_66560.tif' not recognized as a supported file format. Warning 1: Can't open ./map-nad_tif_tiles/tile_5120_61440_10240_66560.tif. Skipping it .70...80...90...100 - done. gdal_translate -co compress=lzw -co bigtiff=yes -co TILED=yes -co INTERLEAVE=BAND -co BLOCKXSIZE=256 -co BLOCKYSIZE=256 ./map-nad_tif_tiles/mosaic.vrt map-nad.tif Input file size is 181523, 91054 0...10...20...30...40...50...60...70...80...90...100 - done. Removing: ./map-nad_tif_tiles/ Wrote: map-nad.tif Finished in 3144.875788450241 seconds.

[oleg-alexandrov]

Yes, I set --mpp 0.01 for testing.

I don't know why you see pieces missing, and why there are tiling artifacts. It could be a filesystem thing on your system. You can try rerunning the problematic part with mapproject with the option --t_projwin. The bounds can be found as described here: https://stereopipeline.readthedocs.io/en/latest/tools/stereo_gui.html#finding-pixel-values-and-region-bounds.

If the small part works by itself, it can be merged into the big maprpojected images with dem_mosaic. For the future, maybe you should use fewer processes on your machine, or maybe there are some storage issues, not sure. This is is a big dataset, so maybe your system has issues completing all of it.

[zhaomumu233]

The missing part of the projected image before may be related to the performance of the computer. When switching to another computer, a complete projected image can be obtained.

I used the image processed by mapproject to generate DEM, but the program was interrupted by an error at the "Stage 1 --> LOW-RESOLUTION CORRELATION" step.The main reason is that the search range is too large, which leads to the failure of low-resolution disparity map generation.

I also used the stereo_gui tool to select a small area for DEM generation, but the program still reported an error and interrupted because the search range was too large.

I checked the projected geolocation and both images are the same and correct. I also checked the ".match" file and the matching points generated are sufficient, correct and evenly distributed. Compared with the two unprojected images, the projected images are more similar, and the image distortion is further weakened.

I thought the search range would be reduced after projection, but the situation is not as expected. What are the reasons that may cause the search range of the projected image to become larger? Thank you so much!

The command used is as follows:

/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-17-x86_64-Linux/bin/parallel_stereo map-fwd.tif map-nad.tif \ result/1 --threads-multiprocess 15 --threads-singleprocess 15 \ -t rpcmaprpc -s SGM-stereo.default COP30.tif

The content of the default file is as follows:

ip-detect-method 1 ip-per-tile 200 individually-normalize left-image-crop-win 53174 9455 9907 9979 right-image-crop-win 140920 25847 31092 30369 cost-mode 4 stereo-algorithm 1 corr-kernel 7 7 corr-tile-size 2080 corr-memory-limit-mb 5000

The error message is as follows(use a small area):

[ 2022-Apr-22 16:52:32 ] : Stage 1 --> LOW-RESOLUTION CORRELATION

• Loading images for IP detection. No IP file found, computing IP now.
• Detecting interest points. --> Matching interest points using homography. Looking for IP in left image... Using 200 interest points per tile (1024^2 px). Detecting IP Removing IP near nodata with radius 4 Found interest points: 18869 Recording interest points to file: result/1-L.vwip Looking for IP in right image... Using 200 interest points per tile (1024^2 px). Detecting IP Removing IP near nodata with radius 4 Found interest points: 180288 Recording interest points to file:result/1-R.vwip --> Adjusted uniqueness threshold: 0.8 Matching: [***.] 99% Matched points: 9354 Inlier threshold: 200 RANSAC iterations: 100
  • Writing match file: result/1-L__R.match --> Using interest points to determine search window.
  • Loading match file: result /1-L__R.match Removed 0 outliers based on percentiles of differences of interest points with --outlier-removal-params. Refined search range using a histogram and --outlier-removal-params: (Origin: (438.509, 216.057) width: 19791.8 height: 19955.5) Search width of 19791 is greater than desired limit of 4000, retrying with more aggressive IP filter. Refined search range using a histogram and --outlier-removal-params: (Origin: (438.509, 216.057) width: 19791.8 height: 19955.5) Search width of 19791 is greater than desired limit of 4000, retrying with more aggressive IP filter. Refined search range using a histogram and --outlier-removal-params: (Origin: (438.509, 216.057) width: 19791.8 height: 19955.5) Search width of 19791 is greater than desired limit of 4000, retrying with more aggressive IP filter. Refined search range using a histogram and --outlier-removal-params: (Origin: (438.509, 216.057) width: 19791.8 height: 19955.5) D_sub search range: (Origin: (-204.125, -228.125) width: 2471.25 height: 2491.25) px Warning: Unable to compute valid search ranges for SGM input. Warning: Unable to compute valid search ranges for SGM input. Warning: Unable to compute valid search ranges for SGM input. Writing: result /1-D_sub.tif --> Low-resolution disparity:[***] Complete! Filtering outliers in D_sub based on --outlier-removal-params. Empty disparity. Traceback (most recent call last): File "/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-17-x86_64-Linux/libexec/parallel_stereo", line 1005, in calc_lowres_disp(args, opt, sep, resume = opt.resume_at_corr) File "/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-17-x86_64-Linux/libexec/stereo_utils.py", line 279, in calc_lowres_disp stereo_run('stereo_corr', local_args, opt, msg='') File "/home/hipeson/StereoPipeline-3.0.1-alpha-2022-04-17-x86_64-Linux/libexec/stereo_utils.py", line 205, in stereo_run raise Exception('Stereo step ' + kw['msg'] + ' failed') Exception: Stereo step failed

[oleg-alexandrov]

Your search range, width: 19791.8 height: 19955.5, is totally out there, the worst I have ever seen. Anything over 200 pixels is not good. Can you open your result/1-L.tif and result/1-R.tif in stereo_gui and put them on top of each other (from the menu, choose to view in single window). Something is messed up and I don't know what. Normally these images should have quite little difference.

[zhaomumu233]

I used "stereo_gui --single-window" to visualize the image, 1-L.tif in the red box and 1-R.tif in the blue box, the result is shown below. The two images do not overlap, which seems to be the reason for the excessive search range.

I use "gdalinfo" to view the information of 1-L.tif and 1-R.tif, the results are as follows：

gdalinfo 1-L.tif Driver: GTiff/GeoTIFF Files: 1-L.tif Size is 9907, 9979 Corner Coordinates: Upper Left ( 78.3686616, 30.2853299) ( 78d22' 7.18"E, 30d17' 7.19"N) Lower Left ( 78.3686616, 30.0164012) ( 78d22' 7.18"E, 30d 0'59.04"N) Upper Right ( 78.6356499, 30.2853299) ( 78d38' 8.34"E, 30d17' 7.19"N) Lower Right ( 78.6356499, 30.0164012) ( 78d38' 8.34"E, 30d 0'59.04"N) Center ( 78.5021557, 30.1508655) ( 78d30' 7.76"E, 30d 9' 3.12"N) Band 1 Block=256x256 Type=Float32, ColorInterp=Gray

$ gdalinfo 1-R.tif Driver: GTiff/GeoTIFF Files: 1-R.tif Size is 31092, 30369 Coordinate System is: Corner Coordinates: Upper Left ( 78.3647898, 30.2872702) ( 78d21'53.24"E, 30d17'14.17"N) Lower Left ( 78.3647898, 30.0144609) ( 78d21'53.24"E, 30d 0'52.06"N) Upper Right ( 78.6440940, 30.2872702) ( 78d38'38.74"E, 30d17'14.17"N) Lower Right ( 78.6440940, 30.0144609) ( 78d38'38.74"E, 30d 0'52.06"N) Center ( 78.5044419, 30.1508655) ( 78d30'15.99"E, 30d 9' 3.12"N) Band 1 Block=256x256 Type=Float32, ColorInterp=Gray NoData Value=-32768

I also use arcgis software to open 1-L.tif and 1-R.tif, the two images overlap very well, the color is 1-R.tif, and the black and white is 1-L.tif.

The geolocation of both images is correct, but the "stereo_gui --single-window" in ASP is wrong, I think the possible reason is the number of pixels. The size of 1-L.tif is 9907, 9979, and the size of 1-R.tif is 31092, 30369. The relationship between the two is about three times, which is consistent with the image displayed by stereo_gui.

When two images have different pixel counts, or different image resolutions, is it difficult for ASP to deal with it? I don't know if my guess is correct, please advise. Thank you very much！

[oleg-alexandrov]

Actually you did share before the text stereo printed on screen. My apologies, I forgot.

I think the problem is the following, and I ran into it as well. Your two images must be projected at the same resolution. So, the value of --tr to be passed to the mapproject command should be the same. This is discussed here: https://stereopipeline.readthedocs.io/en/latest/next_steps.html#resolution-of-mapprojection

So you can delete your mapprojected images and try again. Since your images are large, I will suggest mapprojecting first onto only a small area, using the --t_projwin option of mapproject. How to get the window to pass to this option is described here: https://stereopipeline.readthedocs.io/en/latest/tools/stereo_gui.html#finding-pixel-values-and-region-bounds

I hope you can inspect in the gui your mapprojected images before running stereo. They will hopefully have similar size and similar level of detail.

On Sat, Apr 23, 2022 at 8:17 AM Oleg Alexandrov @.***> wrote:

This shows that image alignment failed. Can you share the text which the program prints on the screen as it runs? It will likely suggest the issue.

On Sat, Apr 23, 2022, 03:10 赵林博 @.***> wrote:

I used "stereo_gui --single-window" to visualize the image, 1-L.tif in the red box and 1-R.tif in the blue box, the result is shown below. The two images do not overlap, which seems to be the reason for the excessive search range. [image: 3] https://user-images.githubusercontent.com/67795058/164890008-2018402d-a66a-4c50-8168-373acd6008b3.png

I use "gdalinfo" to view the information of 1-L.tif and 1-R.tif, the results are as follows：

gdalinfo 1-L.tif Driver: GTiff/GeoTIFF Files: 1-L.tif Size is 9907, 9979 Corner Coordinates: Upper Left ( 78.3686616, 30.2853299) ( 78d22' 7.18"E, 30d17' 7.19"N) Lower Left ( 78.3686616, 30.0164012) ( 78d22' 7.18"E, 30d 0'59.04"N) Upper Right ( 78.6356499, 30.2853299) ( 78d38' 8.34"E, 30d17' 7.19"N) Lower Right ( 78.6356499, 30.0164012) ( 78d38' 8.34"E, 30d 0'59.04"N) Center ( 78.5021557, 30.1508655) ( 78d30' 7.76"E, 30d 9' 3.12"N) Band 1 Block=256x256 Type=Float32, ColorInterp=Gray

$ gdalinfo 1-R.tif Driver: GTiff/GeoTIFF Files: 1-R.tif Size is 31092, 30369 Coordinate System is: Corner Coordinates: Upper Left ( 78.3647898, 30.2872702) ( 78d21'53.24"E, 30d17'14.17"N) Lower Left ( 78.3647898, 30.0144609) ( 78d21'53.24"E, 30d 0'52.06"N) Upper Right ( 78.6440940, 30.2872702) ( 78d38'38.74"E, 30d17'14.17"N) Lower Right ( 78.6440940, 30.0144609) ( 78d38'38.74"E, 30d 0'52.06"N) Center ( 78.5044419, 30.1508655) ( 78d30'15.99"E, 30d 9' 3.12"N) Band 1 Block=256x256 Type=Float32, ColorInterp=Gray NoData Value=-32768

I also use arcgis software to open 1-L.tif and 1-R.tif, the two images overlap very well, the color is 1-R.tif, and the black and white is 1-L.tif. [image: arcgis] https://user-images.githubusercontent.com/67795058/164890069-72ca769f-4cc0-47ac-9060-c738d9553670.jpg

The geolocation of both images is correct, but the "stereo_gui --single-window" in ASP is wrong, I think the possible reason is the number of pixels. The size of 1-L.tif is 9907, 9979, and the size of 1-R.tif is 31092, 30369. The relationship between the two is about three times, which is consistent with the image displayed by stereo_gui.

When two images have different pixel counts, or different image resolutions, is it difficult for ASP to deal with it? I don't know if my guess is correct, please advise. Thank you very much！

— Reply to this email directly, view it on GitHub https://github.com/NeoGeographyToolkit/StereoPipeline/issues/363#issuecomment-1107446421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKDU3HK35CTJPNLTB6AH5LVGPD7XANCNFSM5TT44QNQ . You are receiving this because you commented.Message ID: @.***>

[zhaomumu233]

In fact, the two images I use have different resolutions, so when using "mapproject", I set the "--mpp" parameter differently.

I was reading the ASP documentation and found "If these two images have rather different auto-determined resolutions, it is suggested that the smaller one be used for both."

I think, if the lower resolution image is also projected to the higher resolution, will it affect the quality of the final DEM?

But for now, I can only do this experiment first. I will project both images and keep them at the same resolution. If there are new progress or problems in the follow-up, I will tell you here in time. Thanks a lot for your help.

[oleg-alexandrov]

Given that your two input images have different native resolutions, I am not fully sure what the optimal mapprojection resolution should be. You can try, in addition to using the highest resolution (that is, smallest ground sample distance), also something in between. For a fair comparison, the resulting point clouds should be made into DEMs using the same value for the --tr parameter rather than counting on it determining one automatically for each. Then the DEMs can be examined and see which has more detail and less artifacts.

[zhaomumu233]

I projected the two images to the same ground resolution and passed it into ASP to successfully generate a DEM. The integrity and accuracy of the DEM have achieved the expected results.

Then I use Stereo_GUI to open 1-L.tif and 1-R.tif. When I used "single-window", I found that the two images did not overlap with a large dislocation. But when I use "zoom all images to same region" first, and then use "single-window", I find that the two images overlap very well.

There may still be some hiccups, but now I get the correct results, which I think is a big improvement. The current success would not have been possible without your help, and I would like to express my sincerest thanks again for your continued help!

[oleg-alexandrov]

Your 1-L.tif and 1-R.tif represent the same ground, so when you "zoom all images to same region" they agree. Without that they don't agree because on the ground they have different extent, just like the input images, so one image may cover more terrain than another.

That is not a problem in stereo, as the constant shift among them gets compensated for. The big problem was the different resolution, as that resulted in a scale change and a big search range.

It can be convenient to cut both mapprojected images to the same domain using "gdal_translate -projwin" before doing stereo, and then likely the software will run a little faster and there will be no shift between L and R. But this is not a crucial thing.