Opened 17 years ago
Last modified 15 years ago
#88 closed bug
Restricting level 1 processing by scan line causes error — at Version 3
Reported by: | anee | Owned by: | mggr |
---|---|---|---|
Priority: | alpha 4 high | Milestone: | The Glorious Future |
Component: | az* programs | Keywords: | |
Cc: | Other processors: |
Description (last modified by benj)
The use of -l in azspec produces a blank image if anything than a start line of 0 is used. The end line number does seem to produce the correct effect however.
Same problem also occurs in azatm (causes errors saying "scan jump from: 0 to 191119 scan : 191119 rejected"). Same option in azcas2 seems to work correctly.
Change History (3)
comment:1 Changed 17 years ago by anee
- Priority changed from immediate to medium
comment:2 Changed 17 years ago by mggr
- Component changed from ARSF to az* programs
- Milestone set to The Glorious Future
- Status changed from new to assigned
- Type changed from task to bug
comment:3 Changed 17 years ago by benj
- Description modified (diff)
- Summary changed from Possible azspec bug. to Restricting level 1 processing by scan line causes error
Note: See
TracTickets for help on using
tickets.
It appears that HDF files are created without a CAimage when a start line other than 0 is used.
Mike should produce a test case and ask Bill to look at it.
In the meantime, use -l in azgcorr, but ensure the info is passed on to end users if we deliver data that has used the azgcorr option.