Questions about search range

[Ben Johnson]

Hi there, 

I'm processing some mapprojected pleiades imagery and have a question about the search range. In here you say search range should be less than 100 pixels https://stereopipeline.readthedocs.io/en/latest/next_steps.html#longrun

My logfiles are saying: 

Search range:   Min: (-84, -445) width: 1 height: 140

Am I understanding this is referring to a search range originating at (-84, -445) pixels disparity and searching within a window of 1 pixel horizontally and 140 pixels vertically? This seems very weird to me. 

I've got corr-seed-mode 1 to get my search range from the low res disparity map. I've attached band 2 of the low res disparity map and a QGIS histogram of all bands ( band 1 being the horizontal and band 2 being the vertical I think? ).  This map doesn't seem to bear much resemblance to the search range I'm getting so I'm a bit confused. 

I do note that the option --skip-low-res-disparity-comp seems to be on, even though I didn't turn this on in my script -- has the low res disparty map been assessed to be not that useful?

Here is the full stereo call from the logfile 

stereo_corr -t pleiades 7573544201_MP.TIF 7573548201_MP.TIF 7573544201_MP.XML 7573548201_MP.XML full_area_23rds/dem-24576_10240_2048_2048/24576_10240_2048_2048 refdem_sig2-tile-0.tif --corr-memory-limit-mb 10000 --cost-mode 4 --corr-kernel 5 5 --median-filter-size 3 --texture-smooth-size 13 --texture-smooth-scale 0.13 --subpixel-mode 3 --stereo-algorithm asp_mgm --skip-low-res-disparity-comp --corr-seed-mode 1 --sgm-collar-size 0 --corr-tile-size 2560 --threads 8 --trans-crop-win 24320 9984 2560 2560

Here is the console log from the logfile

Vision Workbench log started at 2025-11-14 15:03:40.

2025-11-14 15:03:40 {0} [ console ] : Warning: When using a stereo algorithm rather than asp_bm, the default suggested value for texture-smooth-size is 11. Got instead 13.
2025-11-14 15:03:40 {0} [ console ] : Using session: pleiadesmappleiades
2025-11-14 15:03:40 {0} [ console ] : Images before mapprojection: 7573544201.TIF 7573548201.TIF
2025-11-14 15:03:40 {0} [ console ] : Mapprojection cameras: 7573544201.XML 7573548201.XML
2025-11-14 15:03:40 {0} [ console ] : Mapprojected images bundle adjustment prefixes:  
2025-11-14 15:03:40 {0} [ console ] : Mapprojection cam types: pleiades pleiades
2025-11-14 15:03:40 {0} [ console ] : Loading camera model: 7573544201_MP.TIF 7573544201_MP.XML
2025-11-14 15:03:40 {0} [ console ] : Loading camera model: 7573548201_MP.TIF 7573548201_MP.XML
2025-11-14 15:03:41 {0} [ console ] : Warning: Changing the alignment method to 'none' as the images are map-projected.
2025-11-14 15:03:41 {0} [ console ] : Distance between camera centers: 250503 meters.
2025-11-14 15:03:41 {0} [ console ] : --> Using no pre-processing filter with stereo algorithm: asp_mgm
2025-11-14 15:03:41 {0} [ console ] :
[ 2025-Nov-14 15:03:41 ]: Stage 1 --> CORRELATION
2025-11-14 15:03:44 {0} [ console ] : --------------------------------------------------
2025-11-14 15:03:44 {0} [ console ] :    Kernel size:    Vector2(5,5)
2025-11-14 15:03:44 {0} [ console ] :    Search range:   Min: (-84, -445) width: 1 height: 140
2025-11-14 15:03:44 {0} [ console ] :    Cost mode:      4
2025-11-14 15:03:44 {0} [ console ] : --------------------------------------------------
2025-11-14 15:03:44 {0} [ console ] : Writing: full_area_23rds/dem-24576_10240_2048_2048/24576_10240_2048_2048-D.tif
2025-11-14 15:06:17 {0} [ console ] :
[ 2025-Nov-14 15:06:17 ]: CORRELATION FINISHED

[Oleg Alexandrov]

Am I understanding this is referring to a search range originating at (-84, -445) pixels disparity and searching within a window of 1 pixel horizontally and 140 pixels vertically? This seems very weird to me. 

That is what it seems. It is easier to understand these numbers if the input left and right mapprojected images are projected to precisely the same extent with --t_projwin in mapproject (or, they can be cut to the same shared area later, with gdal_translate -projwin). Then, if you overlay them you should be able to see by comparing any observed visual shift with what the correlator program is giving you. 

Then you should see how the final DEM looks like. If it is good, maybe the numbers are fine.

 

band 1 being the horizontal and band 2 being the vertical I think? ).  This map doesn't seem to bear much resemblance to the search range I'm getting so I'm a bit confused. 

These bands also use 0 for no-data values, so a disparity of 0 may mean no-data. If you mapproject as suggested above to the same extent, all these numbers will be around 0 so it will be easier to see.

I do note that the option --skip-low-res-disparity-comp seems to be on, even though I didn't turn this on in my script -- has the low res disparty map been assessed to be not that useful?

This is some internal logic. First, the low-res disparity was computed, and later, when processing each tile, this switch says that the low-res disparity should be used but not recomputed.

Hopefully this will clear something up. 

[Ben Johnson]

Thanks for the rapid reply.

Yeah the disparities are pretty small in the clipped mapprojected images (10 to 20 or so). I think what's happening is that the image is downsampled so much in *D_sub.tif (10m pixels) that the low res disparity is just failing because remaining disparity after mapprojection is comparable to the pixel size of *D_sub.tif. I notice in the clipped areas I've run the *D_sub.tif is much higher resolution, and so the low res disparity map is much more useful. (my full size image is 42224 x 41462 pixels as opposed to clipped area of 1993 x 2079 pixels).

Is there a way to specify the resolution used for low res disparity? I'm guessing not from this https://stereopipeline.readthedocs.io/en/latest/correlation.html#disparity-from-stereo-correlation . 

I guess if the DEM comes out ok this maybe isn't important, but I'm about to do many images in a batch and am looking for ways to speed the process up while maintaining results, and I thought if the search range is much higher than it needs to be then fixing this might get speed savings.

Cheers

Ben

[Oleg Alexandrov]

 I think what's happening is that the image is downsampled so much in *D_sub.tif (10m pixels) that the low res disparity is just failing because remaining disparity after mapprojection is comparable to the pixel size of *D_sub.tif. I notice in the clipped areas I've run the *D_sub.tif is much higher resolution, and so the low res disparity map is much more useful. (my full size image is 42224 x 41462 pixels as opposed to clipped area of 1993 x 2079 pixels).

That can happen indeed with large images. We have several other ways of finding D_sub. See https://stereopipeline.readthedocs.io/en/latest/correlation.html#low-resolution-disparity. Also there it is described how to avoid doing D_sub altogether, and do a custom search range.

 

Is there a way to specify the resolution used for low res disparity? I'm guessing not from this https://stereopipeline.readthedocs.io/en/latest/correlation.html#disparity-from-stereo-correlation . 

Nope, but hopefully the approaches from above will help.

 

I guess if the DEM comes out ok this maybe isn't important, but I'm about to do many images in a batch and am looking for ways to speed the process up while maintaining results, and I thought if the search range is much higher than it needs to be then fixing this might get speed savings.

You can also use the option --max-disp-spread to ensure that no matter what the disparity range does not exceed your budget. A good value for this may be 150 or so (or 200, if you want to simply cut off the worst excesses). Much depends on how steep your terrain is and how well the low-res DEM you use for mapprojection agrees with your final results.

[Ben Johnson]

I'm guessing using a DEM for disparity doesn't make sense when the only DEMs I have are the one I used for mapprojection and the result of the stereo process? Or is the idea that you take the unsmoothed mapproject DEM to estimate the disparity? (I used ALOS with a 2 sigma blur applied using dem_mosiac for my mapprojection).

I think --max-disp-spread might be the thing. I've got some cliffs which will no doubt be quite large but it's not practical for me to hunt each image for the maximum disparity to set the search range manually, so keeping it from being very large might might be the thing and perhaps just turning off low resolution disparity. I might fiddle with sparse_disp if this approach fails. 

Thanks!

[Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]]

>I'm guessing using a DEM for disparity doesn't make sense when the only DEMs I have are the one I used for mapprojection and the result of the stereo process? Or is the idea that you take the unsmoothed mapproject DEM to estimate the disparity? (I used ALOS with a 2 sigma blur applied using dem_mosiac for my mapprojection).

Yeah, likely the unsmoothed one would work better for estimating the disparity, assuming it is not wildly off relative to the final DEM you will get. 

My point is that it may be worth trying if you believe the regular D_sub approach is simply not working.  This approach may be of value particularly for vegetation or when there is a lot of snow with no features.

I think using a smoothed vs unsmoothed DEM for disparity initialization won't make much of a difference, if you set the --disparity-estimation-dem-error to 50 meters or so (but it depends on the ALOS resolution of course). 

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Ben Johnson <bwwjo...@gmail.com>
Sent: Friday, November 14, 2025 10:58 AM
To: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] [BULK] Re: Questions about search range

 

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/9a7a78fa-023e-4e73-9223-fb09a34c3c2dn%40googlegroups.com.

[Ben Johnson]

Could you clarify, I don't understand how using the DEM I used for mapprojection aids in estimating the search range. My understanding is that mapprojection is designed to *remove* disparity from the raw image, and that stereo on mapprojected images is searching for the remaining disparity that wasn't removed by mapprojection. So how can the DEM used for mapprojection contain any information about the remaining disparity in the mapprojected image, and so how does it tell us where / how big the search range should be? 

I'll give it a try anyway but I'm keen to understand why this might work.

[Oleg Alexandrov]

Could you clarify, I don't understand how using the DEM I used for mapprojection aids in estimating the search range. My understanding is that mapprojection is designed to *remove* disparity from the raw image, and that stereo on mapprojected images is searching for the remaining disparity that wasn't removed by mapprojection. So how can the DEM used for mapprojection contain any information about the remaining disparity in the mapprojected image, and so how does it tell us where / how big the search range should be? 

Yeah, I guess using the DEM for mapprojection for estimating the disparity based on mapprojected images is broadly equivalent to simply skipping the D_sub computation altogether and setting a custom search range with --corr-search (once left and right images are mapprojected to the same extent). That because increasing --disparity-estimation-dem-error, which is meant to compensate for your input DEM not being in full agreement with the images (which handles the remaining disparity) is about the same as increasing the width and height of the search range.

Using a DEM for finding initial D_sub disparity is more helpful with non-mapprojected images.