<div dir="ltr">Dear Tobias,<div><br><div>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:</div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 0 gap (</span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">pixel</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> with no sensor)</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 1 dead</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px"><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 2 under responding</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 3 over responding</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px"><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 4 noisy</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 5 -undefined-</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px"><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 6 </span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">pixel</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> is part of a cluster of problematic </span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">pixels</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> (</span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">bit</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> set in addition to others)</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 7 -undefined-</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px"><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 8 user defined </span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">mask</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> (e.g. around beamstop)</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px"><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 9-29 -undefined-</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px"><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 30 </span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">virtual</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> </span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">pixel</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> (corner </span><span class="" style="font-family:arial,sans-serif;font-size:13.333333969116211px">pixel</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> with interpolated value)</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+ 31 -undefined-</span></div><div><br></div><div>Is it possible at this point to change the definition? Thanks for your understanding!</div>
<div><br></div><div>Best regards,</div><div>Michael</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 4:14 PM, <span dir="ltr"><<a href="mailto:Tobias.Richter@diamond.ac.uk" target="_blank">Tobias.Richter@diamond.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have captured that in the NXDL like this for now:<br>
<br>
+ <field name="pixel_mask" type="NX_INT32" ><br>
+ <doc>The pixel mask for the detector.<br>
+ Contains a bit field for each pixel to signal dead, blind or high or otherwise unwanted or undesirabe pixels.<br>
+ They have the following meaning:<br>
+<br>
+ 0 gap (pixel with no sensor)<br>
+ 1 dead<br>
+ 2 under responding<br>
+ 3 over responding<br>
+ 4 noisy<br>
+ 5 -undefined-<br>
+ 6 pixel is part of a cluster of problematic pixels (bit set in addition to others)<br>
+ 7 -undefined-<br>
+ 8 user defined mask (e.g. around beamstop)<br>
+<br>
+ 9-30 -undefined-<br>
+<br>
+ 31 virtual pixel (corner pixel with interpolated value)<br>
+<br>
+ The normal data analysis software would not take pixels into account when a bit in (mask & 0x00FF) is set.<br>
+ Tag bit in the upper two bytes would indicate special pixel properties that normally would not be a sole reason to<br>
+ reject the intensity value (unless lower bits are set as well of course).<br>
+ </doc><br>
<br>
It could be prettier, but if we can all agree on it that's almost better.<br>
<br>
Any comments or corrections welcome.<br>
<div class=""><br>
Regards,<br>
<br>
Tobias<br>
<br>
________________________________<br>
From: Michael Rissi [<a href="mailto:michael.rissi@dectris.com">michael.rissi@dectris.com</a>]<br>
</div>Sent: 10 July 2013 10:29<br>
To: Richter, Tobias (DLSLtd,RAL,DIA)<br>
Cc: Marcus Mueller; Herbert J. Bernstein; <a href="mailto:nexus@nexusformat.org">nexus@nexusformat.org</a><br>
<div class="">Subject: Re: [Nexus] pixel_mask documentation<br>
<br>
</div><div class="">Hi Tobias,<br>
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!<br>
<br>
Best,<br>
Michael<br>
<br>
<br>
</div><div class="">On Wed, Jul 10, 2013 at 11:04 AM, <<a href="mailto:Tobias.Richter@diamond.ac.uk">Tobias.Richter@diamond.ac.uk</a><mailto:<a href="mailto:Tobias.Richter@diamond.ac.uk">Tobias.Richter@diamond.ac.uk</a>>> wrote:<br>
Hi Michael,<br>
<br>
Thanks for that clarification. I will add that to the documentation of NXdetector.<br>
<br>
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?<br>
<br>
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.<br>
<br>
How would everyone feel about:<br>
<br>
* moving this corner information to a separate field?<br>
* 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?<br>
<br>
Or is it too late for any changes?<br>
<br>
Kind regards,<br>
<br>
Tobias<br>
<br>
________________________________<br>
</div>From: Michael Rissi [<a href="mailto:michael.rissi@dectris.com">michael.rissi@dectris.com</a><mailto:<a href="mailto:michael.rissi@dectris.com">michael.rissi@dectris.com</a>>]<br>
<div class="">Sent: 10 July 2013 06:48<br>
To: Richter, Tobias (DLSLtd,RAL,DIA); Marcus Mueller<br>
</div>Cc: Herbert J. Bernstein; <a href="mailto:nexus@nexusformat.org">nexus@nexusformat.org</a><mailto:<a href="mailto:nexus@nexusformat.org">nexus@nexusformat.org</a>><br>
<div class="HOEnZb"><div class="h5">Subject: Re: [Nexus] pixel_mask documentation<br>
<br>
Hey Tobias,<br>
<br>
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.<br>
<br>
Is 6 or 7 targeted for corner pixels on Eiger/Pilatus?<br>
<br>
7 is for corner pixels. Bit 6 is for pixels that lie in a cluster of bad pixels.<br>
<br>
<br>
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.<br>
<br>
What's "5 non uniform" exactly? Just that I can make the documentation most meaningful.<br>
<br>
I am sorry, that was still there for historical reasons... We can remove this flag, as we do not really need it anymore.<br>
<br>
<br>
Bits do come in handy though. It allows us to add:<br>
<br>
8 user specified<br>
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?<br>
<br>
Yes, definitely!<br>
<br>
Best regards,<br>
Michael<br>
<br>
<br>
--<br>
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.<br>
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.<br>
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.<br>
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<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
**************************************************<br>
Michael Rissi, Ph.D.<br>
Product Development<br>
<br>
DECTRIS Ltd.<br>
Neuenhoferstr. 107<br>
5400 Baden<br>
Switzerland<br>
<br>
+41 56 500 2100 general<br>
+41 56 500 2101 fax<br>
+41 56 500 2125 direct<br>
</div></div><div class="im HOEnZb"><a href="mailto:michael.rissi@dectris.com">michael.rissi@dectris.com</a><mailto:<a href="mailto:michael.rissi@dectris.com">michael.rissi@dectris.com</a>><br>
<a href="http://www.dectris.com" target="_blank">www.dectris.com</a><<a href="http://www.dectris.com" target="_blank">http://www.dectris.com</a>><br>
</div><div class="im HOEnZb">**************************************************<br>
<br>
<br>
Confidentiality Note<br>
This message is intended only for the use of the named recipient(s)<br>
and may contain confidential and/or privileged information. If you are<br>
not the intended recipient, please contact the sender and delete the<br>
message. Any unauthorized use of the information contained in this<br>
message is prohibited.<br>
**************************************************<br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
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.<br>
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.<br>
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.<br>
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<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>**************************************************</div><div>Michael Rissi, Ph.D.</div><div>Product Development</div><div><br></div><div>DECTRIS Ltd.</div>
<div>Neuenhoferstr. 107</div><div>5400 Baden</div><div>Switzerland</div><div><br></div><div>+41 56 500 2100 general</div><div>+41 56 500 2101 fax</div><div>+41 56 500 2125 direct</div><div><a href="mailto:michael.rissi@dectris.com" target="_blank">michael.rissi@dectris.com</a></div>
<div><a href="http://www.dectris.com" target="_blank">www.dectris.com</a></div><div>**************************************************</div><div><br></div><div><br></div><div>Confidentiality Note</div><div>This message is intended only for the use of the named recipient(s) </div>
<div>and may contain confidential and/or privileged information. If you are</div><div>not the intended recipient, please contact the sender and delete the </div><div>message. Any unauthorized use of the information contained in this </div>
<div>message is prohibited.</div><div>**************************************************</div>
</div>