Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unwrapping - Phass not found and files too big for snaphu #21

Open
jlmaurer opened this issue May 16, 2020 · 8 comments
Open

Unwrapping - Phass not found and files too big for snaphu #21

jlmaurer opened this issue May 16, 2020 · 8 comments

Comments

@jlmaurer
Copy link

  • When running the unwrapping script with snaphu I get the message:
    • "one or more interferogram dimensions too large"
    • file size is (67557.0,18929.0)
  • Phass doesn't seem to exist (can't be imported)
    • Is it another library?
@hfattahi
Copy link
Contributor

Phass is another unwrapping software. Currently it's not available.

@piyushrpt
Copy link
Member

The use case for this tool might not be to a wide-area analysis at high resolution in a single shot. For wide area analysis, if you are still interested in high-res; we will need a tiling mechanism that puts together results after unwrapping. I think that will come much later. If you are interested in moderate/low resolution results over a large area - you might be better off multi-looking fringe results and performing analysis with that.

@jlmaurer
Copy link
Author

Yes, that's what I was thinking. Sounds good.

@scottstanie
Copy link
Contributor

I got the same "dimensions too large" error from processing just a .5 degree x .5 degree block, which came out to have interferograms with shape (7335, 45053). For me, giving the --tile option to snaphu avoided the error and unwrapped successfully

I'm not sure if it's available as the Snaphu component that unwrap_fringe.py uses, since i've only used configuration files/ command line calls to snaphu before, but I'll attach the config I used in case @jlmaurer want's to try again with snaphu. For reference, my interferogram unwrapped in 14 minutes with the tile settings I had, but it was on a pretty big machine.

$ cat snaphu1.conf
########################
# Unwrapping parameters
#########################

STATCOSTMODE SMOOTH
INITMETHOD MCF
VERBOSE TRUE

###############
# Input files
###############

CORRFILE tcorr_ds_ps.bin

################
# Output files
################

OUTFILE unwrap/20160930_20170104.unw
LOGFILE snaphu.log

################
# File formats
################

# INFILEFORMAT FLOAT_DATA
CORRFILEFORMAT FLOAT_DATA
# OUTFILEFORMAT FLOAT_DATA


################
# Tile control
################

NTILEROW 4
NTILECOL 12

ROWOVRLP 30
COLOVRLP 30

NPROC 48

@jlmaurer
Copy link
Author

Thanks @scottstanie I'll try that option out!

@stoormgeo
Copy link

I got the same "dimensions too large" error from processing just a .5 degree x .5 degree block, which came out to have interferograms with shape (7335, 45053). For me, giving the --tile option to snaphu avoided the error and unwrapped successfully

I'm not sure if it's available as the Snaphu component that unwrap_fringe.py uses, since i've only used configuration files/ command line calls to snaphu before, but I'll attach the config I used in case @jlmaurer want's to try again with snaphu. For reference, my interferogram unwrapped in 14 minutes with the tile settings I had, but it was on a pretty big machine.

$ cat snaphu1.conf
########################
# Unwrapping parameters
#########################

STATCOSTMODE SMOOTH
INITMETHOD MCF
VERBOSE TRUE

###############
# Input files
###############

CORRFILE tcorr_ds_ps.bin

################
# Output files
################

OUTFILE unwrap/20160930_20170104.unw
LOGFILE snaphu.log

################
# File formats
################

# INFILEFORMAT FLOAT_DATA
CORRFILEFORMAT FLOAT_DATA
# OUTFILEFORMAT FLOAT_DATA


################
# Tile control
################

NTILEROW 4
NTILECOL 12

ROWOVRLP 30
COLOVRLP 30

NPROC 48

Thanks @scottstanie I'll try that option out!

@scottstanie @jlmaurer
Did you get the correct unwrapped images after using the tile mode?
My issue #46

@scottstanie
Copy link
Contributor

I've had relatively few problems with the tile mode of snaphu. Only recently did I have an interferogram where there was an obvious tile artifact.
BTW, the most recent snaphu gives this warning:

$ /home/scott/phase_unwrap/bin/snaphu -s ./20150706_20160302.int 3120 -c ./20150706_20160302.cc -o ./20150706_20160302.unw -S --tile 3 3 30 30 --nproc 9

snaphu v2.0.4
WARNING: Tile overlap is small (may give bad results)
Starting first-round tile-mode unwrapping
...

Apparently my "30 30" overlaps were less than it was expecting. If you give larger overlaps (like in the 300- 500 range), it stops giving that warning. With less overlap, snaphu has less data to figure out the across-tile solutions at the end.

But I'll say that the tiling has never given a result like the issue you linked to. That diagonally-repeating binary messed up output almost always comes from my giving the display program the wrong file width, or from saving it using the wrong width.

@hfattahi
Copy link
Contributor

I've had relatively few problems with the tile mode of snaphu. Only recently did I have an interferogram where there was an obvious tile artifact.
BTW, the most recent snaphu gives this warning:

$ /home/scott/phase_unwrap/bin/snaphu -s ./20150706_20160302.int 3120 -c ./20150706_20160302.cc -o ./20150706_20160302.unw -S --tile 3 3 30 30 --nproc 9

snaphu v2.0.4
WARNING: Tile overlap is small (may give bad results)
Starting first-round tile-mode unwrapping
...

Apparently my "30 30" overlaps were less than it was expecting. If you give larger overlaps (like in the 300- 500 range), it stops giving that warning. With less overlap, snaphu has less data to figure out the across-tile solutions at the end.

But I'll say that the tiling has never given a result like the issue you linked to. That diagonally-repeating binary messed up output almost always comes from my giving the display program the wrong file width, or from saving it using the wrong width.

Yes definitely larger overlap reduces the possibility of tile boundary artifacts. I agree the plot looks to me as a display issue. That's why I was asking about the shape and size of the outputs in #46 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants