cansas multid: Difference between revisions
From canSAS
(kick-off the multi-dimensional format) |
(not just XML anymore) |
||
| Line 1: | Line 1: | ||
''Note: please keep discussion content on the [[Talk:cansas_multid | discussion]] page. Your contributions may get moved there anyway.'' | ''Note: please keep discussion content on the [[Talk:cansas_multid | discussion]] page. Your contributions may get moved there anyway.'' | ||
= | = standard for reduced small-angle scattering data with multi-dimensional data = | ||
XML? HDF? Something else? | |||
== Key Points so far == | == Key Points so far == | ||
Revision as of 17:29, 8 May 2008
Note: please keep discussion content on the discussion page. Your contributions may get moved there anyway.
standard for reduced small-angle scattering data with multi-dimensional data
XML? HDF? Something else?
Key Points so far
- with the 1D format agreed, we should look at 2D data
- we should also consider how different we are from NeXus and then why
- We must address data beyond simple 2D detector patterns (multi-dimensional data)
- kinetic/time-resolved stuff (frames, periods, whatever you call them),
- other experiments where data is being collected as a function of some variable (temperature, pH, or whatever)
- quite happy to abandon human-readability ... even prepared to consider binary storage!
- We have benefited a little from [the NeXus] instrument dictionary.
- The time is now ripe to show the use of HDF for storing multi-dimensional data, only using pure HDF5.
- Regarding the cansas1d/1.0 XML format:
- table structure used in the 1D format is quite 'tag-heavy' and just will not extend easily.
- takes a little bit more work to extract the I(Q) data into vectors for use in processing or analysis software.
- For multi-dimensional data in XML, rather than create anew, I chose to model the data structures from a popular commercial application.
