adaptive-spot-finding
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
a72ba82f48 |
Powder calibration: write rot2/rot3 in pyFAI's frame, not ours
Build Packages / build:windows:nocuda (push) Waiting to run
Build Packages / build:windows:cuda (push) Waiting to run
Build Packages / build:viewer-tgz:cpu (push) Successful in 11m23s
Build Packages / build:viewer-tgz:cuda (push) Successful in 14m56s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 18m7s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 20m33s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 19m59s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 15m33s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 19m50s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 19m7s
Build Packages / build:rpm (rocky9) (push) Successful in 18m55s
Build Packages / build:rpm (rocky8) (push) Successful in 20m39s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 20m18s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 15m27s
Build Packages / Generate python client (push) Successful in 12s
Build Packages / XDS test (durin plugin) (push) Successful in 8m43s
Build Packages / Create release (push) Skipped
Build Packages / XDS test (JFJoch plugin) (push) Successful in 8m52s
Build Packages / Build documentation (push) Successful in 42s
Build Packages / XDS test (neggia plugin) (push) Successful in 6m59s
Build Packages / DIALS test (push) Successful in 13m49s
Build Packages / Unit tests (push) Successful in 1h23m35s
The .poni file carried rot2 and rot3 with our sign, which is not pyFAI's. pyFAI has the slow axis increasing bottom to top; the MX convention runs top to bottom, so the two frames differ by a reflection in y. Conjugating a rotation by a reflection gives R(n, theta) -> R(Mn, -theta), so for rot2 (about x) and rot3 (about the beam) the sense reverses, while for rot1 the axis IS y and the axis and the sense reverse together and cancel. Negate the first two, leave rot1 alone. Poni1/Poni2 are unaffected: they are distances from pixel (0, 0) along each axis, which the direction the axis runs in does not change. Caught by integrating a LaB6 image in pyFAI with the file we had just written. Unflipped, the rings come out BROADER than they do with no tilt at all - peak height 42 against 30, mean ring-position error 0.0045 1/A against 0.0027 - which is the signature of a tilt applied the wrong way. Flipped, they sharpen to 132 and 0.0005, and flipping rot1 as well makes it far worse (peak 5), so the asymmetry is real and not a fitting artefact. The unit test pinned the old signs, so it passed throughout. It now pins the verified ones and says why, since the stored values and the written ones disagreeing looks like a bug unless the reason is written down. Only the exported file was wrong. Nothing internal changes: the fitted geometry and everything downstream of it in Jungfraujoch were always self-consistent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
6468dd13be |
rugnux: --mode, and detector calibration from powder rings
Build Packages / build:windows:nocuda (push) Waiting to run
Build Packages / build:windows:cuda (push) Waiting to run
Build Packages / Unit tests (push) Failing after 6m24s
Build Packages / build:rpm (rocky9_nocuda) (push) Failing after 14m5s
Build Packages / build:viewer-tgz:cpu (push) Failing after 14m34s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Failing after 14m54s
Build Packages / build:viewer-tgz:cuda (push) Failing after 16m14s
Build Packages / build:rpm (rocky8_nocuda) (push) Failing after 16m24s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Failing after 18m53s
Build Packages / build:rpm (rocky9_sls9) (push) Failing after 13m2s
Build Packages / build:rpm (rocky8_sls9) (push) Failing after 19m34s
Build Packages / build:rpm (rocky9) (push) Failing after 14m54s
Build Packages / Generate python client (push) Successful in 42s
Build Packages / build:rpm (ubuntu2404) (push) Failing after 14m10s
Build Packages / Create release (push) Skipped
Build Packages / XDS test (durin plugin) (push) Successful in 12m14s
Build Packages / XDS test (neggia plugin) (push) Successful in 11m52s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 12m15s
Build Packages / Build documentation (push) Successful in 2m10s
Build Packages / build:rpm (rocky8) (push) Failing after 18m29s
Build Packages / build:rpm (ubuntu2204) (push) Failing after 17m55s
Build Packages / DIALS test (push) Successful in 17m4s
--azint-only and --scale are replaced by --mode mx|azint|scale|calibration, with mx the default. The old flags are removed rather than aliased. Calibration mode fits the detector geometry - PONI x/y, the two tilts and the distance - to a calibrant's powder rings and writes a pyFAI .poni alongside a report of how far each parameter moved from the header. Bragg data constrain the beam centre worst, because it is gauge-coupled to the crystal orientation; a powder ring has no orientation to couple to. --calibrant takes lab6, agbh, ceo2, si or ice. A calibrant is a list of ring positions rather than a unit cell, because hexagonal ice is P6_3/mmc: rings enumerated from its cell would include systematically absent ones. So the crystalline standards generate their rings from a cell and ice carries the measured list, and RingsFromAzimuthalProfile, GuessGeometry and OptimizeGeometry all take ring q. The calibrant table is shared with the viewer's powder panel, which previously carried its own copy. --calibration picks how the rings are measured: rings (default) sums the (q x azimuth) profile over every processed image and fits the arcs in it; spots pools the found spots and fits those. Both use the whole run, with -s/-e/-t selecting images. rings defaults --azim-phi-bins to 32, since a profile with one azimuthal bin has averaged the ring over every direction and cannot locate it. Two fixes this exposed: The extraction window is capped at half the gap to the neighbouring ring. The background under a peak is taken from the ends of its window, so a window wider than half that gap measures the next ring's flank as this ring's background - and hexagonal ice has three rings within 0.06 1/A. Ice calibration was 3.5 px out before this and 0.29 px after; LaB6 is unaffected. RingOptimizer holds rot1/rot2 fixed when only one ring is present. A tilt and a centre offset both move a ring as cos(phi) and are separated only by the tilt's amplitude growing as the ring radius squared, so on a single ring they are exactly degenerate. Measured. LaB6 at five distances: the fitted direct beam is within 0.36 px of an independent implementation out to 300 mm, and D = -0.046 + 1.000788 dtz with an rms of 0.011 mm. At 500 mm one ring is fully on the detector and a second only clips the corners, which is not enough to constrain a tilt - restricting the q range to the resolved ring recovers 0.06 px. Ice: 5.53 -> 0.29 px on one crystal and 4.71 -> 0.80 px on another, against XDS's refined direct beam. On an ice-free crystal the fit is worse than the header, which is the correct outcome. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |