Thanks! I will test the code release in that case. I am not sure the striping is the same as what I have noticed earlier (regular straight striping across range), but that’s something to find out. Your striping sounds less problematic.
Guido
It looks like there are still problems with the radiometric terrain flattening in SNAP that the upcoming release will not solve. I hope we can work together with @eyeinsky to find out where our implementation goes wrong.
1 Like
About that, because I don’t understand all, I would like to know if the terrain flattening will integrate the correction between sub swath and also due between the different incidence angle ?
Indeed, divided every line by the average of every line works well buts it’s complicated to apply that because all data are not homogeneous.
Best.
I did a couple of tests with the Beta 8 compiled version. I found that terrain flattening is different from before, but still not the same as what @eyeinsky generates. The cross-range striping is no longer present, even when processing with SRTM 1Sec HGT. The order of steps is still important (e.g. ML -> TF is different from TF -> ML). I can run the full processing chain in one go (Border Noise Removal -> Calibration -> ML -> TF -> TC) and all seems to be a little faster than before.
So, progress, but we’d be very interested if results would converge.
Guido
Nice news.
However, I don’t know if it’s possible to share beta 8 because I don’t know how to compile it ?
Best
I understand Beta 8 is to be released this week, before the hackathon at ESRIN (15 & 16 Sept.)
yep, Luis Veci @lveci also said that on is communication, the next Beta it would be closely released. At min 16.
http://livestream.com/ESA/eoscience/videos/101790018
About sharing the SNAP build, it’s free open source, just be sure you’ll be sharing the same specs (win/unix, 32bits/64bits)
We’re getting there but it’s still not perfected
Luis,
As a follow up on the terrain flattening issue, are there plans to correct the procedure so that it is in line with David Small’s algorithm?
Guido
We don’t have plans to revisit this yet.
@lveci and @mengdahl : Can you update us on the TF algorithm status?
Does it worth to invest and use it ?
1 Like
Continuing on this topic which might be the main reason to keep SNAP for processing (and not moving to GEE GRD collection).
I tested the impact of two factors on the resulting Gamma0 : 1) starting from SLC or GRD base product 2) with or without TF.
Equivalent source products used :
SLC : S1A_IW_SLC__1SDV_20150821T055817_20150821T055844_007357_00A1B9_4D44.zip
GRD : S1A_IW_GRDH_1SDV_20150821T055818_20150821T055843_007357_00A1B9_0046.zip
I tested 4 processing chains using SRTM 1s (30m) on SNAP v4.0.1 + S1TBX 4.0.0 :
- <GRD> -> Orbit -> Cal -> Thermal -> TC -> <Gamma_GRD_noTF>
- <GRD> -> Orbit -> Cal -> Thermal -> TF -> TC -> <Gamma_GRD_TF>
- <SLC> -> Orbit -> Cal -> Thermal -> TOPSAR-deburst -> Multilook (5x1) -> TC -> <Gamma_SLC_noTF>
- <SLC> -> Orbit -> Cal -> Thermal -> TOPSAR-deburst -> Multilook (5x1) -> TF -> TC -> <Gamma_SLC_TF>
Here is the resulting Gamma0 VH distributions along a random profile of 10 km across the scene (y in percent) :
or in dB:
The only processing chain showing an effect of the TF is the one starting from SLC product ! In all the other cases, we yield about the same result.
@eyeinsky : David, can you try your test again but starting from a SLC product on SNAP ?
+(It doesn’t look like there is striping any more)
3 Likes
Sorry for the delayed response - I was away on vacation.
That surprises me that SLC vs. GRD should not give consistent results. Can you please specify which version of SNAP you were using?
I’m using SNAP v4.0.1 + S1TBX 4.0.0. Thank you for looking at this !
Before TF one should prepare a Cal Beta_Nought, not a Cal Gamma_Nought. That may explain part of the lack of correspondence between the histograms. i.e. one should compare gamma_GRD_noTF with beta_GRD_TF, not with gamma_GRD_TF.
The TF tool is renaming the Beta_Nought into Gamma_Nought, so I considered gamma_GRD_noTF and gamma_GRD_TF. Maybe one should compare beta_GRD_noTF and gamma_GRD_TF?
Yes, after TF, the output is terrain-flattened gamma nought, so that is correct. But as an input to TF, one should provide a radar geometry image in the backscatter convention beta nought, not gamma nought.
Hi @mengdahl, hi all,
I am trying to correct for terrain using the Terrain Flattening operator and Range Doppler Terrain Correction. However results after Terrain Flattening are highly unsatisfactory (s. Screeshots). I wonder if this is (still) a issue of the algorithm or if there is a way to improve the output.
I´m working on Win10 64bit, Snap 6.0 Beta, Example dataset: S1B_IW_GRDH_1SDV_20170110T095447_20170110T095512_003784_00681B_B4AB.SAFE (Chilean Andes)
I use a gap filled TanDEM-X DEM (doesnt cover the whole radar scene) so I doubt that the issue is within the DEM (Projection UTM 19S, resampled to 10m with bilinear; also tried WGS84 Lat/long).
I applied (and varied) the following pre-processing steps: Thermal Noise Removal >Apply Orbit File > Calibrate to beta > (Subset) > Speckle Filter >Terrain Flattening > Terrain Correction
– Calibrated Image –
– DEM (same extent as TC&TF below) –
– Terrain Flattened and Terrain Corrected (without additional normalization) –
– Terrain Corrected –
Range Doppler with radiometric normalization set performs well in referencing the image to the source DEM but correction for terrain is weak and shadows largely persist (as well as bright areas)
Similar posts:
Best
Chris
Could you fix the orientation of the images - it’s very difficult to compare the results for the moment. The terrain flattened scene looks good IMO, I don’t know what is going on with the terrain corrected version.
Hi @mengdahl,
I edited the screenshots, hope its now easier to compare. I´m not sure with the TF image, the blurriness and the NaN holes (in the TF&TC image) are much different from what I know of corrected images from MapReady (which of course uses a different algorithm and doesnt support S1). Let me know if I can provide you with any additional info