A valid NXmx master written outside the DECTRIS toolchain could not be opened. Measured on a
Diamond-written master of a 360 deg EIGER 16M sweep, where the images and the meta file are pure
DECTRIS and only the master is third-party - which is why the two sides disagree on units at all.
Five independent things, of which two were silent:
* The image size came from detectorSpecific/x_pixels_in_detector, a DECTRIS extension rather than
NXmx, so a third-party writer has no reason to emit it. It now comes from the image array's own
shape, as it already did for a VDS master.
* Lengths were assumed to be metres and the units attribute was never read. A pixel size, sensor
thickness or distance stated in millimetres - correct NXmx - was silently a factor of a thousand
out. The unit is now read; an undeclared one still means metres, an unknown one is refused.
* The detector distance can sit in NXinstrument rather than in NXdetector; that is now the last
fallback after the NXmx and the firmware-1.x spellings.
* A pixel mask that is an external link into a file not holding it passed the Exists() check and
then threw on the open. Whether the array is there is now decided by opening it.
* Each data file was re-opened and searched for /entry/data/data, ignoring the path the master's
own link names. A master linking to a plain /data therefore found no images at all - and that
was a warning and exit code 0 over a sweep sitting right there, not an error. The link is now
taken at its word, and a master that links to data files but yields no images is an error.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T3yNBXk4wKdMZy1ak2NY7f
leonarski_fandClaude Opus 5
c9ca7e424a