Description / Goal
- define dark, ref, projection and returns by there group names (in this case 'titles' will be ignore) For this feature we will handle urls. But we expect to have path pointing to HDF5Group and no dataset. So (of course) slices will be rejected.
- add an option to provide a configuration name to
nxtomomill h52nx. In this case it 'overwrite' the settings.py file (for the run) and no other options should be provided
- create some utils command to generate configuration file
input example files
- default configuration file: default.cfg
create the io module
HDFConfigclass: used to store the configuration for the conversion
HDF5ConfigHandler: define a set of function to filter inputs from the HDF5config: for example when titles are provided and some node names for dark, flat... are provided too. Insure also the validity of a configuration
acquisitionmodule and the hdf5converter.
handle a configuration file (basically overwrite the settings.py file).
nxtomomill h52nx --config [config_file]
create a quick start for h5 to generate a configuration file
nxtomomill h5-quick-start output_file.cfg
- add options
ignore_sub_entriesto DataUrl in order to handle input file as well.
should handle input file from different files. Urls can be provided or just group files.
update training to present this
add test when using configuration with ̀
test the Standard acquisition
deprecate the API of
add a "initialization" entry which could contain
check slices are handled or raise an error
handle copy parameter
add an example copying dataset and not and check if a copy is made
updating design: for now design is: we open a file and we browse it and create the .nx at the same time. it might be wiser to create an uri during preprocessing for each parameter of the
x_translation_uri... and used those during the write step. This would be more convenient for copying frame dataset (we could only copy and update the uri) which would bring visiblity to the existing code. This could also add flexibility to the
AcquisitionBase. But as nxtomomill might integrate other acquisition style way different this is not the time to go for this kind of refactoring I guess.
INFO (how to use...)
This PR add an io module close #53 (closed)
Any warning ?
the "data_scans" values from the
FRAME_TYPE_SECTION section should be provided with indentation (at least one empty space. Otherwise they will be ignored by configparser.
associated materials (screenshot, test scripts...)
user can now provide a list of "FrameGroup" that refer to a scan and which should fit a type. Those can only be provided by the configuration file. The dedicated section looks like:
[FRAME_TYPE_SECTION] # optional section # allows to define scan to be used for nxtomo conversion # the sequence order will follow the order provided. # list of scans to be converted. frame type should be provided for each scan. # expected format is: # data_scans = ( # (frame_type=projections, entry=silx:///path/to/file?/path/to/scan/node, copy=true), # (frame_type=projections, entry=/path_relative_to_file), # ) # * `frame_type` (mandatory): values can be `projection`, `flat`, `dark`, `alignment` or `init`. # * `entry` (mandatory): dataurl with path to the scan to integrate. if the scan is contained in the input_file then you can only provide path/name of the scan. # * copy (optional): you can provide a different behavior for the this scan (should we duplicate data or not) # more details are available here: todo data_scans = ( (frame_type=init, entry=1.1), (frame_type=dark, entry=2.1), (frame_type=flat, entry=3.1), (frame_type=projection, entry=4.1), (frame_type=flat, entry=5.1), (frame_type=projection, entry=6.1), (frame_type=alignment, entry=7.1), ) # you can duplicate data inside the input file or create a link to the original frames. in this case you should keep the relative position of the files default_data_copy = False