jmfriedt / sentinel1_level0

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

New Decoding Files

GianluCampa opened this issue · comments

Good morning jmfriedt,

first of all thank you for your important work shared. In the context of my master thesis I am involved in the processing of Sentinel-1 products, and I used your files for decoding. I have seen that a couple of days ago you have fixed and updated some of them, so I ask you if you can explain a little bit better the modifications done.
In particular I would like to know if the files decoded with the previous version are still valid or if I need to decode once again all the files I am working on with the new decoding version.

Thank you in advance,
Gianluca

I have made two mistakes which do not strictly invalidate the former processing in the sense that pulse compression is robust enough to allow for some noise during correlation (as I showed in my initial analysis of the Sao Paulo datasets, but probably did degrade the quality of focusing).

The first mistake was on one of the quantization cases, I had indexed BRCn with the Huffman code hcode instead of THIDX, meaning that the reconstructed value was erroneous. I am not sure how much impact that has since it only applies in one of the many reconstruction cases (hcode==3 for BRC0, hcode==4 for BRC1, hcode==6 for BRC2 and hcode==9 for BRC3) so I believe this will impact one of the 256 possible reconstruction cases for each BRC. The correction can be found at
7eb59f5#diff-1bc6fcdca604eb920978458b20493e4cd8bc7cbf19ddf766db3bf2f48b73ba57

The second correction is more fundamental and might have a stronger impact: I was handling the sign and magnitude of the hcode as a single value as I could not understand the ESA manual separating the two quantities as sign and magnitude mcode. I now understand: in case of an mcode of 0, the sign is lost (we store -0 or 0 as the same) but during the reconstruction process, the resulting value is non-0 with possibly the wrong sign. Since 0-index reconstructed values are quite low, I would expect this error to induce more noise close to 0 but again not to prevent compression. The correction is at 70bd038#diff-1bc6fcdca604eb920978458b20493e4cd8bc7cbf19ddf766db3bf2f48b73ba57

Please note that the intermediate update 0d8a627#diff-1bc6fcdca604eb920978458b20493e4cd8bc7cbf19ddf766db3bf2f48b73ba57 is only cosmetic and has no impact on the calculation result. I am not exactly sure how the duration of one abs() calculation compares with two comparisons, but anyway this update was invalidated by the next correction which handles the magnitude of the hcode which by definition is positive.

Overall, for a rigorous analysis, I would advise recomputing the most significant datasets you wish to exploit for the thesis or for an article, but the general insight you gathered from your work so far remains definitely valid, only the noise level with decrease thanks to these corrections.
Best, JM

Dear jmfriedt,

thank you for the comprehensive explanation. I will definitely re-decode the most relevant products.

Best regards,
Gianluca