Custom Query (432 matches)
Results (58 - 60 of 432)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#56 | fixed | Support: 01/Oct/2007, Johanna Breyer, GB06-11 | mggr | mggr |
Description |
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. |
|||
#225 | fixed | Specim synchronisation error | mggr | mggr |
Description |
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. |
|||
#73 | fixed | Specim sync errors | mggr | mggr |
Description |
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. |
Note: See TracQuery
for help on using queries.