[viewer] Additionnal plot description for NXdata

[kif]

For SAXS data, user expect their data to be displayed "as usual". I don't want to enforce novice user to perform 5 clicks in menus to ease the acceptance of NeXus format in this community. For this I would need 4 features which are not (yet?) provided by NXdata:

• [ ] display a plot in semi-log -x or -y or in log-log. One could use the NXdata attribute @axis_style=["lin", "log"] for semi-log-y, @axis_style=["log", "lin"] for semi-log-x, ...
• [ ] Display all curves from a 2D dataset tagged with @interpretation="spectrum" using @quotity="all" instead of "one" which would be the current default
• [ ] Display an image using log-scale colormap, for example using the @color_normalization="log"
• [ ] Enforce the colormap when displaying images. Imaging beamlines tend to use greyscale color-maps, while diffraction beamlines prefer coloured images. Being able to enforce the colormap would allor to respect the different communities. The attribute NXdata@colormap="magma" would do the job.

This is more a request for comment ... There are little implementation difficulties.

[vasole]

I am in favor of a more complete description of the representation to be used for each axis and the signal(s). I have foreseen to discuss it at the NIAC but I can also send it to mailing list to fire up the discussion.

[vasole]

I would wait a couple of weeks to see if we get some feedback from https://github.com/nexusformat/NIAC/issues/29

[vasole]

For the time being, reasonable candidates seem to be axes_scale_type and signal_scale_type.

On the point of showing all or one curve, that should be a decision of the viewer. Our viewer could offer to show one curve or all.

[vasole]

OK guys, the NIAC decision is to say nothing about how the data are to be displayed. They limit at what is to be visualized and the annotations. So, we have open bar but we should think a bit about how descriptive we want to be and make sure our specification is ours (sx_wathever?)

[vasole]

@t20100

One nice idea that appeared in the discussion was to use just one attribute (something in the lines of plot_hint) so that the application trying to perform the visualization would not need an ever growing set of attributes and it could just be reactive to the qualifiers it understands ignoring those that cannot.

[t20100]

+1 for a prefix for extension stuff (could be ext_ or addon_ if we don't want to mark it as silx only).

@vasole, what you propose looks like a CSS style sheet string as for Qt widgets. Good point is indeed to avoid having too many attributes, but the down side is to add a parsing of this string to the visualization tool. And anyway, it will have to adapt to new fields.

[vasole]

The attribute could be a variable length string array so that you are free to store a list of strings of variable size therefore allowing to write basically anything.

Other alternative would be just to throw a json string inside the attribute.

[vasole]

On June 2, 2020 meeting we decided to create an NXdata attribute SILX_style containing the plot information. The most urgent information needed is to know if axes are linear or logarithmic or if the colormap normalization is linear or logarithmic.