possible issue with noise LUT range

What is suspect with current s1.datatree['noise_range'].ds['noise_lut'] is:

lines are giving 2 values below zero (a single negative value would have been enough to do interpolation)
lines from associated to this noise_range LUT are stopping at 10639 while lines from digital numbers are stopping at 13481

checked in xml file: noise-s1b-iw1-slc-vv-20200925t173739-20200925t173804-023535-02cb5d-004.xml
the two first values annotated are :

 <line>-2996</line>
  <line>-1498</line>
  <line>0</line>
  <line>1498</line>
  <line>2996</line>
  <line>4494</line>
  <line>5992</line>
  <line>7490</line>
  <line>8988</line>
  <line>10639</line>

in other products there is only one negative value:

<line>-1496</line>
<line>0</line>

or

<line>0</line>
<line>1505</line>

So it seems that the index in azimuth of the noise annotation is not always the same.

after investigations, it appears that lines decoded from noise*.xml files are exactly the same than the ones in xsar Sentinel1Dataset.Datatree .
There is only a cropping in samples from a noise annotation to another (see

xsar/src/xsar/sentinel1_xml_mappings.py

Line 337 in 048f17e

def noise_lut_range_raw(lines, samples, noiseLuts):

) .
but it removes at maximum 1 pixel.
To conclude I think that there is no problem in xsar regarding noise range LUT lines.
Possible issue in the denoising observed are possibly due to corrupted annotation files.

equivalent GRD product : noise-s1b-iw-grd-vv-20200925t173738-20200925t173803-023535-02cb5d-001.xml
doesn't have issue on the line coordinates associated to the noise LUT:

<line>0</line>
    <line>668</line>
    <line>1336</line>
    <line>2004</line>
    <line>2672</line>
    <line>3340</line>
    <line>4008</line>
    <line>4676</line>
    <line>5344</line>
    <line>6012</line>
    <line>6680</line>
    <line>7348</line>
    <line>8016</line>
    <line>8684</line>
    <line>9352</line>
    <line>10020</line>
    <line>10688</line>
    <line>11356</line>
    <line>12024</line>
    <line>12692</line>
    <line>13360</line>
    <line>14028</line>
    <line>14696</line>
    <line>15364</line>
    <line>16032</line>
    <line>16690</line>

ticket opened here: https://jira-projects.cls.fr/browse/MPCS-3180

Copy/paste from MPC ticket:

this issue has been fixed in our development branch and will be included in the next release of L1 IPF.

There was a bug in the calculation of the line number: whenever 1 (or more) bursts from the start of the L0 data are not included in the L1 SLC data, the line numbers were shifted accordingly by linesPerBurst * skippedBurstCount. The reason why bursts may not be processed is due to the slicing. The L0 data may be larger than what's actually needed in order to process a given slice and in these cases the L1 processor skips these extra bursts.

The AzimuthTimes and the noise vectors itself are not affected.
I forgot to mention that for GRD products, the line numbers are calculated by a different routine and thus do not show the same error.
Two quality disclaimers were published on this topic QD 117 for S1A and QD 118 for S1B.

So this bug will be gone in future products Sentinel-1 SLC but there is still a question about how to deal with products impacted:
@lanougue do you think we can shift the line number in azimuth ?