Opened 18 years ago
Closed 17 years ago
#121 closed bug (fixed)
Azatm -cuo option seemingly not working
| Reported by: | benj | Owned by: | benj | 
|---|---|---|---|
| Priority: | whenever | Milestone: | |
| Component: | az* programs | Keywords: | |
| Cc: | mggr | Other processors: | 
Description
If you use the -cuo option in azatm to change the values it's supposed to set overflowed and underflowed pixels to, it doesn't seem to have an effect - always sets underflowed pixels to 0 (even if told to set them to ffff) and always says: 
************* radcal underflow and overflow fill values changed ********
      under : 00000  = 0     over: 00000  = 0
...in azatm output, regardless of what values are entered for the under/overflow (tried with 0 fffe and ffff ffff).
Arose from testing on #115
Change History (3)
comment:1 Changed 18 years ago by benj
- Priority changed from low to whenever
 
comment:2 Changed 18 years ago by benj
...and obviously above I meant 2 to the 15th power, minus 1, but the wiki formatting's messed up.
comment:3 Changed 17 years ago by benj
- Resolution set to fixed
 - Status changed from new to closed
 
Fixed, closing
Note: See
        TracTickets for help on using
        tickets.
    
Does actually work, it's just that it's parsing badly - the help lists the default as "0 ffff", but it doesn't recognise ffff as a number because it needs hex to have 0x in front of it (and if it did work it would itself be an overflow - ffff is negative for a signed integer). If you enter 32767 (215-1) as the value to use, it works.
Leaving open in case we ever get around to fixing the parsing, but dropping priority to whenever.