Using ASP with PlanetScope images

[Talfan Barnie]

Hello all,

I'm trying to extract DEMs from PlanetScope images using ASP 2.60 in order to estimate the thickness of lava flows. For this I'm using the RPCs that come with the basic data product. For my experiments I've been using a test pair of images acquired on neighbouring tracks on successive days - see attachment (planetscope_image_extents.png - image extents outlined in red). Both images are nadir looking (I believe). 

I've been experimenting with different workflows, and it seems that semi global matching gives the best results. However the resulting DEM has steps, or oscillations in it that roughly follow contours in the topography- see attachment steps.png - the resulting DEM is overlain in greyscale on the images and the red line shows the location of cross section below, red profile is from PlanetScope DEM, green profile from SRTM.

I've began to experiment with changing a few settings, but I haven't had any success so far. Given there are a lot of options I was wondering if anyone has seen this artefact before and can point me in the right direction to fix it?

Thanks for your help!

Best wishes,

Talfan

[Scott McMichael]

One thing that can cause step artifacts is the subpixel correlation step in SGM.  If you look at the contents of -RD.tif stereo output file (use gdal_translate -b N to extract the x and y disparity components) do you see a similar step pattern?

The next thing I would suspect is that there may be a problem related to the RPC stereo model.  Try generating the error image during the point2dem step (using --errorimage) and see if you find the step pattern in the error numbers.

Once we isolate where the problem is coming from we can try to come up with a fix =)

Scott

PS: I don't think this will change the artifacts but you may want to try using the latest development build.  There have been a lot of improvements to the SGM implementation since our last release:  https://byss.arc.nasa.gov/stereopipeline/daily_build/StereoPipeline-2.6.0-2017-12-22-x86_64-Linux.tar.bz2

[Talfan Barnie]

Hi Scott,

Many thanks for your reply!

I re-ran everything with the latest development build as you suggested, and the steps are still there in the final DEM. You can see the steps very faintly in the x disparity component (-RD_band1.png), but they're not really present in the y component (-RD_band2.png).  They look pretty prominent in the intersection error, along with perpendicular features which give a kind of checkerboard pattern (intersectionErr.png). Might this mean the RPCs are likely the problem?

Best wishes,

Talfan

[Alexandrov, Oleg (ARC-TI)[SGT, INC]]

Howdy, 

I looked at all the data, and, both Scott and me tend to believe something is funny with the RPC model. RPC is usually an approximation, and if I am not mistaken, I see a very strong systematic effect in the intersection error (it would be easier to see if this error were colorized, using the colormap model). Hence, I think there are are areas where this model does not approximate things very well. 

I saw such behavior (if not looking quite like this) for ASTER a while ago. 

I must say the fact that these data comes from Planet (formerly PlanetLabs) does not inspire confidence. This is low-cost data provider using cheap cameras, I would doubt they did the homework as well as say Digital Globe would.

I could suggest you read more into their doc, or try to get images from another source (ASTER could also work, some of their imagery is free I think, and our tools work well with it if the exact model is used and not RPC).

Taking the very long term, it is possible to write code to correct the RPC model, especially given that there is an underlying SRTM, but that would be a lot of work.

Oleg

---

From: ames-stereo-pi...@googlegroups.com [ames-stereo-pi...@googlegroups.com] on behalf of Talfan Barnie [talfan...@gmail.com]
Sent: Tuesday, December 26, 2017 10:57 AM
To: Ames Stereo Pipeline Support
Subject: Re: Using ASP with PlanetScope images

--
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 on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/a0e33bd6-2512-4364-a7d9-1d8453282922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexandrov, Oleg (ARC-TI)[SGT, INC]]

As another thought, our bundle_adjust may be able to help you to reduce the systematic error. I don't think it will make it go away, but may get better, or at least re-distribute it somewhat.

Oleg

---

From: ames-stereo-pi...@googlegroups.com [ames-stereo-pi...@googlegroups.com] on behalf of Alexandrov, Oleg (ARC-TI)[SGT, INC] [oleg.al...@nasa.gov]
Sent: Tuesday, December 26, 2017 5:15 PM
To: Talfan Barnie; Ames Stereo Pipeline Support
Subject: [non-nasa source] RE: Using ASP with PlanetScope images

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/0C9898C7EDFD7A4FBCEF4F6C5D11E3502F02D825%40NDJSMBX101.ndc.nasa.gov.

[Talfan Barnie]

Hi Oleg and Scott,

Many thanks for having a look, and for your helpful suggestions! I thought it might be a bit of a long shot, but the images have such great resolution and the satellite such a short revisit time I had to try ...

I've conducted a few experiments applying bundle adjustment before running stereo, and this is as far as I have got:

(1) Applying bundle adjustment to both images without GCPs - no improvement

(2) Applying bundle adjustment to 7 overlapping PlanetScope images without GCPs (I figured this might give a better constraint on the results?), and then generating the DEM form the same pair as before - no improvement

(2) Applying bundle adjustment with GCPs - I wasn't able to use the stereo_gui program to generate GCPs because I get the error "symbol lookup error: /usr/lib/x86_64-linux-gnu/libgnomevfs-2.so.0: undefined symbol: g_mutex_lock" whenever I tried to export them. However I managed to hack together an automated GCP generation procedure using the AROSICS python library to match points on the PlanetScope images with common points on an orthorectified WorldView image, and use that to get the lat lon and height of each point from a high resolution worldview DEM. The points seem ok, at least by visual inspection. They cover a small area, but I'm only interested in measuring lava flow thickness in a small region, so I thought maybe it would be enough to correct the systematic error locally (perhaps at the expense of a worse result elsewhere?). The distribution of GCPs is shown in the attached gcps_from_arosics.png - two images on the left panel show the GCPs superimposed the stereo images loaded from the GCP file I created with my script, the right hand image the orthorectified WorldView reference image. However, the resulting DEM doesn't look so good - there seems to be a systematic offset between the WorldView reference DEM and the PlanetScope one (see dem_profiles.png - blue profile is the reference DEM, red profile is the PlanetScope DEM) - should the bundle adjustment procedure result in an alignment if the GCPs are good?

But maybe ASTER is a better bet, at least in the short term - I've downloaded some images, and will have a go ...

Thanks again for all your help,

Talfan

Howdy, 

To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline-support+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/a0e33bd6-2512-4364-a7d9-1d8453282922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-support+unsub...@googlegroups.com.

[Talfan Barnie]

Hi Oleg and Scott,

Just to follow up on this, I heard back from Planet who inform me the typical base to height ratio of 1:20 for PlanetScope image pairs precludes using them for DEM generation anyway.I was wondering if there are any guidelines for what rage of base to height ratios are worth trying with ASP?

Many thanks for your help!

Best wishes,

Talfan

[Alexandrov, Oleg (ARC-TI)[SGT, INC]]

Talfan,

The accuracy of stereo degrades continuously with smaller base to height ratio, so it is hard to give a number. See here a longer text: https://robotics.stackexchange.com/questions/896/how-to-select-cameras-for-a-stereo-vision-system

The ratio 1:20 seems a bit bad. I don't know what a good ratio is, maybe 1:5 or better? 

Normally the satellite operator should know these. Their documentation may say things about their stereo accuracy, etc.

Oleg

---

From: ames-stereo-pi...@googlegroups.com [ames-stereo-pi...@googlegroups.com] on behalf of Talfan Barnie [talfan...@gmail.com]

Sent: Saturday, January 13, 2018 8:38 AM

To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/5cf318de-37cc-41af-ab67-ee19cf61a25c%40googlegroups.com.