I am a PhD student at Aberystwyth university and received some CASI data
from you this June and while finally coming round to processing it, I
have come across the problems underlined below.
If you could give me some advice on this problem I would be very grateful.
Thank you and best wishes,

Johanna


The CASI imagery for lake Vyrnwy has been processed using the azgcorr
software version 4.7.9 (April 9 2007). But when the images are
processed they are flipped as shown in the attached image
(c219013a.jpg), for comparison see the attached screenshot sent with   the
original data (219-casi-mosaic.png). We have experimented with   the
command but cannot seem to fix the problem. The following command   (the
same as the readme file) was used to generate the attached
screenshot:

./bin/azgcorr -v -mUK99 ./misc/osgb02.cgrf -bl 5 3 2 -1 -p 2 2 -1 ./
lev1/c219011b.hdf  -3 ./lev3/c219013a.hdf

The DEM has been removed as we have a problem with it as the output   file
from the azgcorr process is blank when the DEM is included. We   are not
sure whether this is because of the flipping problem or
another separate problem.

In addition please find attached the exported details from the input and
output hdf files.

Descriptive email from Ben to Bill (4/Mar/2009):

We were (still) trying to track down our Vocals offset problem and we think we stumbled across something else. We used CaliGeo to process a line that had had a timing error in it when we'd processed it using the az suite, and CaliGeo didn't produce a timing problem.

We noticed that in the bit where Caligeo is looking for sync the message it finds has a time delay of 548ms, which matches the 548 in the "Navsync Timing" line on the line 5 header file. The previous sync message it found (and discarded) had a time delay of 119ms, which matches the Navsync Timing for line 4. Azimport for that line found a specim sync message offset of 0.119, which suggests to me that it actually picked up the sync message for line 4 rather than 5. Can you take a look at this when you get a chance please? Let me know if I can send you any additional test data. 

Many 2007 flight lines have problems with navigation sync (ie. they don't sync!). This appears to be due to missing sync messages in the .nav file, or a totally missing .nav file. A typical error looks like:

--------------------------------------------------------------------------
azimport  -- ver: 2.2.10 May  7 2007   (C) Azimuth Systems UK 1996, 2007

File template for Specim sync is: hawk/SWIRsh2007130#.nav

Site time limits - day: 130  start: 94341  end: 94609
date: 10 05 2007 jday: 130 utc2gps: 14.0
NAV vgroup exists - updating
Specim navigation sync details from image file header.....
   image lines: 2901 approximate sync time: 35021.46880 (gps SoD) frame inc: 0.05000 secs
   sensor: Hawk frame rate: 20.00 fps  no. of frames to correct for: 3.00
sync time: 35021.5 is NOT on Applanix POSATT file: hawk/SWIRsh2007130a-1.nav start: 35182.8  end: 35403.5
sync time: 35021.5 is NOT on Applanix POSATT file: hawk/SWIRsh2007130a-2.nav start: 35421.1  end: 35565.1
sync time: 35021.5 is NOT on Applanix POSATT file: hawk/SWIRsh2007130a-3.nav start: 35752.3  end: 35869.1
sync time: 35021.5 is NOT on Applanix POSATT file: hawk/SWIRsh2007130a-4.nav start: 36085.1  end: 36243.4

** NO Specim SYNC found after checking all files
** check file template and directory contents - no data saved

A procedure to correct for this is outlined in the specim processing guide but appears only to apply to azspec 1.1.3. We have azspec 1.1.2.