[Nexus] pixel_mask documentation

Mon Jul 15 07:07:05 BST 2013

To me too! We will correct the description on our website as soon as
possible.

On Wed, Jul 10, 2013 at 4:23 PM, yayahjb <yayahjb at gmail.com> wrote:

> Looks good to me -- Herbert
>
>
> On 7/10/13 10:14 AM, 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]
>> 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<Tobias.Richter at diamond.ac.uk>
>> <mailto:Tobias.Richter@**diamond.ac.uk <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 <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:n**
>> exus at nexusformat.org <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<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.
>> ****************************************************
>>
>>
>>
>
>

-- 
**************************************************
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
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.
**************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20130715/e56105a2/attachment-0001.html>