Fix using slice(None) as default value for double sized strixels

Description

As reported by Nuno, a missing double sized pixel definition in the hardcoded conversion files for strixels unfortunately uses slice(None) / np.s_[:] instead, effectively making all pixels double-sized. This MR fixes this by using np.s_[:0] instead.

How Has This Been Tested?

TBD CI

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Reviewers

@kluyvert @hammerd

Do we want to make them length 0 arrays for consistency with what's loaded from the files? It could be easy to miss if we're changing that code that they're arrays or slices. This isn't a priority, though, I'm just speculating.

LGTM

Hmmm interesting, technically nothing is stopping the files from containing slices though, r?

They're .npz files, so unless you load them with allow_pickle=True, they're limited to Numpy arrays with native numpy data, not arbitrary Python objects. We don't allow pickles there at the moment, although of course we could change that in the future.

https://git.xfel.eu/calibration/pycalibration/-/blob/c37e18ecdb966ce0296d91fa8ce9ead54b507d25/src/cal_tools/jungfrau/jfstrixel.py#L29-31

I suppose allow_pickle could be acceptable from a safety point of view given that we only load the .npz files we baked ourselves. Is a slice on X and Y sufficiently general or should we just bake a mask?

Yup, I don't think there's a security issue. I'd still be a little bit reluctant to use pickle because it's harder to work out what types the things we load are, and - while slices are fine - it's easy to save something in a pickle which doesn't load properly with a newer version of Python or a dependency.

That's deeper than I intended to go

As you don't mind, I'll keep it a slice and expect the code to work with any form of numpy indexing.

CI passed, so thanks for review!

(I realize there's no strixel detector in the CI, but I didn't broke the notebook)

merged

changed milestone to %3.16.0

mentioned in commit 557b568b