Support: 15/May/2007, Rachel Gaulton, GB06/05

[mggr]

Two issues:

• Amer checking on LIDAR.
• Use of bsq with azgcorr
  • mggr suspects perhaps the missing scans are throwing off the navigation?

Rachel's initial contact email:

I am trying to process ATM and CASI data flown last summer over my two
sites in Wales (GB06/05, PI - Tim Malthus). Unfortunately we are
having a few problems with AZGCORR and I wanted to check whether you
had encountered them before and had any idea what might be wrong (or
who else might have).

As we are carrying out atmospheric correction before geometrically
correcting the swaths in AZGCORR, so we are using the resulting .bsq
image in conjunction with the original .hdf (and a DTM) as inputs to
AZGCORR, as recommended in the user guide. With the CASI data and most
of the ATM swaths this appears to work ok (at least as far as can be
determined by visual inspection of the results), however with certain
swaths the geometric correction is not successful. These seem to be
swaths with considerable numbers of missing pixels / scan lines.  When
the raw .hdf data is geometrically corrected directly, the problems do
not appear and AZGCORR  works correctly (attached jpeg1), but when the
image is first converted to .bsq and atmospherically corrected the
image seems to be corrected up until the point of the missing scan
lines, but after that appears to be just 'stretched' to fit the
correct outline (jpeg2). The same problem is also being encountered by
John Dowens in correcting strips from GB06/07.

Do you have any ideas what may be causing this problem? Any
suggestions very much appreciated.  I was also wondering if you know
when I might be likely to receive the remaining LIDAR data from this
acquisition (I have the lidar from my Glasfynydd site but not from
Clocaenog)?

[mggr]

jpeg1 from Rachel's initial email

[mggr]

jpeg2 from Rachel's initial email

[mggr]

Steve replied and asked for additional info while we're trying to reproduce. Rachel replied back with:

> Many thanks for your response and help. Command string is 
> below as requested. The DTM used is attached in case this is 
> of use. The file a195041b_atm.bsq is the output of 
> atmospheric correction in the ATCOR program which is 
> formatted as a .bsq with an ENVI header. Bit big to email but 
> can find a way to get it to you if necessary.

Command line she used:

~s0455027/loyal_scratch/image_preprocessing/azgcorr/azgcorr.4613 \
  -1 ~s0455027/loyal_scratch/image_preprocessing/a195041b.hdf \
  -3 ~s0455027/loyal_scratch/image_preprocessing/azgcorr/atm/a195043a_atm_gcor.hdf \
  -p 1.5 1.5 -B 3802 12 0 1.0 0.0 0.0 \
  -Bs ~s0455027/loyal_scratch/image_preprocessing/ATCOR/atm/a195041b_atm.bsq \
  -mUKNG -an -hn -in \
  -eh ~s0455027/loyal_scratch/image_preprocessing/azgcorr/glasfyn_dtm.asc \
  -v 

DEM stored at ~arsf/arsf_data/2006/dems/glasfyn_dtm.asc

[mggr]

Her contact details:
<Details removed>

[mggr]

Implication of her DEM is that the site is Glasfynydd, or 195A.

Processing data to catch up with her.. Project is stored at ~arsf/arsf_data/2006/195A_GB06_05

[mggr]

Steve found a -be option in azgcorr that enables the use of the SCbedit (bad scans) vector.

I have solved the problem by using the "-be" option in azgcorr. Note
this is not documented in the manual so I assume it is a recent addition
to azgcorr. If you type azgcorr -help you will get a listing of all the
commands so please check that your version includes this option. If not
we can let you have an updated version.

The help on "-be" notes that it "enables use of SCbedit to remove bad
bands" but in your case it appears to be using the SCbedit vector (set
of flags) to remove bad lines - you will see that the mapped image has
the bad lines interpolated.

I have attached the commands used to produce the results together with
the azgcorr -help listing.

Please let me know if this solves the problem.

SBG's commands:

/users/rsg/sbg/arsf_user_test/bin/azexhdf.317 -h a195041b.hdf -BS a195041b_test.bseq
/users/rsg/sbg/arsf_user_test/bin/azgcorr.479 -1 a195041b.hdf -3 a195043a.hdf -bl 2 3 5 -1 -p 1.5 1.5 -mUKNG -an -hn -in -eh ~arsf/arsf_data/2006/dems/glasfyn_dtm.asc -Bs a195041b_test.bseq -B 3802 11 0 1.0 0.0 0.0 -be
/users/rsg/sbg/arsf_user_test/bin/azexhdf.317 -h a195043a.hdf -b1 2 3 5 -1 -G a195043a.tif

User contacted to see if that solves their problem.

[mggr]

Rachel replied that Steve's fix works for her too, but has funny effects on other images.

> > It produces some strange results if run on 
> > image strips that geo-corrected ok before but do have some 
> > missing scan lines / significant amounts of missing pixels.

Steve asked for which lines and whether it's ok to just use the non-"-be" azgcorr for those.

[mggr]

LIDAR status appears to be that it's still at Cambridge, with some poor GPS issue. We need to contact them.

Mike investigating Rachel's query as to how -be works, but thinks we need to contact Bill (possible bug :p). Found a bug in azexhdf while at it, see #9.

[mggr]

Mike sent tentative reply, describing how we think it works. Mike contacting Bill for more info.

Steve told Rachel about the LIDAR status and pointed her to Cambridge (see Processing/LIDAR).

[mggr]

Bill confirmed it's an azgcorr bug re: SCbedit handling and BSEQs. Released azgcorr.481 to fix it (need to test and get back to Rachel). Tracker ticket for the bug is #11.

[mggr]

sbg was checking this version - any luck?

[mggr]

mggr checked it out - seems ok.

Sent an explanation and updated azgcorr (4.8.3) and azexhdf (3.1.9, should fix #9) to Rachel and John.

Closing this ticket on the wild assumption that it's all fixed (will reopen if we get a contradictory response).