Opened 13 years ago

Closed 12 years ago

#2 closed support (fixed)

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

Reported by: mggr Owned by: mggr
Priority: alpha 4 high Milestone:
Component: Support Keywords:
Cc: sbg Other processors:

Description (last modified by 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)?

jpeg1 from Rachel's initial email

jpeg2 from Rachel's initial email

Attachments (2)

jpeg1.jpg (106.8 KB) - added by mggr 13 years ago.
jpeg1 from Rachel's initial email
jpeg2.jpg (107.1 KB) - added by mggr 13 years ago.
jpeg2 from Rachel's initial email

Download all attachments as: .zip

Change History (14)

Changed 13 years ago by mggr

jpeg1 from Rachel's initial email

Changed 13 years ago by mggr

jpeg2 from Rachel's initial email

comment:1 Changed 13 years ago by 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

comment:2 Changed 13 years ago by mggr

Her contact details:
<Details removed>

comment:3 Changed 13 years ago by 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

comment:4 Changed 13 years ago by mggr

  • Description modified (diff)
  • Owner set to mggr
  • Status changed from new to assigned

comment:5 Changed 13 years ago by mggr

  • Description modified (diff)

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by 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.

comment:8 Changed 13 years ago by mggr

  • Cc sbg added

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.

comment:9 Changed 13 years ago by 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).

comment:10 Changed 13 years ago by mggr

  • Description modified (diff)

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.

comment:11 Changed 13 years ago by mggr

  • Type changed from task to support

sbg was checking this version - any luck?

comment:12 Changed 12 years ago by mggr

  • Resolution set to fixed
  • Status changed from assigned to closed

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).

Note: See TracTickets for help on using tickets.