JUNGFRAU: Mask double-size pixels
Requested by Marcin who included the following screenshot to demonstrate the bright double-size pixels:
Doing the actual masking is not that hard: for now, I've added a few lines to (if mask_double_size_pixels
) set the corresponding rows / columns* in bad pixels mask to 1**. Details to discus:
*Have asked for confirmation about the exact pixels. Seems like all ASIC borders.
**Would want a good bad pixel field to set. Maybe we reuse one of the existing bad pixel fields or add one?
Merge request reports
Activity
requested review from @ahmedk
assigned to @hammerd
- Import new
BadPixels
enum memberNON_STANDARD_SIZE
fromcalng
- Make side-by-side assembled report preview with and without masks
Edited by Philipp Schmidt- Import new
changed milestone to %3.7.0
added 263 commits
-
82c0ef70...6d32d11a - 261 commits from branch
master
- 458c3216 - Specifying ranges to add to mask
- d70cce49 - Merge branch 'feat/jf_mask_double_size_pixels' of...
-
82c0ef70...6d32d11a - 261 commits from branch
- Resolved by David Hammer
Have rebased and switched to using
NON_STANDARD_SIZE
. Now a question: should we always set double size pixels toNON_STANDARD_SIZE
or should there be a toggle tomask_double_size_pixels
? Technically the pixels are always double size, so it would make sense to always set and let user later decide which bad pixel fields to care about - but is this convenient enough that users like this? (https://github.com/European-XFEL/EXtra-data/issues/146)
With the default paths for input data, corrected preview mean looks like this:
And if I apply mask, it looks like this:
Whereas applying mask without the double size pixels in the mask (i.e.
corrected_masked[mask & (~np.uint32(BadPixels.NON_STANDARD_SIZE)) != 0] = np.nan
), it looks like this:And by the way, bad pixel mask looks like this (tweaked by adding epsilon before
np.log2
because the mask preview doesn't work very well, but that's not in scope of this MR):added 2 commits
- Resolved by Karim Ahmed
- Resolved by Karim Ahmed
Thank you @hammerd , LGTM
mentioned in commit 1504d8f4