nxmx: handle variants and weights #549
Comments
phyy-nx
added a commit
that referenced
this issue
Sep 10, 2022
This is mostly a port (copy) of the spectrum reading code from FormatNexus. I imagine we'll want to eliminate one of the two copies at some point. Includes fixes for non-contiguous masks, caching, tests, and a fix for FormatNexus which caused an off-by-one pixel read error for detector positions. Details: * Move file handle caching to the start method. Needed since new implementation of beam/spectra needs access to the file handle outside of get_raw_data * Update xfailing test of JF16M data to AssertionError test now that it reads the JF16M data using FormatNXmx, but there is a one pixel offset compared to FormatNexus * Switch to using pint * Bugfix in FormatNexus: remove extra pixel offset in fast direction. There were two problems when constructing the panel object as a leaf of the detector hierarchy using the fast_pixel_direction NeXus field. The fast and slow directions are ready out correctly, but the origin was read out using get_cumulative_change_of_basis in order to include any offsets. However, since the pixel size is the value of this field, it was included as an offset, leading to an extra pixel added in the fast direction. Additionally, get_cumulative_change_of_basis relies on the equipment_component chain, which fast_pixel_direction doesn't use, so only the fast_pixel_direction offset was picked up. This is why there isn't an extra pixel in the slow direction. Fix is to not include fast_pixel_direction field value when reading out the offset and to explicitly also read the slow_pixel_direction offset. * Mark test as passing. Off-by-one error fixed in in FormatNexus * Include the offsets in fast and slow pixel direction. (these are usually 0) * Need to add unit conversion * Handle deprecation for weight vs. weights. See nexusformat/definitions#837 * Add tests for FormatNXmx reading spectra. Uses the in memory version of testing. Tests both a single spectra for a dataset and a set of 3 spectra using variants derived from calibrated energies. * Add comment pointing to new issue #549 Co-authored-by: Graeme Winter <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As discussed in DIALS core, it would be good if the nxmx class model could natively understand if a given NeXus field has _weights as a matching item, or if it has an attribute named variant with a pointer to another key. That would allow more general interrogation of data variants and weights, and replace some of the custom handle reading that #538 introduces.
The text was updated successfully, but these errors were encountered: