Terrain flattening co-registered images

[lundj17]

I am running into trouble performing Radiometric Terrain Flattening on co-registered images, wondering if anyone else has run into (and has a solution to) this problem?

My images are first calibrated to beta0 and co-registered, but when I continue in the processing chain to terrain flatten the image with two beta0 bands (a master and slave), the output image has a singular gamma0 band, with no indication if it is based on the master or slave input band.

Anybody familiar with this?

[ABraun]

Wouldn’t it make more sense to coregister after flattening?

[lundj17]

Thank you @ABraun for the input. Co-registration after multi-looking and terrain flattening still results in minimal residuals.

[ABraun]

are the bands still empty if co-registering is performed last?

[lundj17]

I may not understand your question; originally my issue was in terrain flattening co-registered images with multiple beta_0 bands. This process would produce a single gamma_0 band, and didn’t indicate if it was a flattened image of one of the bands or a combination of the bands.

Terrain flattening prior to co-registration solves this problem, and thankfully produces minimal residuals.

As the best DEM’s I have access to for this region are the S1-tbx available SRTM or ASTER, I still must multi-look before terrain flattening, which is more processing than I would prefer prior to co-registration.

[ABraun]

Disable the re-grid option and you can flatten without multi-looking.

[art23130]

I have also tried terrain flattening prior to co-registration but still I have missing bands in the outcome image, I think it is the problem of the stacking phase in co-registration because when I stack the images using create stack option I have the same error.

In this topic I have shown the error

Create Stack error in filter images

I have applied these steps in order to process the data: Thermal noise removal Apply Orbit file Calibration to Beta0 MultiTemp filtering Radiometric terrain flattening --- SRTM 1Sec HGT (Auto Download) Sub-setting the images Coregistration --- here is the problem!!!!!!!!! Range Doppler Terrain Correction --- it would be the next step I have attached the outcome of the stack. [image]

[junlu]

It looks like the current Terrain Flattening code has some problem in handling target product band names. We will fix it. Thank you all for pointing it out.

[junlu]

The problem has been fixed.

[art23130]

Thanks for the update. Is it in the new version?

[junlu]

It should be in the next release (somewhere in June)

[lundj17]

Thanks for your responses, @ABraun.

When I disable the re-grid option, at least using the SRTM 1 arc-second DEM, my resulting image is replete with blank sections, as shown below:

Terrain flattened image before multi-looking, re-grid option unchecked

Same terrain-flattened image, with multi-looking and terrain correction performed

I’ll explore now whether I see the same effect using the ASTER GDEM. Has anyone else run into this issue?

[ABraun]

it could be that artefacts in the DEM cause strange holws. Would be worth a try with the ALOS World DEM
http://www.eorc.jaxa.jp/ALOS/en/aw3d30/index.htm

[lundj17]

I don’t believe the blank sections are due to DEM artifacts. Below are similar results with the ASTER GDEM and ALOS DSM:

ASTER

ALOS

FWIW, the SRTM 1 arc second DEM performs generally quite well when multi-looking is performed before terrain flattening. Have you experienced otherwise in your processing?

[ABraun]

Have you experienced otherwise in your processing?

reminds me of this

Change detection and ratio

Hi all Screenshot of my processing for make terrain correction of ALOS PALSAR images with SAR Mosaic in SNAP, I don't believe that geometric distortion was corrected!!! I have doubt Left: image with SAR mosaic, Right: Image without SAR mosaic [image] [image]

Here, also small DEM errors caused large faulty areas.