3 Commits

Include renames

Author	SHA1	Message	Date
jungfrauandClaude Opus 5	9f49e5abb7	Keep 16-bit images 16-bit through the GPU pipeline ... A detector reading out 16 bits had its frame widened to int32 the moment it was decoded, and every per-pixel pass over that frame then moved four bytes a pixel to carry two. Those passes - the ring statistics three times over, the strong-pixel search, spot extraction, the azimuthal and ROI integrators, Bragg integration - are the bulk of the image loop's device traffic, and 16 bits is the mode a fast acquisition runs in, which is exactly where throughput matters. The preprocessed image now keeps the width of its source. Two codes at the top of the 16-bit range carry the two special states, and they cannot collide with a real value: 0xFFFF masked, or the source's own bad-pixel marker. saturation a pixel at or above the saturation limit. 0xFFFE where the limit code leaves room - a 16-bit EIGER declares a count-rate limit of a few thousand, so there is room to spare - and 0xFFFF where the limit is the whole range, in which case the "is error" test has already claimed 0xFFFF, nothing can be saturated, and 0xFFFE stays a real value. Either way a real value is strictly below the saturation limit and so below both codes. Nothing is clipped and nothing is lost, and which code is in force is carried with the image rather than assumed. No engine learns a second convention. PixelView widens on load, so a masked pixel still reads as INT32_MIN and a saturated one as INT32_MAX, and every existing `v != INT32_MIN && v != INT32_MAX` test keeps its meaning. One code path, not two instantiations that can drift apart; the branch is on a pointer that is the same for every thread of every block, on kernels whose time is the loads it selects between. The vector loads are kept - four pixels still arrive in one transaction, 16 bytes wide or 8, whichever the image is. The wide path is unchanged, and is still taken for anything that is not a 16-bit source, and for any caller that wants the preprocessed image copied back to the host - that mirror is int32 and the CPU engines know only that convention. Measured on the one 16-bit dataset in the rotation test set, which is also the smallest detector in it (2.5M pixels, where per-pixel work is a small part of the loop): image loop 1.025 s -> 1.005 s at one GPU, whole run 5.64 s -> 5.52 s. The gain scales with the frame, so a 16M-pixel detector - where six full-frame passes are 86 % of the loop's GPU time - has much more to gain, and nothing here can measure that: every other dataset in the test set is stored 32-bit. Correctness on that dataset is exact where it can be: indexing rate, first-pass validation score and the integrated partial count are identical to the wide path, and its whole battery row - reflections, observations, space group, R_meas, CC1/2, ISa, mosaicity - is unchanged. Battery 6m17s -> 6m16s, 21/24 space groups, no failures. Also logs, once per run, the width the images are stored in, since it decides how much of the frame moves through every pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 01:52:27 -04:00
leonarski_f	538f3504d3	v1.0.0.rc-161 (#71) ... This is an UNSTABLE release. It includes many experimental features, as well as many AI generated fixes. We recommend using rc.152 for production use. * **rugnux: significantly better quality of results, and faster.** A large rework of integration, scaling, merging, geometry refinement and space-group determination, together with measurements the program previously made no attempt at - the direct beam before indexing, the beam stop, the goniometer rotation scale, and the stretches of a sweep the crystal did not deliver. A rotation dataset typically gains observations at better <I/sigma> and R_meas, and every `mx` and `scale` run writes a `<prefix>_report.txt` results report modelled on XDS's `CORRECT.LP`. Many defaults moved with it: spot detection is self-calibrating, beam-stop detection and rotation geometry post-refinement are on, resolution limits default to as far as the detector reaches, and ice-ring handling engages only where the crystal is measured to have ice. * **jfjoch_viewer:** the beam-stop shadow, the detector calibration and the beam-centre measurement are reachable from "Analyze dataset"; the settings panel reports how the sample moved and how polarized the beam was; image rendering and interaction are faster. * **Performance:** bitshuffle+LZ4 images are decoded on the GPU rather than on the host, with the bitshuffle inverse fused into preprocessing so the decompressed frame is never held in device memory. * **Broker, writer, packaging and build:** image-slot lifetime and locking fixes, per-image datasets sized by the images actually written, the Debian/Ubuntu broker package renamed to `jfjoch`, and `image_analysis` compiling under MSVC again. **Breaking change to the rugnux command line:** * `--azint-only` and `--scale` are **removed**, replaced by `--mode azint` and `--mode scale`; the full pipeline is `--mode mx` and remains the default. A script passing the old flags now fails with the list of valid modes rather than silently running the wrong one. * `-t`/`--stride` is **refused on rotation data**: skipping frames cuts every reflection's rocking curve, so the combined fulls and their partiality would be measured over frames the sweep never recorded. Select a contiguous range with `-s`/`-e` instead. `--mode azint` and `--force-still` still take a stride. **Breaking changes to OpenAPI** - regenerate the client (`jfjoch-client` 1.0.0-rc.161, `frontend/src/client`) or read the affected fields as optional: * `image_scale_b` is removed from the `plot_type` enum, so a client requesting that plot now gets an error rather than a curve. * `azim_int_settings.high_q_recipA`, `spot_finding_settings.high_resolution_limit` and `spot_finding_settings.low_resolution_limit` are no longer `required`. All three mean "no limit at that end" when unset and are omitted from the response instead of carrying a placeholder value, which raises in a client generated from an rc.160-or-earlier spec. A value of 0 is still accepted and means the same thing. **Breaking changes to the stored formats** - a consumer reading these fields must treat them as optional: * The per-image image-scale B factor is no longer computed, so `/entry/MX/imageScaleBFactor` is absent from newly written HDF5 files and the corresponding key is absent from the CBOR DataMessage and END blocks. Files written by rc.160 and earlier still contain it and still open; nothing in the pipeline reads it any more. * `_reflns.jfjoch_diffrn_ISa` now carries the whole-range `1/sqrt(a*b)` that XDS's ISa denotes, and the error-model `a` and `b` are reported in XDS's convention; the strong-reflection asymptote moves to `_reflns.jfjoch_diffrn_ISa_asymptotic`. **A file written by an earlier version carries the asymptote under the plain `ISa` name.** Reviewed-on: #71 Co-authored-by: Filip Leonarski <filip.leonarski@psi.ch>	2026-08-13 17:03:10 +02:00
leonarski_f	c981e1b91c	v1.0.0-rc.137 (#46) ... This is an UNSTABLE release. The release has significant modifications and bug fixes, if things go wrong, it is better to revert to 1.0.0-rc.132. * jfjoch_broker: Better track time for each operation in the processing stack * jfjoch_broker: Rewrite preprocessing of diffraction images in the non-FPGA workflow to better use GPUs (work in progress) * jfjoch_broker: Remove ROI calculation in the non-FPGA workflow (work in progress) * jfjoch_viewer: Toolbar displays image number starting from 1 (instead of 0) Reviewed-on: #46	2026-04-25 19:59:21 +02:00