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