... | ... | @@ -16,11 +16,18 @@ As explained in the [documentation](http://www.silx.org/pub/nabu/doc/processing_ |
|
|
* It must be implemented as a class, possibly inheriting from a base class like `CCDProcessing` or `SinoProcessing`.
|
|
|
* The initialization should only setup parameters for the underlying processing.
|
|
|
* As a general rule, **the initialization should avoid allocating memory** when possible. Allocating several images and 2D FFT plans is fine. 3D data volumes, likely to be "big", should be created only as a last resort - see for example the mechanism of `nabu.cuda.processing.CudaProcessing`.
|
|
|
* The class is then executed on data satisfying the initialization parameters (shape, dtype, etc).
|
|
|
* The class is then executed on data satisfying the initialization parameters (shape, dtype, etc). It raises an error if the input data has unexpected properties.
|
|
|
|
|
|
### Unit tests
|
|
|
|
|
|
Each processing feature should come with a unit test. Unit tests are located in the same module as the processing feature. For example, unit tests for pre-processing are in `nabu.preproc.tests`.
|
|
|
Each processing feature should come with a unit test.
|
|
|
|
|
|
* Unit tests are located in the same module as the processing feature. For example, unit tests for pre-processing are in `nabu.preproc.tests`.
|
|
|
* The feature is tested against a reference implementation (ex. tomopy). This reference implementation can either be put in `nabu.thirdparty` or in the unit test file itself if not needed elsewhere.
|
|
|
|
|
|
The unit test is likely to need data. There are two options:
|
|
|
- The data can either be created (synthetic data). In this case, it must be created in a way that the result is exactly known and reproducible (see the flatfield tests)
|
|
|
- Or, the data can be "real data" (with proper permissions). It is hosted on "edna-site", and must use `nabu.testutils.get_data` (relying on `silx.resources.ExternalResources`).
|
|
|
|
|
|
|
|
|
|
... | ... | |