The ordered sequence of processing modules operating on an input file to generate an output image is known as the “pixelpipe”.

Die Reihenfolge in der Pixelpipe wird grafisch durch die Reihenfolge dargestellt, in der die Module auf der Benutzeroberfläche angezeigt werden: Die Pixelpipe beginnt mit einem RAW-Bild unten in der Modulliste und wendet die Dunkelkammer-Module schrittweise an, Ebene für Ebene von unten nach oben, bis oben in der Liste das vollständig bearbeitete Bild ausgegeben wird.

Hinweis: Die Reihenfolge, in der die Dunkelkammer-Module ausgeführt werden, ist gleich der Reihenfolge, wie sie auf der Nutzeroberfläche angezeigt werden. Das Ändern der Modulereihenfolge auf der Nutzeroberfläche ändert auch die Bildbearbeitung.

Module order and workflows

Die Reihenfolge, in der die Module in der Pixelpipe abgearbeitet werden, wurde sehr sorgfältig ausgewählt, um die beste Ausgabequalität zu erzielen. In früheren Versionen von Ansel war es nicht möglich, die Reihenfolge der Module zu ändern. Es gibt jedoch eine Reihe spezifischer Fälle, in denen das Verschieben der Module in der Pixelpipe sinnvoll ist.

Die szenenbezogene Bearbeitung versucht, so viele Operationen wie möglich in einem linearen RGB-Farbraum auszuführen, und nur am Ende der Pixelpipe die Tonwerte in einer nicht-linearen Dynamikkompression an ein Ausgabemedium anzupassen. Vorteilhaft ist dabei für die Transformationen die Verwendung eines physikalisch realistischeren Farbraums gegenüber der früheren anzeigebezogenen Bearbeitung, die Operationen in einem nicht-linearen, auf Wahrnehmung basierten Farbraum ausführt. Wenn physikalische Realitäten höher als wahrgenommene Realitäten gewichtet werden, vereinfacht dies stark die Entwicklung von vorhersagbaren Bearbeitungsalgorithmen mit minimalen Artefakten.

Das folgende Schaubild soll dir helfen, die Unterschiede zwischen diesen Abläufen zu verstehen:

![scene-referred and display-referred modules]../../../the-pixelpipe-and-module-ord../../../scene-display-workflows.png)

  1. Scene-referred modules process linear data that is proportional to the amount of light collected by the camera at the scene. The dynamic range of an image in the scene-referred section of the pixelpipe is often larger than that of the display medium.

  2. At some point in the pixelpipe, these pixel values are compressed by a non-linear tone mapping operation into a smaller dynamic range more suitable for display on a monitor or a print.

  3. The remaining modules operate in the non-linear display-referred section of the pixelpipe to produce the final output image.

Changing module order

Es wird aus verschiedenen Gründen empfohlen, die Reihenfolge innerhalb der Pixelpipe nicht zu ändern:

  • The sequence of modules has been selected with great care in order to give highest output quality. Changes to the sequence often worsen the result rather than improving it.
  • Some processing modules simply don’t make sense if they are shifted in the pixelpipe. For example, highlight reconstruction needs to be performed on raw data before demosaic, which itself needs to be performed before any input color profile can be applied. For this reason it is still not possible to move some of the modules that are placed early in the pixelpipe.
  • Most processing modules are designed to work within a specific color space (see the color management section for more details). Full flexibility would require modules to support different parallel algorithms depending on the color space they are working in, which would drastically increase complexity.

Despite the general recommendation to leave the pixelpipe order alone, it is possible to move modules within the pixelpipe from the darkroom module-order graph. Open it from the node-graph button in the darkroom toolbar, then drag and drop modules directly in the graph to a new location. This should only be done by experienced users who understand the impact this will have on the image.

The graph popup provides a scrollable left-to-right view of the pipeline, from the base image to the screen output. It shows:

  • The current execution order of visible modules,
  • The active color-space lifecycle across the pipeline,
  • The input/output runtime descriptors for each module,
  • Raster-mask dependencies between producer and consumer modules,
  • The module-order presets toolbar, used to add presets, reset the order, or apply an existing preset.

Modules that cannot cross ordering fences are constrained by the same rules as the processing pipeline itself, so impossible moves are prevented in the graph.

The module order can be manually changed back to either the v3.0 or legacy versions using the module order popup, which can also be used to define your own custom module order presets.