Repository navigation
fix(h5): keep non-uniform float32 image axes with a large origin - #18
Merged
Merged
Conversation
- NeXus and mapped image axes were converted to uniform coordinates when they deviated from even spacing by up to 4 * eps * max|x|, i.e. 4 to 8 ULP of their data type: a float32 axis such as [1e6, 1e6 + 1, 1e6 + 2.25, 1e6 + 3] was imported with 1e6 + 2 as third coordinate. Axes are now converted only if they deviate by at most 2.5 ULP of their stored data type (UNIFORM_AXIS_TOLERANCE), evenly spaced values computed in their storage precision deviating by up to about 2 ULP; other axes keep their stored coordinates exactly. - The maximum deviation of each axis converted to uniform coordinates is recorded among the experimental_source conversions. - Documented the criterion in the HDF5 guide, the API reference and the release notes, with French translations. Assisted-by: Claude Opus 5.5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
_is_uniform()(introduced in 589aafa, part of #13, unreleased 1.1.0) accepted a deviation from even spacing of4 * eps * max|x|, i.e. 4 to 8 ULP of the axis data type. A genuinely non-uniformfloat32axis with a large origin was therefore flattened to uniform coordinates, silently altering the spatial calibration of imported NeXus images and mapped (HDF5 profile) images.Reproduced case:
float32axis[1e6, 1e6 + 1, 1e6 + 2.25, 1e6 + 3](steps 1, 1.25, 0.75; deviation 4 ULP = 25 % of the step) was imported as uniform, the third coordinate becoming1e6 + 2.Fix
sigimax.h5.nexus.UNIFORM_AXIS_TOLERANCE), evaluated at the largest axis magnitude (float64 ULP for non-float axes). Otherwise the stored coordinates are kept exactly.experimental_sourceconversions, e.g.axis 'x': uniform coordinates (max deviation 0.000195, 0.4 ULP of float32). Lossless conversions (zero deviation, dimensions without axis) are not recorded.Rationale for 2.5 ULP
Measured on 3000 random evenly spaced
float32axes:linspace, decimation and bin edges → centers deviate by at most 1.0 ULP;float32arithmetic (x0 + i * dx) by at most 2.1 ULP. A step-relative guard (e.g. ≤ 1 % of the step) was considered and rejected: it would have turned about 15 % of genuinely uniformfloat32axes (small step relative to the origin, e.g. 8000 eV / 0.1 eV) into non-uniform coordinates, which Sigima binning and resampling refuse.Known limit: a genuinely non-uniform axis deviating by ≤ 2.5 ULP of its storage type cannot be distinguished from a uniform axis computed in that type; it is converted, but its deviation is now recorded.
Tests
test_nxdata_image_axis_precision:float32linspace(8000, 8100, 1001)→ uniform, deviation recorded (0.4 ULP);float32arithmetic axis-50 + i * 0.37(1.87 ULP) → uniform, guarding against an over-tight criterion.The new test fails on the previous implementation.
sigimax/tests/hdf5: 309 passed; Ruff and Pylint clean; Sphinx gettext build with-WOK.