Skip to content

Read datasets stored as the native HDF5 complex datatype - #2036

Open
NAThompson wants to merge 1 commit into
silx-kit:mainfrom
NAThompson:feat/native-complex-datatype
Open

Read datasets stored as the native HDF5 complex datatype#2036
NAThompson wants to merge 1 commit into
silx-kit:mainfrom
NAThompson:feat/native-complex-datatype

Conversation

@NAThompson

Copy link
Copy Markdown

HDF5 2.0 added H5T_COMPLEX (class 11), storing interleaved real and imaginary components of a base float. It is what h5py writes given a COMPLEX_IEEE_* type, and what HDF5 2.0 writers will produce in place of the legacy {r, i} compound H5Web already reads. H5T_CLASS stopped at ARRAY = 10, so such a dataset fell through parseDType to unknownType() and offered no visualisation at all.

Both components are the same float and each is half the itemsize, so the component type needs no metadata of its own. The values do need converting: h5wasm exposes the interleaved layout directly, whereas H5Web's model is one [real, imag] pair per element. Attributes need the same by a separate route, arriving through Attribute.json_value as a plain array.

The reader side is usnistgov/h5wasm#140. packages/h5wasm/package.json pins h5wasm 0.10.3, which predates it, so nothing exercises this in CI until that lands and the pin is bumped. Checked by hand against a local h5wasm build and a file written by h5py.

HDF5 2.0 added `H5T_COMPLEX` (class 11), storing interleaved real and imaginary
components of a base float. It is what h5py writes given a `COMPLEX_IEEE_*`
type, and what HDF5 2.0 writers will produce in place of the legacy `{r, i}`
compound H5Web already reads. `H5T_CLASS` stopped at `ARRAY = 10`, so such a
dataset fell through `parseDType` to `unknownType()` and offered no
visualisation at all.

Both components are the same float and each is half the itemsize, so the
component type needs no metadata of its own. The values do need converting:
h5wasm exposes the interleaved layout directly, whereas H5Web's model is one
`[real, imag]` pair per element. Attributes need the same by a separate route,
arriving through `Attribute.json_value` as a plain array.

The reader side is usnistgov/h5wasm#140. `packages/h5wasm/package.json` pins
h5wasm 0.10.3, which predates it, so nothing exercises this in CI until that
lands and the pin is bumped. Checked by hand against a local h5wasm build and a
file written by h5py.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant