The last post for today… sorry for spamming!
We are working hard with SNAP and Sentinel-1 SLC products, but getting many issues and no image usable for the moment…
The question is simple and it’s probably related to what already reported here by @felix and me:
and also here by me:
I can’t find the answer to: calibration should be performed before or after debursting?
We realized that AFTER debursting, although SNAP allows its execution, calibration always fails on our SLC products.
If we apply it BEFORE debursting, it works.
I said that this could be related to the other posts because there nobody did a calibration before debursting and the error was actually related to calibration (in the terrain correction post it was related to “normalization”, which implies calibration).
Thanks for you time and sorry if the question is trivial… but we discovered this after a long trial-and-error process, and I would like to be sure we’re doing well.
Regards,
Adamo
I answer to myself and maybe also to @felix regarding the aforementioned posts…
As usual, after searching, then asking… you find the solution somewhere else:
where @lveci reports an example of SLC to GRD processing chain.
Calibration is the very first step.
Can we assume that it should be always like this?
If so, maybe it would be worth to not allow the user to perform calibration after debursting of Sentinel-1 data?
E.g., regarding the first ref. post above, I was supposing it was not necessary to calibrate at the beginning (with the ellipsoid) because I was doing “normalization” (with the DEM) at the end in the terrain correction step.
Finally, this should solve also the problem with dual-pol data reported in the second ref. post. Tomorrow I’ll give it a try.
Most probably the errors that SNAP outputs when trying to calibrated a debursted SLC image or even a pre-processed images after filtering or/and coregistration (for example during radiometric calibration in Terrain correction) is due to the wrong alignment of the LUTs and the “new” images, which has no more bursts. The same happens to the thermal noise removal (after both bursting or co-registration). Is this corrected @lveci@junlu? If so, I see especially problematic the thermal noise removal if someone wants to get good co-registration accuracy by using the back-geocoding before. In this way the thermal noise removal will be impossible.
Thanks again for your job! Hope this can improve it.
