Update PNG resolution change as per develop branch

[truth-quark]

From Thomas: On the https://github.com/GeoscienceAustralia/gamma_insar/commit/72c3785dd473a9dbdc67e16f0e9e37e5e14d312a commit in the develop branch: this was a minor change to the image resolution of png files generated for each interferogram (flattened, unwrapped, coherence). It was done to make the images a bit more appealing and make it easier to spot issues such as burst discontinuities. The images were quite small after the change of the DEM resolution used in the geocoded products.

Update the parameters: RAS_PIXEL_AVERAGE_RANGE = 20 RAS_PIXEL_AVERAGE_AZIMUTH = 20 in constant.py to RAS_PIXEL_AVERAGE_RANGE = 5 RAS_PIXEL_AVERAGE_AZIMUTH = 5

[truth-quark]

There's several python modules where quick look PNGs are created:

$ grep -ir "make quick-look" --include="*.py" insar | uniq
insar/coregister_dem.py:        # make quick-look png image
insar/process_ifg.py:    # make quick-look png image
insar/coregister_slc.py:            # make quick-look png image

@mcgarth & @adeane-ga: do these params need to be updated for process_ifg.py only, or also in the coregistration modules?

[tfuhrmann]

The change of the pixel averaging factor was required for us to be able to properly review the quality of interferograms (e.g. with regards to burst discontinuities). I've just had a "quick look" at the quicklook PNGs :-) created during the coregister_dem and coregister_slc steps. They are quite low-res at the moment. So for consistency, it might be good to update the params for those scripts as well. @adeane-ga might want to do some testing on what an appropriate pixel averaging factor for those cases would be (trade-off between disk storage and visually appealing image resolution). It's a low-priority task though in my opinion.

[truth-quark]

Flagging a related problem mentioned in #175. Several different pixa(vr|vaz) values are used in the workflow, so the generic RAS_PIXEL_AVERAGE_(RANGE|AZIMUTH) constants make less sense, unless there's a need for a global default (or similar). We also want to avoid creating multiple constants for pixa(vr|vaz) in the workflow too.

One solution is making a generic quicklooks function, discarding the constants and having each caller specify pixa(vr|vaz) on a case by case basis.