[Nexus] pixel_mask documentation

Wed Jul 10 15:14:16 BST 2013

I have captured that in the NXDL like this for now:

+  <field name="pixel_mask" type="NX_INT32" >
+    <doc>The pixel mask for the detector.
+ Contains a bit field for each pixel to signal dead, blind or high or otherwise unwanted or undesirabe pixels.
+        They have the following meaning:
+
+ 0 gap (pixel with no sensor)
+ 1 dead
+ 2 under responding
+ 3 over responding
+ 4 noisy
+ 5 -undefined-
+ 6 pixel is part of a cluster of problematic pixels (bit set in addition to others)
+ 7 -undefined-
+ 8 user defined mask (e.g. around beamstop)
+
+ 9-30 -undefined-
+
+ 31 virtual pixel (corner pixel with interpolated value)
+
+ The normal data analysis software would not take pixels into account when a bit in (mask & 0x00FF) is set.
+ Tag bit in the upper two bytes would indicate special pixel properties that normally would not be a sole reason to
+ reject the intensity value (unless lower bits are set as well of course).
+    </doc>

It could be prettier, but if we can all agree on it that's almost better.

Any comments or corrections welcome.

Regards,

Tobias

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

Hi Tobias,
That is a good idea! The first two bytes for critical pixel problems, and the rest to mark special pixels. We can still change that, that is fine!

Best,
Michael

On Wed, Jul 10, 2013 at 11:04 AM, <Tobias.Richter at diamond.ac.uk<mailto:Tobias.Richter at diamond.ac.uk>> wrote:
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<mailto: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<mailto: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

--
**************************************************
Michael Rissi, Ph.D.
Product Development

DECTRIS Ltd.
Neuenhoferstr. 107
5400 Baden
Switzerland

+41 56 500 2100 general
+41 56 500 2101 fax
+41 56 500 2125 direct
michael.rissi at dectris.com<mailto:michael.rissi at dectris.com>
www.dectris.com<http://www.dectris.com>
**************************************************

Confidentiality Note
This message is intended only for the use of the named recipient(s)
and may contain confidential and/or privileged information. If you are
not the intended recipient, please contact the sender and delete the
message. Any unauthorized use of the information contained in this
message is prohibited.
**************************************************

-- 
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