API: [CCDProcessing.Log](apidoc/nabu.preproc.ccd.rst#nabu.preproc.ccd.Log) and [CudaLog](apidoc/nabu.preproc.ccd_cuda.rst#nabu.preproc.ccd_cuda.CudaLog)
### Sinogram normalization
Sinograms can sometimes be "messy" for various reasons. For example, a synchrotron beam refill can take place during the acquisition, and not be compensated properly by flats.
In this case, you can "normalize" the sinogram to get rid of defects. Currently, only a baseline removal is implemented.
Mind that you probably lose quantativeness by using this additional normalization !
Setting `coeff` to zero (default) disables unsharp masking.
## Reconstruction
Tomographic reconstruction is the process of reconstructing the volume from projections/sinograms.
...
...
@@ -107,6 +120,16 @@ The purpose of this class is to quickly reconstruct slices over the three main a
The Reconstructor enables to reconstruct slices/region of interest without reconstructing the whole volume.
## Post-processing
### Histogram
Nabu can compute the histogram of the reconstucted (sub-) volume. As the volume usually does not fit in memory, the histogram is computed by parts, and the final histogram is obtained by merging partial histograms.
API : [PartialHistogram](apidoc/nabu.misc.histogram.rst#nabu.misc.histogram.PartialHistogram) and [VolumeHistogram](apidoc/nabu.misc.histogram.rst#nabu.misc.histogram.VolumeHistogram)
## File formats
### HDF5
...
...
@@ -118,7 +141,7 @@ When a [multi-stage reconstruction](nabu_cli.md) is performed, the volume is rec
### Tiff
Reconstruction can be saved as tiff files by specifying `file_format = tiff` in the configuration `[output]` section.
In the current version (2020.3), tiff support has the following limitations:
Mind that tiff support currently has the following limitations:
- One file per slice
- Data is saved as `float32` data type, no normalization
- No metadata (configuration used to obtain the reconstruction, date, version,...)
...
...
@@ -126,7 +149,7 @@ In the current version (2020.3), tiff support has the following limitations:
### Jpeg2000
Reconstruction can be saved as jpeg2000 files by specifying `file_format = jpeg2000` in the configuration `[output]` section.
In the current version (2020.3), jpeg2000 support has the following limitations:
Mind that jpeg2000 support currently has the following limitations:
- When exporting to `uint16` data type (mandatory for jpeg2000), the normalization from `float32` to `uint16` is done slice-wise instead of volume-wise. This is slightly less accurate.
- Only lossless compression is supported. In the future, compression will be tunable through Nabu configuration.
- No metadata (configuration used to obtain the reconstruction, date, version,...)
...
...
@@ -138,6 +161,14 @@ In the current version (2020.3), jpeg2000 support has the following limitations:
Nabu provides a method to find the half-shift between two images. The center of axial vertical rotation is obtained when the fist image is a radiography at the rotation angle 0 and the second image is given by the radiography at the rotation angle 180 after flipping the image horizontally. The rotation axis position is the center of the image plus the found shift.
Configuration file: section `[reconstruction]`, key `rotation_axis_position`. Values can be:
- A number (known CoR)
- Empty: the CoR is set to the middle of the detector
-`centered` (or `auto`): this searches for a CoR around the center, but does not work for half-acquisition
-`global`: new method, should return a CoR in any setting.
@@ -52,6 +52,7 @@ Each section describe a usual processing step. In the current version, the avail
-`preproc`: phase retrieval, CCD corrections, ...
-`phase`: phase retrieval
-`reconstruction`: tomography reconstruction
-`postproc`: post-processing: histogram
-`output`: output data description
-`resources`: computing resources description
-`about`: extra information about the current configuration file
...
...
@@ -71,6 +72,6 @@ Yes. Nabu is foremost a library, meaning that all its component can be accessed
### Compatibility policy
At this early development stage, it is not entirely clear which keys should be in the configuration file. In the future, some keys might be removed, added, or have their name changed. Also, with new features coming, new keys/sections might appear in the configuration file.
During the development of Nabu, some features will be added, leading to new keys in the configuration file. Besides, some keys might be renamed or even deleted if deemed necessary.
Thus, the configuration file might change according to the version of nabu. For this reason, there is a section `[about]` in the configuration file, which defines a `nabu_version` and a `nabu_config_version`. A given version of the nabu software (`nabu_version`) will be compatible with a certain range of nabu configuration files (`nabu_config_version`).
In any case, **a configuration file from an "old" version of nabu will be supported by newer versions** for some time, with a deprecation warning when using obsolete keys.
Version 2020.4.0 adds a number of features, notably command line tools for manipulating datasets.
``` note:: The changelog is available at https://gitlab.esrf.fr/tomotools/nabu/-/blob/master/CHANGELOG.md
```
## Highlights
This section highlights some of the available [features](features.md).
### Fully automatic center of rotation estimation
Various methods exist for estimating automatically the center of rotation (CoR). Nabu had one, but it did not work for half tomography acquisitions. Another method is now available and should work with any kind of acquisition.
The paramater is `rotation_axis_position` (in section`[reconstruction]`), the value can be:
- A number (known CoR)
- Empty: the CoR is set to the middle of the detector
-`centered` (was `auto`): this searches for a CoR around the center, but does not work for half-acquisition
-`global`: new method, should return a CoR in any setting.
### Histograms
Nabu can now compute a histogram of the reconstructed volume. This histogram can serve for further volume processing (conversion to uint16 for example). The computation is done while the data is still in memory to avoid extraneous disk reads/writes.
The option is available in a new section `[postproc]` with the parameter `output_histogram = 1`.
A command line tool is also available to merge the histogram of multiple volumes: `nabu-histogram <file1> <file2> ... <output>`.
### Use darks/flats from another dataset
Sometimes, flats cannot be acquired properly during an acquisition. In order to still have the ability to reconstruct the data, a common workaround is to use flats from another dataset.
Suppose you want to reconstruct a dataset which does not have flats/darks. In this case, nabu will detect that these images are missing and won't do flat-field correction. However you can force the flat-field normalization with `flatfield_enabled = forced` in the `[preproc]` section, and by providing `processes_file = /path/to/nabu_processes.h5`. This `nabu_processes.h5` file (or `tomwer_processes.h5`) can be generated either by tomwer or nabu.
### Sinogram normalization
A sinogram normalization is now available in the section `[preproc]` : `sino_normalization = chebyshev`. If enabled, each line of the sinogram undergoes a baseline removal. This can be useful to correct a "refill" taking place during the scan. See [this discussion](https://gitlab.esrf.fr/tomotools/nabu/-/issues/118#note_74284) for more details.
### Split a NXTomo file by "z series"
Z-series is the name given to a multi-stage scan, i.e scanning a volume in several stages by moving the sample vertically after each stage (this is different from helical tomography).
For the time being, the CLI tool `nxtomomill` merges everything in a single file.
Projections have a varying "z" identified by the `entry/sample/z_translation` key (in conformity to the Nexus-Tomo standard).
The command line tool `nabu-zsplit` enables to split a file into distinct "z" to reconstruct each volume individually.
``` warning:: This is a temporary solution. This will be natively be handled by nxtomomill in the future.
