jungfrauandClaude Opus 5
a97d763098
Build Packages / build:viewer-tgz:cpu (push) Successful in 20m56s
Build Packages / build:viewer-tgz:cuda (push) Successful in 24m22s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 25m52s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 26m12s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 31m13s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 31m27s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 32m3s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 20m9s
Build Packages / XDS test (durin plugin) (push) Successful in 11m44s
Build Packages / build:rpm (rocky9) (push) Successful in 22m43s
Build Packages / Generate python client (push) Successful in 35s
Build Packages / Build documentation (push) Successful in 1m25s
Build Packages / Create release (push) Skipped
Build Packages / build:rpm (rocky8) (push) Successful in 27m26s
Build Packages / DIALS test (push) Successful in 21m34s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 26m50s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 21m57s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 12m11s
Build Packages / XDS test (neggia plugin) (push) Successful in 10m6s
Build Packages / Unit tests (push) Successful in 1h56m8s
Build Packages / build:windows:nocuda (push) Canceled after 0s
Build Packages / build:windows:cuda (push) Canceled after 0s
DetectorSetup gave a DECTRIS detector bit_depth_image = 16 and bit_depth_readout = 16
the moment it was constructed. Both mean "the detector told us", and at construction
nothing has asked it: the SIMPLON client learns them at configure time, and the lite
receiver reads them off the start message. Until then they were an assumption wearing
the clothes of a measurement.
The assumption was load-bearing in the wrong direction. GetByteDepthImage() gives the
detector's image depth absolute priority - correctly, since the DECTRIS path forwards
images verbatim and the depth has to be the one the pixels actually have - so a value
that was always set meant everything below it was unreachable on DECTRIS:
* image_format_settings.bit_depth_image, which the API documents as "bit depth of
resulting image ... if not provided value is adjusted automatically", was silently
discarded. It works on JUNGFRAU, where the detector's value is not set, and did
nothing at all on an EIGER. No error, no warning.
* so was the promotion to four bytes that summation needs.
Both are now unset for DECTRIS. JUNGFRAU keeps its readout depth of 16, because there
that is a property of the hardware rather than something configured.
Where nothing supplies a depth the answer does not change: GetByteDepthImage() falls
through to the same two bytes it produced before, and the fallback no longer throws
merely because the readout depth is not known yet - GetBitDepthReadoutIfKnown() reports
it as unknown instead of inventing one. The start message carries it as an optional
already, and the receiver already guards on that, so "not known" travels end to end
rather than being papered over. GetBitDepthReadout() still throws for the callers that
genuinely require a value; all of them are on the FPGA path, where it is always set.
Also fixes the jfjoch_test build, which the previous commit broke: SpotExtractorGPU's
Extract() takes a PixelView now, and the parity test still passed a raw pointer. That
should have been caught before it was pushed.
Tests: DetectorSetup (with a new case pinning the contract this restores), plus
DiffractionExperiment, CBOR, writer, HDF5, preprocessing, azimuthal integration and the
GPU spot-finding / integration / decoder suites. rugnux unchanged end to end.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>