16 and 8 bit data

[c-mita]

Following from https://www.globalphasing.com/autoproc/wiki/index.cgi?DataProcessingHdf5Eiger16bit201910, where neggia does not help XDS detect overexposed pixels for 16 bit data.

The reason this "works" for durin is because durin pretends the raw data is signed when converting to 32 bit in the COPY_AND_MASK macro in plugin.c (resulting in sign rather than zero extension). This means that values over 32767 are interpreted as the corresponding negative number (in particular, 65535 is interpreted as -1).

This was a deliberate decision made after discussion with @graeme-winter a while ago, so overloaded pixels would be handled "as expected", even though it was a departure from neggia. This certainly seems to have been the better direction to take.

But it is maybe a bit too simple. Perhaps it would be better to treat the source data as unsigned, and identify the proper upper bound (even if it's just UINT_N_MAX) and only make negative (or -1) for pixels at or above that value. Compare with the suggested patch to neggia here:
CV-GPhL/neggia@2d47864

This would likely be a bigger issue for 8-bit data, where the highest value durin would be able to read would be 127, when it may be only the value 255 should be interpreted as -1.

[graeme-winter]

Another issue while looking at this is the treatment of data over the count rate limit - should durin squash this to -2 or no?