Klar, im Kreis rechnen die nicht. Aber, His Dudeness, vielleicht täuscht die Stellung im Stapel ja darüber, was wirklich passiert...
Überleg mal - wenn zB ein Rotpixel einmal aus WB-Gründen * 0.9 genommen werden muss, dann wg. Lichterretten * 0.6, dann beim de-bayern *1.4, dann aus Farbraumgründen * 1.1; ja mei, diesen 'Stapel' von vier Multiplikationen wird man, wenn das irgend geht, zusammenfassen; das spart Zeit und Rundungsfehler. In diesem Fall würde 'im Stapel vor demosaic' einfach nur bedeuten: bei Änderung von (WB, Lichter, Farbraum) muss neu demosaict werden, und zwar mit anderen Parametern.
Wie gesagt, es ist ein erklärtes Feature von darktable, die Reihenfolge im UI sehen zu können. Es ist darüber hinaus so, dass die Module in der Pipeline alle nur auf ihren Eingagnsdaten (die Ausgabe des vorangegangenen Modusl oder der initiale Datensatz) und mit ihrer jeweils eigenen Menge an Parameter arbeiten. Querbeziehungen wie in deinem Beispiel gibt es daher nicht. Der Quellcode sei mein Zeuge
Was dein Beispiel angeht, ist es ziemlich konstruiert, aber ich bin der Meinung, das eine Zusammenfassung weder eine Effizienzsteiegerung bedeutet, noch eine relevant Vermeidung von Rundungsfehlern, da die dartkable Pipeline vollständig mit einer Fließkomma-Darstellung arbeitet. Und selbst wenn man einige wenige Taktzyklen sparen könnte, wäre es die Sache nicht wert. Solche Querbeziehungen würden die Pipeline einfach nur kompliziert und wenig Modular machen.
Gleichfalls!
