On 25 November 2010 20:39, Tim Jenness <[log in to unmask]> wrote:
> On Thu, 25 Nov 2010, Malcolm J. Currie wrote:
>
>> Sorry to come to the party late.
>>
>>> I think I understand the issue now. "Badness" is a concept that is not
>>> present in HDS - there are no references to VAL__BAD anywhere in HDS.
>>
>> Exactly. HDS provides the basic hierarchical building blocks. We devise
>> other conventions and construct standard structures upon it. Badness is once
>> such higher-level concept. As far as I know the only place where the
>> flagged-value concept enters is for values where a type-conversion error has
>> occurred, but as David says these don't use PRIMDAT.
>
> HDS and PRIMDAT explicitly agree on the definition of bad values without HDS
> depending on primdat (I think there is even a test for it).
>
> HDS doesn't use VAL__BAD but it does use an internal global struct that
> defines the bad values for its own use. These are the values that are
> inserted when conversion fails so HDS does actually use bad values for the
> conversion as you state above AND they are assumed to be PRIMDAT equivalent.
>
> So I think the feature-not-bug case is that someone using HDS has to worry
> that the bad value definition in HDS is not defined and its only when
> Starlink applications use HDS that the Starlink definition of bad value
> becomes relevant.
>
>>
>>> So the fact that HDS does not convert bad pixel values is probably a
>>> feature rather than a bug.
>>
>> I agree. Bad values were formally introduced in SGP/38 in 1987/8, then
>> implemented in PRIMDAT later in 1988. Some older packages like EDRS had
>> supported bad pixels (if only for integers) for some years previously.
>>
>
> The problem is that if I map _INTEGER as a smaller type and _INTEGER has bad
> values in it then I'm guranteed to get a conversion error but I can't really
> tell whether it's an error I should be worried about or simply a bad value
> (which is guaranteed to be out of range of the smaller type).
>
> So my choices are:
>
> 1. Map as _INTEGER and write my own conversion code (using VEC but with a
> C interface)
>
> 2. Assume that DAT__CONER errors can be ignored when I map a smaller type
> (effectively assuming that conversion errors are occurring because of
> bad values rather than unexpected out of range values). Note that
> these will contain perfectly valid PRIMDAT bad values.
>
> 3. Add one if statement to HDS for the conversion error handling
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.
David
> #3 seems safest to me (even if I have to add that one line in quite a few
> places). #3 does not cover the case where you are mapping to a bigger type
> since there is no overflow handling code in there so I'd have to add many
> cases.
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
|