NXmx has no field for the depth of the stored image - only bit_depth_readout,
"how many bits the electronics record per pixel". The two diverge exactly when
summation is used: the readout keeps the detector's native width while the
summed image must be wider to hold the sum.
Every NXmx reader nonetheless takes bit_depth_readout as the width of the stored
pixel. dxtbx ignores the non-standard bit_depth_image entirely for a generic
NXmx file, derives its masking markers from bit_depth_readout, and raises
"Unsupported integer dtype uint32" for a 32-bit image when the field is absent.
Reporting the electronic value there would mislead precisely where it differs.
So report the image depth in both fields, and drop the machinery that existed to
carry the electronic one for a DECTRIS detector: the SIMPLON read, the
DetectorSetup setter, and the receiver-side propagation of a key that the DECTRIS
stream2 protocol does not even define. JUNGFRAU and PSI EIGER keep their readout
depth, which the FPGA acquisition genuinely needs.
Also write NXmx underload_value, the lowest valid value. Without it a reader
takes the trusted minimum to be -0x7FFFFFFF, so the error-pixel marker sits
inside the trusted range and is consumed as an intensity. Measured with DIALS
3.27 on a written file: trusted_range goes from (-2147483647, 32766) to
(-32767, 32766), so the INT16_MIN gap pixels are now masked.
Third fix in the same area: JFJochReceiverLite::Configure took the image width
from the incoming stream but not the sign, while the image itself is forwarded
byte-for-byte. A detector sending int32 was re-declared uint32, and the VDS
master was typed unsigned over signed data files. Take pixel_signed from the
stream too - it and the width are both carried by the one image_dtype key.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
leonarski_fandClaude Opus 5
77c6d0f4ec