[Nexus] pixel_mask documentation

[Tobias.Richter at diamond.ac.uk]

Hi Michael,

Thanks for that clarification. I will add that to the documentation of NXdetector.

The only slight problem I have is that bit 7 is special in that for the 95% (more 99% I would guess) of the users that is a good pixel and hence it should not be "masked". I mean that's why you Dectris guys go through all the effort of manufacturing them like that, right?

If other vendors create detectors with other types of special pixels you would have to mask out a strange combination of bits of that bit mask to get a useful detector mask.

How would everyone feel about:

* moving this corner information to a separate field?
* using (for example) bits 31 downwards in the pixel_mask for usable non non-perfect pixels, so that software would normally use (mask & 0x0000FFFF) and will in all likelihood never need to change even when new types of pixels come up?

Or is it too late for any changes?

Kind regards,

Tobias

________________________________
From: Michael Rissi [michael.rissi at dectris.com]
Sent: 10 July 2013 06:48
To: Richter, Tobias (DLSLtd,RAL,DIA); Marcus Mueller
Cc: Herbert J. Bernstein; nexus at nexusformat.org
Subject: Re: [Nexus] pixel_mask documentation

Hey Tobias,

We intend also to mark the invalid pixels in the images themselves with -1. So only if you want to know what is wrong with a marked pixel, you can check the pixel mask.

Is 6 or 7 targeted for corner pixels on Eiger/Pilatus?

7 is for corner pixels. Bit 6 is for pixels that lie in a cluster of bad pixels.


To make it easy for consuming software I would not want any bits to be set for a usable pixel value. 95% would not care about a reason for not using the pixel. Flagging up these special pixels somewhere is useful but maybe not in a "mask". Maybe I am wrong anyway.

What's "5 non uniform" exactly?  Just that I can make the documentation most meaningful.

I am sorry, that was still there for historical reasons... We can remove this flag, as we do not really need it anymore.


Bits do come in handy though. It allows us to add:

8 user specified
For pixels that are masked out by the user although they have a physically "correct" reading but for example represent artefacts in the measurement like beamstops. Agreed?

Yes, definitely!

Best regards,
Michael


-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom