tomoscan merge requestshttps://gitlab.esrf.fr/tomotools/tomoscan/-/merge_requests2023-11-07T12:00:37+01:00https://gitlab.esrf.fr/tomotools/tomoscan/-/merge_requests/165Draft: Additional writers features2023-11-07T12:00:37+01:00Pierre PaleoDraft: Additional writers features[nabu writers](https://gitlab.esrf.fr/tomotools/nabu/-/blob/master/nabu/io/writer.py?ref_type=heads) uses a number of wrappers on top of tomoscan to make it usable from nabu.
Namely:
- `RawVolume`:
- support volumes appending
...[nabu writers](https://gitlab.esrf.fr/tomotools/nabu/-/blob/master/nabu/io/writer.py?ref_type=heads) uses a number of wrappers on top of tomoscan to make it usable from nabu.
Namely:
- `RawVolume`:
- support volumes appending
- make sure that both `.info` and `.xml` are produced
- make sure the metadata is the same as the one produced by PyHST2
- `HDF5Volume`:
- write partial reconstruction files with a file suffix (not supported by HDF5Volume)
For `HDF5Volume`, nabu needs a the `start_index` parameter for the sub-volume files. Also, a sub-directory is creating to contain the partial files.
For example, if `file_prefix="recons"` and `output_dir="/path/to/out"`:
```
/path/to/out/recons.h5 # final master file
/path/to/out/recons/
/path/to/out/recons/recons_00000.h5
/path/to/out/recons/recons_00100.h5
```https://gitlab.esrf.fr/tomotools/tomoscan/-/merge_requests/86Draft: add `z_nm_pattern`2023-09-26T11:48:06+02:00paynoDraft: add `z_nm_pattern`# overview
Add a new name file convention according to the frame z position instead of the index. For now we expect z to be provided in nano meter.
pattern looks like: `"{volume_basename}_{z_mm}mm{z_um_zfill3}um{z_nm_zfill3}nm.{data_ex...# overview
Add a new name file convention according to the frame z position instead of the index. For now we expect z to be provided in nano meter.
pattern looks like: `"{volume_basename}_{z_mm}mm{z_um_zfill3}um{z_nm_zfill3}nm.{data_extension}"`
The behavior is defined in `VolumeSingleFrameBaseZNM`
This feature has been implemented as extension of the the three single frame volume scheme we have at the moment: `edf`, `tiff` and `jp2k`.
As urllib prevent from using `_` we went for `edf+znm`, `tiff+znm` and `jp2k+znm` that I think are convenient enough.
# notes
+ close #56
# bottlenecks
## z random or decreasing values
for now it save the volume according to z which is provided by `_z_nm_pos` and set from `set_z_nm_positions`. But nothing prevent from setting unordered z values or decreasing z values. But the reading and definition of `data` will always be made with z increasing values.
> To avoid this we are now checking z values re providing 'decreasing'.paynopayno