h5web icon indicating copy to clipboard operation
h5web copied to clipboard

[NX] Support nD scatter plots

Open loichuder opened this issue 1 year ago • 2 comments

According to new NeXus recommendations, AXIS_indices attribute should now be added to NXdata group as a way to properly assign an axis to a signal dimension (rather than relying on the order of the axes attribute).

See the example 1. at https://hdf5.gitlab-pages.esrf.fr/nexus/nxdata_axes/classes/base_classes/NXdata.html

Note: This also opens the way for more complex plots with e.g. multiple axes for the same dimensions (example 2) or axes spanning multiple dimensions (example 3). The latter would be a way to properly define scatter plots.


I won't hide that I have an interest in this since we will use AXIS_indices spanning multiple dimensions when saving processed data and would like to have the corresponding scatterplot displayed.

loichuder avatar Jun 12 '23 15:06 loichuder

Next step would be to understand a bit better how AXIS_indices works; how the axis dataset is structured and mapped; how to deal with various uses/misuses of AXIS_indices; etc. The feature seems very broad, so we need to define the scope a bit better.

axelboc avatar Jun 13 '23 09:06 axelboc

I've renamed this issue to focus on the underlying use case, which is basically to support stacks of scatter plots.

For context, currently, the following code is used to decide that an NXdata group supports the NX Scatter visualization:

axisDatasets.length === 2 && axisDatasets.every((d) => d && hasNumDims(d, 1))

... which basically means that the @axes attribute must declare exactly two 1D datasets (e.g. ["X", "Y"] where both X and Y have only one dimension).

This works great for simple 1D cases (cf. /nexus_entry/scatter in demo) but the complexity increases drastically when dealing with nD signals and axes. This is what the AXIS_indices convention was trying to address, but it doesn't help viewers like H5Web understand how the data is really meant to be plotted.

Where we go from here is still an open question. We considered relaxing the condition above to cover more strictly defined cases, but this would add yet another implicit convention, which does not seem like the right way forward.

@loichuder (and others) suggested introducing an attribute called SILX_scatter (in line with the existing SILX_style attribute) to allow describing scatter plots explicitly, which could take the following shape:

{ 
  "x": "A0", // dataset to use as X coordinates
  "y": "A1", // dataset to use as Y coordinates
  "slice": [0] // dimension(s) on which the user should be able to slice
}

axelboc avatar Jul 20 '23 12:07 axelboc