• I like the idea of having the API used for the most complete file format applicable to the other simpler format.
• I would leave the file-series for later discussion. HDF5 (not h5py) does that not to select a series of files but to split a single file. The concept of a stack of files falls on a different use case. You can have stacks of files using the family driver for instance.
• I'm not sure about the need to implement Dataset, Attribute and File. When converting from specfile or EDF to HDF5 one does not need Attributes for instance, but one certainly needs Groups. If you mean not to raise an exception when trying to access the attributes instead of returning the same thing h5py returns when there are no attributes then I agree.
• If I am wrong, and one needs to implement the attributes when doing a hypothetical conversion, then the attributes have to be implemented.

from silx.

Slides of presentation: silx-io.pdf

from silx.

Summary

• The proposal to access SPEC files in the same way as HDF5 files was well received
• The most repeated word from the meeting participants was "official":
  • Official SPEC to NeXus converter
  • Official layout of ESRF NeXus files

from silx.

The HDF5 and SPEC file unification seems to have happened and the HDF5 widget is taking care of it.

That widget should also be able to achieve the same with 2D images via FabIO. Should we close this issue (eventually replacing it by a more dedicated one to images)?

from silx.

On Tue, 20 Sep 2016 07:51:56 -0700
V. Armando Solé [email protected] wrote:

The HDF5 and SPEC file unification seems to have happened and the HDF5 widget is taking care of it.

That widget should also be able to achieve the same with 2D images via FabIO. Should we close this issue (eventually replacing it by a more dedicated one to images)?

Makes sense to me.

Jérôme Kieffer
tel +33 476 882 445

from silx.

Few comments:

• Our binding only concern input
• Maybe we have to discuss about the fabio->h5 binding
• I created a method load_file_as_h5py(filename). It would be nice to expose it in the io module

What i have about that is quite stable now.
Then I can create a PR containing that. It will make the merge of the hdf5widget PR easier.

from silx.

Yes and no. We also contemplate the possibility to export dictionaries in other formats with HDF5 among them but I get your point and yes, we have to clarify output. Concerning writing of HDF5 files we are currently relying on h5py and writing of SPEC files is something I am not sure we want to support (to be discussed). I suppose that for image formats other than TIFF or EDF out best approach would be to use FabIO and, if FabIO is present, then to use FabIO for those too. My personal taste is to export in few but widespread formats (HDF5, TIFF and CSV) leaving more specialized formats to dedicated packages (FabIO, SOLEIL's converters, ...)

from silx.