[Nexus] pixel_mask documentation

yayahjb yayahjb at gmail.com
Thu Mar 6 14:51:19 GMT 2014


I think this is a sensible change, but I would suggest that, in an 
abundance of
caution we also clarify with

31 -- reserved -- deprecated former virtual pixel mask bit, not to be 
used in new code.

That will help to ensure that nobody tries to reuse it for something else.

On 3/6/14 9:44 AM, Michael Rissi wrote:
> Dear Tobias,
>
> We had some discussions here that bit 31 for masking virtual pixels is 
> a little problematic, as we use for various reasons internally int32 
> (instead of unsigned int32) to represent bit masks. We therefore 
> wondered if it were possible to use bit 30 to mask virtual pixels:
>
> + 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-29 -undefined-
> +
> + 30 virtual pixel (corner pixel with interpolated value)
> + 31 -undefined-
>
> Is it possible at this point to change the definition? Thanks for your 
> understanding!
>
> Best regards,
> Michael
>
>
>
>
> On Wed, Jul 10, 2013 at 4:14 PM, <Tobias.Richter at diamond.ac.uk 
> <mailto:Tobias.Richter at diamond.ac.uk>> wrote:
>
>     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
>     <mailto: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
>     <mailto: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><mailto: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><mailto: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><mailto: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><mailto:michael.rissi at dectris.com <mailto:michael.rissi at dectris.com>>
>     www.dectris.com <http://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
>
>
>
>
>
>
>
> -- 
> **************************************************
> 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.
> **************************************************



More information about the NeXus mailing list