On Fri, 26 Nov 2010, David Berry wrote:
> Not sure I follow what you are suggesting for 3) - are you saying you
> would check for (effectively) VAL__BAD values in the input and replace
> them by corresponding VAL__BAD values in the output? If so won't this
> break the whole bad pixel flag concept in NDF? That is, HDS will
> convert bad-looking values regardless of the setting of the NDF bad
> pixel flag. As Malcolm points out, there could well be _UBYTE or
> _UWORD data out there for which setting the bad pixel flag off is
> essential.
>
If you are mapping an _INTEGER as a _WORD and the integer array has bad
values in it then currently you are guaranteed to get a conversion error.
My proposal in this case is simply to not trigger the conversion error if
the integer was the bad value (the conversion will have already put the
bad word into the array so the question is whether to set status to bad or
not). I think this question is different to whether mapping to a bigger
type should translate bad values since you don't get a bad status then.
I assume that ARY maps in the native format regardless and then does the
conversion itself so ARY won't care what HDS does when mapping with a
different type. I assume this is the case because neither ARY nor NDF trap
DAT__CONER.
Sounds like everyone wants me to trap DAT__CONER in SMURF and assume that
the error is from a bad value shrinkage.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|