Opened 17 years ago
Closed 16 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 17 years ago by benj
- Priority changed from low to whenever
comment:2 Changed 17 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 16 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.