[Nexus] pixel_mask documentation

[Michael Rissi]

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


-- 
**************************************************
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/20130710/8db0ecd0/attachment.html>