Commit c4165e72 authored by Pierre Paleo's avatar Pierre Paleo
Browse files

Add doc

parent b4ceafe3
Pipeline #19773 passed with stage
in 1 minute and 39 seconds
......@@ -32,8 +32,10 @@ F.normalize_radios() # parameters depend on the class implementation, ex. CudaFl
- [PaganinPhaseRetrieval](apidoc/nabu.preproc.phase.rst#nabu.preproc.phase.PaganinPhaseRetrieval)
- [Reconstructor](apidoc/nabu.reconstruction.reconstructor.rst#nabu.reconstruction.reconstructor.Reconstructor)
Component
----------
## Component
### Rationale
A `Component` is a wrapper around a `Processing`, whose aim is to make the translation between user parameters and final `Processing` parameters.
For an interactive usage where the data is "ready" and all the parameters are known, it is fine to use `Processing` classes directly. Each feature can be seen as an individual function or class instance.
......@@ -42,3 +44,16 @@ In an application, by contrast, the `Processing` classes (ex. `FlatField`) are p
Conceptually, these are "application components" or "processing pipeline components". A component breaks down in one or several "elementary" Processing steps.
### Behavior
A `Component` object often behaves differently than `Processing` objects:
- On one hand, `Processing` objects can be used to process data independently of eachother
- On the other hand, `Component` objects are designed to be coupled together in a wider context (an application).
For this reason, a component object invariably:
- Take 3D data as an input ([chunks](definitions.md))
- Do the processing **in-place**. **This means that the input data is overwritten**
This behavior is similar to many functions of [tomopy](https://github.com/tomopy/tomopy).
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment