JF: more strixels

As discussed on Redmine and https://git.xfel.eu/calibration/planning/-/issues/195 we're getting more strixels.

Design decision: LUT

I currently feel like prebaking and shipping some simple LUTs is much more convenient than including custom Cython / CUDA kernels for each and every strixel transformation we meet. Therefore, I've used the reference Python implementations to generate flat LUTs with masks (see added tests for comparison) and then strixel transformation is just loading one of these and applying it. Bonus: one less Cython kernel to compile, one less CUDA kernel to maintain. Also it's plenty fast.

Brief test

Quick check in Karabo:

• using arbitrary uncorrected data looking roughly like this:
• cols_A0123 (HED strixels) makes it look like this:
• rows_A1256 (SCS strixels) makes it look like this:

Should probably check with actual strixel data - preferably burst mode for better performance analysis. But as the test shows, the mapping should be the same as what the reference implementations yield. Also, on max-jhub, applying the rows_A1256 to 16 frames with a thread pool (which the CPU runner has anyway) takes less than 5 ms.

In my Karabo test, timing looked like this:

1. GPU warmup time (pinned memory? caching?)
2. GPU regular (keep in mind: no correction applied and single frame mode)
3. GPU applying cols_A0123 (brief slowness while switching; here, the LUT was loaded)
4. GPU applying rows_A1256 (somehow not noticeable hiccup when switching)
5. CPU version also doing no corrections (though kernels are still run doing nothing interesting)
6. CPU applying cols_A0123
7. CPU applying rows_A1256

Masking non-standard size pixels

Non-standard size pixels (well, ones that are not like the other long ones) are not corrected. As discussed with Nuno and Marco, the ones on the border are cropped out and the ones between the ASICs are not handled (both of these in the version Nuno wrote). In the gaps between ASICs, the otherwise unset pixels get corrections.badPixels.maskingValue - this is done regardless of corrections.subsetToUse.NON_STANDARD_SIZE, because we don't want to send uninitialized data.

Future work

Nuno and Marco discussed a bit what to do with the very long strixels on the inner ASIC borders and the weird extra column of small strixels on the outermost ASIC borders. They agreed that, for an initial deployment, the former can be left masked rather than corrected and the latter can be cropped. Also, they didn't find it likely that we'll ever bother going back for these pixels.

assigned to @hammerd

This is a bit atypical for correction runners; it looks more like how for example the upcoming StackingFriend handles its own configuration. I did this because I hope to refactor the correction runners to behave more like that - it would make interface between the correction devices and their runners nicer (currently, BaseCorrection needs to know way too much about BaseKernelRunner to work - a consequence of my attempt to make the runner unaware that it's operating based on a schema).

Neat! It would be good to have the LUT generating code in some place as well, maybe pycalibration? After all we'll need the transformation there as well.

Sure! To generate the ones included here, I just used the following (with partial=True):

def make_flat_lut(input_shape, fun, output_shape=None, partial=False):
    num_elems = np.product(input_shape)
    unmapped = np.arange(np.product(input_shape)).reshape(input_shape)
    if output_shape is None:
        mapped = fun(unmapped)
        output_shape = mapped.shape
    mapped = np.empty(shape=output_shape, dtype=np.int64)
    mapped.fill(-1)
    fun(unmapped, out=mapped)
    mapped = mapped.ravel()
    # let's see how big of a dtype we really need
    max_mapped_index = np.max(mapped)
    for dtype in (np.uint8, np.uint16, np.uint32, np.uint64):
        if max_mapped_index < np.iinfo(dtype).max:
            break
    mask = (mapped == -1)
    mapped[mask] = 0
    mapped = mapped.astype(dtype)
    if partial:
        mapped = mapped[~mask]
    return mapped, mask

in a notebook with the provided reference functions now present in the test file followed by a np.savez_compressed* to store the keys lut, mask, and frame_shape. We can consider whether pycalibration should ship with prebaked LUTs, too (leaving code to regenerate them in a notebook), or whether they should be bootstrapped anew for every job.

*The resulting file is, I suppose, a detector-specific constant. I'd strongly prefer it not be treated as such, though, with CalCat and all. Especially as it doesn't really have conditions - a constant constant, if you will.

And fun would be the naive implementation as used in the tests?

Indeed. In both cases, I only changed it from the "reference implementation" to accept an existing array for conveniently tracking which entries are not written to at all.

We can of course also go by "HED-strixel" and "SCS-strixel". Though if they start moving around, that'd be more confusing than helpful.

I doubt they will, as these sensors are tuned to their use cases. What may happen at some point is more strixels at other places though. Still, for simplicitly in the field, maybe we can use the technical names and add in parantheses "HED-type" and "SCS-type" for now.

changed this line in version 2 of the diff

added 2 commits

• a3e8e308 - Add friendly instrument-related names in parentheses
• 4b7e1b83 - Mask missing strixels with configured bad pixel mask value

Compare with previous version

added 1 commit

• ef6b5ff8 - Think about correction_kernel_strixel being unset initially

Compare with previous version

merged

mentioned in commit 3b329123

changed the description

mentioned in merge request pycalibration!919 (merged)