API: [CCDProcessing.take_logarithm](apidoc/nabu.preproc.ccd.rst#nabu.preproc.ccd.CCDProcessing.take_logarithm) and [CudaLog](apidoc/nabu.preproc.ccd_cuda.rst#nabu.preproc.ccd_cuda.CudaLog)
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)
`Processing` is a class making a specific processing step (ex. `FlatField`). In general, these classes provide a very specific feature (ex. Paganin phase retrieval, Median-clip, ...).
``` note:: The name "Processing" serves as a terminology to distinguish between concepts and Nabu classes. It is not formally enforced by inheritance in the Nabu code, although these classes usually inherit from a "Processing"-like class, like "CCDProcessing", "CudaProcessing", etc.
```
When building an application upon Nabu, these are the last classes to be called, once all the parameters are sorted out.
The typical usage of a `Processing`-like class is
- First instantiate the class with specific options
- Then, Call the main class method
**Example usage**:
```python
# Build a Processing object - it might take some time
F=FlatField(radios,flats,darks)
# Then, perform the processing
F.normalize_radios()# parameters depend on the class implementation, ex. CudaFlatfield
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.
In an application, by contrast, the `Processing` classes (ex. `FlatField`) are part of a wider context (data/GPU contexts have to be re-used, parameters have to be consistent in the whole processing chain, and so on). Therefore, the application is built on top of several `Component` objects, which in turn use the `Processing` objects. A `Component` uses one or more `Processing` class instances, sometimes in loops, for example to manage input/output arrays.
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).
