Issues/questions about Export to snaphu

development
1

I have been unsuccessful using the workflow recommended by ESA for deformation analysis of S1 interferograms. Noise is often mentioned but the level of noise I have is similar to the one of the examples and the outputs are flat, noisy and inconsistent with the data.
After weeks of looking into it, I think that there is a problem in the parameters of the snaphu.conf file.

The first problem when you export is that if you specify a mask, the function doesn’t write a mask and doesn’t specify a mask. I remind you the manual of snaphu. The mask description according to SNAPHU:

Read a byte mask from the specified file. The mask file should be the same size as the input array to be unwrapped. The mask should have the binary (not ASCII) value 0 where pixels of the input array are to be ignored during the primary optimization stage of the program. Values elsewhere should be binary 1. Masking is not applied until after the initialization stage of snaphu. Masked areas are treated as areas in which the solution phase value is irrelevant to the solution cost. The magnitude of the interferogram is set to zero in masked areas in the output file. Areas with zero magnitude in the input data are treated as masked areas as well. Areas near the edges of the input may also be masked via options in a configuration file.

Possibly I could make this binary file by hand in python and add the lines in the .conf

Input file of signed binary byte (signed char) values. Values in

the file should be either 0 or 1, with 0 denoting interferogram

pixels that should be masked out and 1 denoting valid pixels. The

array should have the same dimensions as the input wrapped phase

array.

BYTEMASKFILE snaphu.bytemask

Although it would be more elegant to have it generated by SNAP? Since there is the selector in the advanced option of export to SNAPHU?

In addition, there could be some errors generated in the configuration file. The option NCORRLOOKS is defaulted to 23.33 which implies 16 looks with the current configuration. I think this is incorrect isn’t it? 2 S1_SLC doesn’t make 16 looks or do I misunderstand?
The description:

The number of independent looks: approximately equal to the

real number of looks divided by the product of range and

azimuth resolutions, and multiplied by the product of the

single-look range and azimuth spacings. It is about 0.53

times the number of real looks for ERS data processed

without windowing

Finally the format for the input file should be from [0,2pi[ and in SNAP it is [-pi,pi[. When I open the phase header exported back into SNAP I obtain incoherent numbers including negative numbers. Is that normal? This is all a bit of a black box so I struggle to find solution.

Here is the workflow to get the interferogram from 1 burst in the area I am studying. Once again, it doesn’t look worse than the one in the tutorial.
Back_geocoding_B6_ifg_flt.xml (6.0 KB)

Thanks for the clarification/support,

1 Like
2

I took the time to look at the files exported by SNAP in “SNAPHU format” and I was correct. The file exported range in [-pi,pi[ and if you try to modify the phase in SNAP to be in [0, 2pi[ the export crashes…
An export of what you can see with python numpy

image
image723×434 43.3 KB

3

I can confirm now that modifying the phase file to [0,2pi[ allows unwrapping
I can also confirm that the mask is important. I will provide some code for the conditioning before running SNAPHU when I obtain better results.
best

4

Where I am at processing a single burst

image
image983×764 111 KB

and to obtain this I modify the files after the export to snaphu and I modify snaphu.conf

file architecture is a main directory with a subdirectory called snaphu
Before processing I create a water fraction mask (raster/mask/waterfraction)
here is the python snippet:

    pre='subset_0_of_'
    phase_file='Phase_ifg_IW3_VV_27May2015_08Jun2015.snaphu.img'
    direc='S1A_IW_SLC__1SDV_20150527T081352_20150527T081418_006104_007EB2_5172_Orb_Stack_Deb_Ifg_Flt'
    newconf= 'snaphu_tuned.conf'
    phase=np.fromfile(os.path.join('snaphu', pre+direc, phase_file),dtype='float32')
    water=np.fromfile(os.path.join(pre+direc+'_watermask.data', 
                      'land_water_fraction.img'),dtype='int8')
    pi_value=3.1415927
    phase+=pi_value
    phase[water==100]=pi_value
    mask=water-99
    mask[mask<0]=0
    mask=mask.astype(np.byte)
    mask.tofile(os.path.join('snaphu',pre+direc,'water_mask.img'))
    phase.tofile(os.path.join('snaphu',pre+direc,phase_file))
    with open(os.path.join('snaphu', pre+direc, 'snaphu.conf'),'r') as f:
        with open(os.path.join('snaphu', pre+direc, newconf),'w') as g:
            for line in f.readlines():
                if line[0] != '#':
                    head=line.split('\t')[0]
                    if head == 'CORRFILE':
                        line=line+"BYTEMASKFILE\t\twater_mask.img\n"
                    if head == 'NCORRLOOKS':
                        line="NCORRLOOKS\t\t2.66\n"
                else:
                     if line[:14]=="#       snaphu":
                         command=line.split(' ')
                         command[-3]=newconf
                         line=' '.join(command)
                         print(f'To unwrap in the shell, use the command:\n{line}' )
                g.write(line)

in the snaphu.conf you have to add a line for the BYTEMASKFILE. If you want to make it neat, put it in the INPUT FILE area but it doesn’t really matter. I also modified NCORRLOOKS to something more in line with the recommendations. Seems like it accelerated the computations. The values where exactly the same in the end.

5

@djagula can you have a look at this topic? Thank you!

2 Likes
6

I have found a new bug in snaphu export.
The algorithm adds a row to the image. This is apparently tolerated when importing but it certainly is another serious mathematical issue.