RE: NDStats plugin shows huge numbers for Eiger detector (areaDetector 3.7)

[Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>]

Ø  One possible workaround is to calculate stats on ROIs corresponding to the Eiger modules and have calc records to combine them.

 

I just tested another workaround.  Send the image through an ROI plugin, and set the DataTypeOut to Int32 rather than Automatic.  Set the STATS plugin to get its data from the ROI plugin.  Now it will get Int32 data, and all the pixels that were 2^15-1 or 2^31-1 will be -1 and the statistics will be much more reasonable.  Feeding this signed image into the display plugins (NDPluginStdArrays or NDPluginPva) will also help a lot in making autoscaled display intensities look good.

 

Mark

 

 

From: Bruno Martins <brunoseivam@gmail.com>
Sent: Tuesday, August 20, 2019 10:30 AM
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: Sobhani, Bayan <bsobhani@bnl.gov>; tech-talk@aps.anl.gov
Subject: Re: NDStats plugin shows huge numbers for Eiger detector (areaDetector 3.7)

 

Hi Alex,

 

The SIMPLON API reference [1] states: "pixels that have a corresponding bit set in the pixel_mask are flagged with (2^bit_depth_image)-1". I agree with Mark's assessment that "we are stuck having the gaps and bad pixels be the largest positive number". One possible workaround is to calculate stats on ROIs corresponding to the Eiger modules and have calc records to combine them.

 

 

[1] https://www.dectris.com/support/manuals-docs/eiger2-r-for-laboratory/eiger2-r-500k?file=files/content/docs/support/manuals_and_documentation/EIGER2/api_reference/SIMPLON_APIReference_v1p7.pdf

 

Bruno

 

 

On Tue, Aug 20, 2019 at 10:29 AM Mark Rivers via Tech-talk <tech-talk@aps.anl.gov> wrote:

Hi Alex,

 

The DataType_RBV in the NDStats plugin is the data type of the NDArray it received.  You cannot change it.

 

The ADEiger driver uses unsigned datatypes, UInt32, UInt16, or UInt8 depending on the frame rate.  The Dectris Eiger software uses 0xFFFFFFFF for bad pixels and pixel gaps in 32-bit mode and 0xFFFF in 16-bitmode.  If we changed these ADEiger to use signed types (Int32, Int16, Int8) then those values would represent -1, but the problem is that the maximum number of positive counts would be limited to half the range.  For example in 16-bit mode the counts would be limited to 32767 (2^15-1) before they wrap around to negative numbers.  I think the detector is actually capable of sending images with counts greater than 32767 in 16-bit mode and greater than 2^31-1 in 32-bit mode.  So we are stuck having the gaps and bad pixels be the largest positive number.

 

Perhaps I am wrong, and the Dectris Eiger firmware never produces images where real counts have the most significant bit set.  Then we could change to signed types.  Does anyone know the answer to that?

 

Mark

 

 

 

From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of Sobhani, Bayan via Tech-talk
Sent: Tuesday, August 20, 2019 8:49 AM
To: tech-talk@aps.anl.gov
Subject: NDStats plugin shows huge numbers for Eiger detector (areaDetector 3.7)

 

I have an IOC running for an Eiger detector. The pixels are measured from -1.0 to 0.0. I think at least part of areaDetector recognizes this because when I set the Minimum and Maximum under “Display Controls” on the CSS screens, the picture looks good.

 

However, on the NDStats page, I see the minimum is 0, and the Maximum is 65535. I would expect the minimum to be -1.0, and the maximum to be 0. The Total is also a very large number (16407209312) – it was a much smaller number when I was running an older version of Areadetector (I think 2.7).

 

I thought the problem might be the Datatype – the DataType in the Stats plugin is UInt16. I attempted to change this to Float32 by writing to the Stats1:DataType PV, but it keeps reverting back to UInt16.

 

Any ideas what could be causing the numbers in the Stats1 plugin to be these huge numbers?

 

Alex