2 Commits
Author SHA1 Message Date
leonarski_fandClaude Opus 5 28f222f51d marCCD: take the distance from the start/end pair when the first field is zero
Four of the twelve marCCD sets in the new corpus were refused with "states no
detector distance". Their headers carry xtal_to_detector (offset 640) as zero and
the real distance only in start_xtal_to_detector and end_xtal_to_detector - 70, 170
and 200 mm on three BESSY Rayonix MX-225 sweeps, against a set where all three
fields agree at 300 mm. Reading the first field alone is what refused them.

The guard itself was right: a distance of zero collapses every resolution and every
scattering vector, so refusing beats processing silently. It just fired on data that
does state a distance, in the field the format also defines for it.

With the fallback, all three process de novo and match their depositions - P2_1 at
cell 0.06%, I422 at 0.40%, P1 at 0.07% - and each reaches finer than its deposited
resolution (0.889 A against 1.09, 1.440 against 1.69, 1.757 against 1.93).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 06:39:39 +02:00
leonarski_fandClaude Opus 5 a1889c45e9 rugnux reads marCCD sweeps natively
A decade of deposited CCD data is archived as marCCD - what Rayonix MX-series and
mar Mosaic detectors write - and rugnux could not open any of it. reader/ had two
formats, NXmx/HDF5 and PILATUS miniCBF, and rugnux_cli dispatched on the one
CanRead(); this adds the third.

The format needs no new dependency: a marCCD file is an ordinary uncompressed TIFF
whose 3072-byte instrument header sits in the gap between the TIFF header and the
pixels, so libtiff - already fetched for JFJochPreview in every build mode - reads
the image, and the header is a fixed-offset block of little-endian int32.

Two things differ from the miniCBF path and are worth naming:

* The pixel size is NOT rounded to whole micrometres. A PILATUS pixel is exactly
  172 um so the existing reader can afford lround(); a MAR300 pixel is 73.242 um,
  and rounding it to 73 is a 0.33% scale error on every cell edge reported.
* The sweep template is the last run of digits in the whole file name rather than
  in the stem, which covers both schemes these detectors use - a numbered stem
  (xtal_1_00042.mccd) and the frame number as the extension (D1.042).

A CCD frame marks no untrusted pixels, so the sweep starts with nothing masked, and
the format has nowhere to state the rotation axis' direction, so the run settles its
sign from the data exactly as it does for a miniCBF carrying no axis table.

Measured on one deposited 300-frame Rayonix MX-300 sweep, de novo with no flags:
100% indexing, the deposited point group, cell within 0.045%, 99.5% complete at
multiplicity 3.4, in 26 s. The chosen sweep is confirmed against the instrument
header before it is opened, so a directory of ordinary TIFFs is refused rather than
read with a pixel size of zero - a unit test covers that, both naming schemes, and
the geometry conversion.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 19:31:58 +02:00