stereo with 'map-ready' maxar products?

[Christophe Kinnard]

Helllo,

I know that Ames is not meant to work with OR2A Maxar orthorectified map products, but what about OR2A products that are map projected to a constant (base) elevation but not orthorectified?

I have two wordlview2 images projected to constant elevation and the RPC model in .rpb files for both left/right images.

While calling stereo I get the warning: 

Warning: It appears that the input images are map-projected. In that case a DEM needs to be provided for stereo to give correct results.

I am unsure how to provide the DEM in the stereo command line, I could not find exemples. The documentation seems to suggest this should be done if the images were projected onto the DEM, but they were not, they are projected to a constant elevation.

Should I use map_project beforehand?

I there a way forward with this data?

Thanks!

-Christophe

[Oleg Alexandrov]

We have documentation for how to run stereo with mapprojeted images at: https://stereopipeline.readthedocs.io/en/latest/next_steps.html#running-stereo-with-mapprojected-images

The mapprojection DEM has to be the last argument. In your case, it can be faked, by taking some DEM of the area, and its elevation can be made to be constant. That can be done with our image_calc tool, with a command such as:

image_calc -c "0*var_0 + height" input_dem.tif -o output_dem.tif -d float32

(or something like that). Your height needs to be substituted above. The doc for this tool is here: https://stereopipeline.readthedocs.io/en/latest/tools/image_calc.html

We also assume the left and right mapprojected images are at the same ground resolution. They can be brought to the same resolution with gdalwarp, a GDAL tool that we ship. It is suggested to use it with bicubic interpolation.

I am not sure how well this would work, but likely you will get some plausible terrain.

--
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/CAGdkLUtDV7tw2GwmChmV27ZSfD%3Dnu5reqn1-O2ArCJ%3DUVG79ew%40mail.gmail.com.

[Christophe Kinnard]

Thanks Oleg for the feedback.

I have produced a DEM ('fakedem.tif') with a constant elevation set to the base elevation the images were projected to (2582.54 m above ellipsoid), all images and dem have the same resolution (0.3m)

I am getting the warning: Warning: Missing field value for: CAMERA_MODEL_TYPE in 12august_left.tif.

Warning: Assuming mapprojection was done with camera type: rpc.

I did not enter the .RPB files containing the RPC model, as it was suggested not to in the documentation: 

"For some cameras the RPC coefficients are stored in separate files ending in .RPB or _RPC.TXT (or in lower-case). These will be loaded automatically and should not be specified in the stereo command."

https://stereopipeline.readthedocs.io/en/latest/examples/rpc.html#rpc

But it seems to me that they are not read and that parallel_stereo expects embedded information in the tif?

Here is the command I am using for now (I intend to change the subpixel mode and alignment method later)

parallel_stereo -t rpc \

  --stereo-algorithm asp_mgm \

  --subpixel-mode 9 \

  --alignment-method none \

  --sgm-collar-size 256 \

  12august_left.tif 12august_right.tif \

   output/12august \

   /mnt/e/ames/fakedem.tif  

Christophe

[Oleg Alexandrov]

I am glad there is a little bit of progress. My apologies you are hitting issues, I did not encounter before the case of rpc images, and forgot you mentioned that. (Normally we work with maxar xml files.)

You can try to see what happens if you copy your .rpb files as 12august_left.rpb and 12august_right.rpb. Maybe they will be picked up. Looks that way, based on this: https://gdal.org/en/stable/drivers/raster/gtiff.html

This is all quite experimental. We do not really support ortho products and I think we should, but it was never a high enough priority.

If there is no luck, let me know. Hoping something usable will come out.

[Shashank Bhushan]

Hi Christophe,

If on running gdalinfo on the Maxar images, you get the RPC info printed, then you should be fine without specifying the actual RPC file. If it does not print the RPC information, please specify the left and right RPC XML files in addition to the left and right images.

Also, while the tool reads it by default, you should specify rpcmaprpc as the stereo session.

We and the tool can only guess if RPC was used for the internal orthorectification, as the vendors might have used a rigorous model internally for orthorectification.

Let's see how the results look :)

Cheers,

Shashank

On Wed, Nov 27, 2024 at 7:38 PM Christophe Kinnard <christoph...@gmail.com> wrote:

Thanks Oleg for the feedback. I have produced a DEM ('fakedem. tif') with a constant elevation set to the base elevation the images were projected to (2582. 54 m above ellipsoid), all images and dem have the same resolution (0. 3m) I am

ZjQcmQRYFpfptBannerStart

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

See https://itconnect.uw.edu/email-tags for additional information. Please contact the UW-IT Service Center, he...@uw.edu 206.221.5000, for assistance.

 

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/CAGdkLUtL%2Br%3DbVPY%2BrnCk%3D1%3Dn9vw8f-Hq93eo7W_BvTqTfm_%3DTQ%40mail.gmail.com.

--

Shashank Bhushan, PhD 

Postdoctoral Scholar

Civil & Environmental Engineering

University of Washington, Seattle

Pronouns: (he/him/we)

https://shashankbice.github.io/ 

https://uw-cryo.github.io/authors/shashank/

[Oleg Alexandrov]

So you got two responses, hopefully something works out.

[Christophe Kinnard]

Hello,

Seems that the RPC are embedded within the image geotif files (see below), but stereo is looking for the fields 'CAMERA_MODEL_TYPE' and  'CAMERA_FILE', which are missing in the tif. When inputting the RPB files for both images they seem to be read (see log below), so it seems to be working... I get quite a bit of holes in the DEM though... I will experiment with different settings. I have used 'alignment-method none' to speed up test. Should I use epipolar / local_epipolar as suggested in the documentation?  Also, can/should I intent bundle block adjustment on these map projected images?

Thanks for your support,

-Christophe

GDAL INFO RPC metadata:

RPC Metadata:
ERR_BIAS=3.52
ERR_RAND=0.15
HEIGHT_OFF=2443
HEIGHT_SCALE=943
LAT_OFF=52.1358
LAT_SCALE=0.0430
LINE_DEN_COEFF=+1.000000E+00 -2.830830E-07 +3.626125E-04 +5.046181E-05 -9.337583E-07 +1.677669E-05 -8.625387E-07 +1.187815E-06 -1.101272E-07 -1.127009E-05 -5.314926E-07 +5.898776E-06 -2.593369E-06 -7.477209E-07 -2.528807E-07 +4.565965E-07 -2.652133E-07 -2.335376E-07 -1.175066E-06 -4.285786E-07
LINE_NUM_COEFF=+7.289193E-04 +4.323237E-03 -1.011771E+00 -1.427371E-02 -9.266505E-07 +5.157691E-05 +3.904565E-05 -7.374992E-04 -3.709201E-04 +6.024102E-07 -1.690561E-05 +1.199194E-06 -4.414834E-07 -6.845913E-07 -9.310657E-07 -1.243949E-06 +1.097745E-05 +7.979335E-06 +3.620282E-07 -3.597216E-07
LINE_OFF=14764
LINE_SCALE=15757
LONG_OFF=-117.2524
LONG_SCALE=0.0860
SAMP_DEN_COEFF=+1.000000E+00 +1.507543E-03 +4.950311E-04 -8.986398E-04 +4.971578E-07 -2.018347E-07 +2.246451E-06 +1.994643E-06 -8.004812E-06 -8.406684E-06 +0.000000E+00 +2.048120E-07 +2.154434E-08 +3.541514E-08 +7.843971E-07 -2.127564E-07 -1.650239E-07 +1.805889E-07 -2.847852E-07 -2.505442E-07
SAMP_NUM_COEFF=-2.987931E-03 +1.040761E+00 +2.993386E-03 -4.105353E-02 -4.822699E-04 +7.455558E-04 -3.819315E-04 +1.570177E-03 +2.369812E-06 -3.087246E-05 +2.057156E-06 +1.814655E-06 -8.945190E-06 -7.556122E-06 -9.711461E-07 +1.007241E-07 -3.022553E-07 +6.090245E-08 +3.360176E-07 +4.320488E-07
SAMP_OFF=18286
SAMP_SCALE=18847
Corner Coordinates:
Upper Left ( 487120.800, 5780595.300) (117d11'18.04"W, 52d10'32.46"N)
Lower Left ( 487120.800, 5775680.100) (117d11'17.37"W, 52d 7'53.37"N)
Upper Right ( 488385.000, 5780595.300) (117d10'11.48"W, 52d10'32.56"N)
Lower Right ( 488385.000, 5775680.100) (117d10'10.88"W, 52d 7'53.48"N)
Center ( 487752.900, 5778137.700) (117d10'44.44"W, 52d 9'12.97"N)

stereo_pprc log:

2024-11-27 23:07:45 {0} [ console ] : Using session: rpcmaprpc
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: CAMERA_MODEL_TYPE in 12august_left.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Assuming mapprojection was done with camera type: rpc.
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: INPUT_IMAGE_FILE in 12august_left.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Using: 12august_left.tif instead.
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: CAMERA_FILE in 12august_left.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Using: 12august_left.rpb instead.
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: DEM_FILE in 12august_left.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Using: /mnt/e/ames/fakedem.tif instead.
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: CAMERA_MODEL_TYPE in 12august_right.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Assuming mapprojection was done with camera type: rpc.
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: INPUT_IMAGE_FILE in 12august_right.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Using: 12august_right.tif instead.
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: CAMERA_FILE in 12august_right.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Using: 12august_right.rpb instead.
2024-11-27 23:07:45 {0} [ console ] : Warning: Missing field value for: DEM_FILE in 12august_right.tif.
2024-11-27 23:07:45 {0} [ console ] : Warning: Using: /mnt/e/ames/fakedem.tif instead.
2024-11-27 23:07:45 {0} [ console ] : Mapprojected images bundle adjustment prefixes:  
2024-11-27 23:07:45 {0} [ console ] : Mapprojection cameras: 12august_left.rpb 12august_right.rpb
2024-11-27 23:07:45 {0} [ console ] : Mapprojection cam types: rpc rpc
2024-11-27 23:07:45 {0} [ console ] : Loading camera model: 12august_left.tif 12august_left.rpb
2024-11-27 23:07:45 {0} [ console ] : Loading camera model: 12august_right.tif 12august_right.rpb
2024-11-27 23:07:45 {0} [ console ] : Distance between camera centers in meters: 55746.6.
2024-11-27 23:07:45 {0} [ console ] : Image files:  12august_left.tif, 12august_right.tif
2024-11-27 23:07:45 {0} [ console ] : Camera files: 12august_left.rpb, 12august_right.rpb
2024-11-27 23:07:45 {0} [ console ] : Input DEM: /mnt/e/ames/fakedem.tif

[Christophe Kinnard]

reading more of the documentation I see these two options for the stereo session with map projected images:

• dgmaprpc / dgmapdg

• rpcmaprpc

Since my images are Digital Globe (maxar), should I better use one of dgmaprpc or dgmapdg, instead of rpcmaprpc? I could not find precise guidelines on theses...

-Christophe

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

The dgmaprpc / dgmapdg sessions are more of a hint of what type of cameras are being picked up, there is no difference internally. This is very briefly mentioned on the parallel_stereo doc page.

> 'CAMERA_MODEL_TYPE' and  'CAMERA_FILE', which are missing in the tif. When inputting the RPB files for both images they seem to be read (see log below), so it seems to be working... 

These warnings can also be ignored. That is because we are trying to fake things here, and the usual metadata is missing but that is fine.

>I get quite a bit of holes in the DEM though..

Do you at least get some meaningful terrain where there are no holes? Such as in elevations being roughly correct? The program does better where there is more features in images. Then, with point2dem, one should not make the grid too coarse.

It is also good to overlay your input left and right image in a GIS program and see if they make sense and if the surface coverage is good.

>  I will experiment with different settings. I have used 'alignment-method none' to speed up test. Should I use epipolar / local_epipolar as suggested in the documentation?  

With mapprojected images your only option is no alignment.

>Also, can/should I intent bundle block adjustment on these map projected images?

Bundle adjustment cannot be used with mapprojected images. It is likely not necessary in either case, as Maxar data is quite good as it is.

Sorry this is a bit of a pain. This is not our usual mode of operation.

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Christophe Kinnard <christoph...@gmail.com>
Sent: Thursday, November 28, 2024 7:09 AM
To: Shashank Bhushan <sbag...@uw.edu>
Cc: Oleg Alexandrov <oleg.al...@gmail.com>; Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] [BULK] Re: stereo with 'map-ready' maxar products?

 

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.

To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/CAGdkLUv2e0ia4sG7y1LtopFCCPBhKw%2B%3Dksm_Cm4Qpu4TnVkE4w%40mail.gmail.com.

[Christophe Kinnard]

Hello,

'Do you at least get some meaningful terrain where there are no holes? Such as in elevations being roughly correct? The program does better where there is more features in images. Then, with point2dem, one should not make the grid too coarse.'

=> yes, the resulting DEM seems correct, well aligned and representing the main features visible on the images. The only problem I see is that there are holes in some areas that to me appear to have good contrast. It is on a glacier, and the holes seem to be on the darker moraines. I am trying to increase the corr-search distance. Does that make sense, or do you have other suggestions? For now I am outputting the DEM at the resolution of the images (0.3m, I know I should at least double this)

Best,

-Christophe

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

Glad at least the program is doing something meaningful.

Looks like you are using the asp_mgm algorithm, which is the best we got. 

> The only problem I see is that there are holes in some areas that to me appear to have good contrast. It is on a glacier, and the holes seem to be on the darker moraines.

If the moraines are featureless, that may result in holes. 

You can also try our asp_bm algorithm. That one may not be so detailed but may handle better the large difference in contrast. To speed things up, it can be tried on some crops of the orthoimages around those moraines. 

---

From: Christophe Kinnard <christoph...@gmail.com>
Sent: Friday, November 29, 2024 6:05 AM
To: Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC] <oleg.al...@nasa.gov>
Cc: Shashank Bhushan <sbag...@uw.edu>; Oleg Alexandrov <oleg.al...@gmail.com>; Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: Re: [EXTERNAL] [BULK] Re: stereo with 'map-ready' maxar products?

 

[Shashank Bhushan]

Does that make sense, or do you have other suggestions? For now I am outputting the DEM at the resolution of the images (0.3m, I know I should at least double this)

> The number of holes will also decrease once you use a grid size 3 to 4 times the input image resolution. So try a resolution of 1 to 2 m in point2dem. There is guidance on this on the document, and several discussions on the mailing list to use a grinding resolution, which is 3 to 4x the input image resolution for best results, balancing the resolution, noise, and holes in the DEM.

[Christophe Kinnard]

Dear all,

I am getting a suitable DEM out of my map-projected Maxar images. I solved the hole problems by increasing the collar size to 512 pixels in the parallel stereo function. However, I am trying to get as much fine-scale details as possible, as I want to derive roughness metrics, and the small scale features are quite smoothed in my DEM. I have tried with subpixel-mode 3, and now experimenting with the much longer subpixel-mode 2.

Are there other parameters that you recommend to reduce the smoothing and recover more fine-scale details? I went over the options in stereo.default. Should any parameters in the filtering step (or other step) be changed? (eg: texture-smooth-scale, but I am unsure as it depends on 'texture-smooth-size' and rm-cleanup-passes').

Here is my current call to stereo-algorithm

parallel_stereo -t rpcmaprpc  \
  --stereo-algorithm asp_mgm   \
  --corr-kernel 5 5 \
  --sgm-collar-size 512 \

  --subpixel-mode 3  \
  12august_left.tif 12august_right.tif \
  12august_left.rpb 12august_right.rpb \
  output/12august  \
  /mnt/e/ames/fakedem.tif 

Thanks for your support,

-Christophe

[Oleg Alexandrov]

Fine-level detail is hard to get with stereo. It always smoothes over things, somewhat, as it uses a correlation window.

You can try to use  --corr-kernel 3 3, maybe. 

> texture-smooth-scale, but I am unsure as it depends on 'texture-smooth-size' and rm-cleanup-passes')

I guess you can try experimenting a bit by changing one parameter and seeing the effect. One can cut a small clip (512 pixels) on which this can be fast.

For fine-level roughness, maybe frequency analysis in the images may help, after mapprojecting them onto the local DEM. 

[Christophe Kinnard]

 strangely when I call the previous function with a crop window of about 800-1000 pixels wide, to make quick tests with different settings, I get this error:

Warning: Unable to compute valid search ranges for SGM input. Increase --corr-memory-mb.

        --> Low-resolution disparity:[*******************************] Complete!
Low-resolution disparity computation took 75.2474 s.
Filtering outliers in D_sub based on --outlier-removal-params.


ERROR: Empty disparity.

I tried changing the --corr-tile-size to make it match the width/height of the image, or to make it smaller or bigger, but I get the same error. I increased --corr-memory-limit-mb to 80000, no result neither.

When I changed back the width and height of the crpo window to 2048 it worked (with   --corr-tile-size 6400 \) ..?: Any ideas...?

# Run Ames Stereo Pipeline with asp_mgm settings

parallel_stereo -t rpcmaprpc  \
  --stereo-algorithm asp_mgm   \

  --subpixel-mode 3  \
  --left-image-crop-win  1484 11634 800 800 \
  --right-image-crop-win  1484 11634 800 800 \

  --corr-kernel 5 5 \
  --sgm-collar-size 512 \

  --cache-size 18432 \
  --threads-multiprocess 2 \
  --corr-tile-size 6400 \
  --corr-memory-limit-mb 80000 \

  12august_left.tif 12august_right.tif \
  12august_left.rpb 12august_right.rpb \
  output/12august  \
  /mnt/e/ames/fakedem.tif  

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

This is a sign of filtering of disparity failing. Maybe your input clips lack data? Not sure.

You can try turning off the disparity filtering step by setting --outlier-removal-params 100 3 (the first value is now 100%, so nothing will be filtered). (https://stereopipeline.readthedocs.io/en/latest/stereodefault.html)

This is the second time recently users ran into problems in filtering so I put a small fix in the code to just give up on filtering if something's not working out. This won't help you now but will be in the build for tomorrow.

---

From: Christophe Kinnard <christoph...@gmail.com>
Sent: Thursday, December 12, 2024 10:10 AM
To: Oleg Alexandrov <oleg.al...@gmail.com>
Cc: Shashank Bhushan <sbag...@uw.edu>; Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC] <oleg.al...@nasa.gov>; Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>

[Oleg Alexandrov]

You also need to ensure the input clips overlap. We have the stereo_gui tool that can be invoked with the same options as parallel_stereo and allows for selection of clips and then running on them from the menu. https://stereopipeline.readthedocs.io/en/latest/tools/stereo_gui.html

[Christophe Kinnard]

yes, that is what I use to select my clip... and putting the outlier filter to 100% doe not change. Strangely when putting my crop window to rectangular instead of square the script runs... but it could also be a size threshold, not sure...

 --left-image-crop-win 658 11112 1948 1786 \
  --right-image-crop-win 658 11112 1948 1786 \

But in fact my results are only partial (pixel quality map):

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

Not sure what is going on. You can compare what you see selected in the left and right image in the gui, with the L.tif and R.tif saved in that run directory. 

If the input images have a systematic shift if overlaid, that may have an effect, as internally the tool crops both to a shared spatial extent.

---

From: Christophe Kinnard <christoph...@gmail.com>
Sent: Thursday, December 12, 2024 12:46 PM
To: Oleg Alexandrov <oleg.al...@gmail.com>
Cc: Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC] <oleg.al...@nasa.gov>; Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>

[Christophe Kinnard]

I get it, the overlap is much smaller than the extent of the crop....so even with a large collar size there is no more data to search into...