Der aktuell einzige projektintern normative technische Ausführungsstand ist ATLAS Clarus Workflow v3.4.0, freigegeben am 3. August 2026. Er ersetzt v3.3.0 und bindet die technische Ausführung an den dokumentierten aktiven Atlas-Master.

Normativ definiert sind insbesondere die RGB-only-Ermittlung der Quellidentität, das Einfrieren der source_atlas_row_id, die beiden Δλ-Betriebsarten POSTHOC und ACTIVE, der RGB_TOP_2-Kandidatenkorridor für die aktive Produktionsauswahl, die getrennte Speicherung von Quell- und Produktionsidentität sowie die nachgelagerte Rolle von ICC und Delta E.

Experimentelle Schutzmechanismen wie der Atlas-Bound Protection Marker Workflow besitzen nicht denselben Status. RBSCA ist als Discussion Draft / Technical Whitepaper dokumentiert. Erweiterungen wie Appearance Monitoring, Supplier-/Batch-Lock oder Recipe Lock sind derzeit Forschungs-, Engineering- oder strategische Entwicklungsrichtungen, soweit keine eigene freigegebene normative Spezifikation vorliegt.

Wichtig: „Normativ“ bedeutet hier projektintern verbindlich – nicht ISO-, DIN-, Fogra- oder anderweitig extern standardisiert.

Die source_atlas_row_id wird ausschließlich aus dem dokumentierten 8-Bit-sRGB-Wert des Originalpixels und den RGB-Werten der gültigen Atlaszeilen bestimmt.

Berechnet wird die ganzzahlige quadrierte RGB-Distanz:

d²_RGB = (Rs − Ri)² + (Gs − Gi)² + (Bs − Bi)²

Gewählt wird die Atlaszeile mit der kleinsten Distanz. Bei exaktem Gleichstand entscheidet deterministisch die kleinere atlas_row_id.

Ausdrücklich keinen Einfluss auf diese Quellidentität haben CIELAB, ΔE76, ΔE94, CMC, CIEDE2000, HLC-Abstände, Δλ, ICC, CMYK, GamutMap sowie Material- oder Profilzulassungen.

Die source_atlas_row_id dokumentiert, welche Atlasreferenz dem ursprünglichen Pixel nach der festgelegten RGB-only-Regel entspricht.

Die production_atlas_row_id kann in der aktiven Δλ-Betriebsart davon abweichen. Sie beschreibt dann, welche der zwei RGB-nächsten Referenzen anhand des kleineren |Δλ| für die weitere Produktionskette gewählt wurde. Die ursprüngliche Source-ID bleibt erhalten.

Der praktische Vorteil ist die Rückverfolgbarkeit: Herkunft und Produktionsentscheidung werden nicht miteinander vermischt. Dadurch lässt sich später nachvollziehen, ob eine Abweichung bereits bei der ursprünglichen Referenzierung bestand oder erst durch Produktionsauswahl, ICC-Profil oder Druckbedingung entstanden ist.

Im aktuellen Workflow sind lambda_v2_nm und lambda_ee_nm dokumentierte Eigenschaften der Atlasreferenzen. Definiert ist außerdem:

delta_lambda_nm = lambda_v2_nm − lambda_ee_nm

Im POSTHOC-Modus wird Δλ beschrieben und statistisch ausgewertet. Im ACTIVE-Modus besitzt |Δλ| eine operative Auswahlfunktion innerhalb des fest definierten RGB_TOP_2-Korridors.

Damit ist die algorithmische Wirksamkeit innerhalb dieses Workflows dokumentiert. Nicht belegt ist jedoch, dass ein kleineres |Δλ| automatisch eine kleinere ΔE00-Abweichung, bessere visuelle Übereinstimmung, höhere Druckqualität, bessere Metameriestabilität oder größere industrielle Robustheit erzeugt.

Solche Aussagen sind derzeit OFFENE FRAGE / NICHT BELEGT.

Ein wichtiger Konflikt betrifft den Begriff λ*. Ältere RBSCA-Texte verwenden λ* teilweise als allgemeinen spektralen Prozessdescriptor oder „edge locator“. Der aktuelle ATLAS-Clarus-Workflow arbeitet dagegen konkret mit den Masterfeldern lambda_v2_nm, lambda_ee_nm und delta_lambda_nm. Diese Begriffe sollten deshalb nicht ohne Definition gleichgesetzt werden.

Ein zweiter Konflikt betrifft die Rolle von Δλ. Frühere Texte behandelten Δλ teilweise ausschließlich als nachgelagerte Analysegröße. Workflow v3.4.0 erlaubt zusätzlich eine aktive Produktionsauswahl innerhalb von RGB_TOP_2.

Ein dritter Konflikt ist versionsbezogen: Eine FAQ vom 2. August 2026 bezeichnet noch v3.3.0 als aktuellen Normstand. Seit dem 3. August 2026 ist v3.4.0 der aktive projektinterne Normstand.

Die bisher dokumentierte RGB-Full-Reference-Analyse ist zunächst ein digitaler Nachweis. Auch Vergleiche von RGB_TOP_2 mit größeren Kandidatenräumen sind rechnerische No-ICC-Tests. Sie zeigen algorithmische Funktion und Auswahlwirkung, aber noch keine physische Druckqualität.

Dasselbe gilt für ICC-Vorschauen: Eine digitale Profiltransformation ist keine physische Messung.

Der normative Workflow verlangt deshalb bei fehlender physischer Messung den Status measured_qc_status = NOT_MEASURED. Für Aussagen zu industrieller Reproduzierbarkeit, Materialwechseln, Chargenschwankungen, Metamerie, Langzeitstabilität oder tatsächlichem Reklamationsrisiko sind weitere unabhängige physische Versuche erforderlich.

Der wichtigste Unterschied liegt nicht darin, ICC oder Delta E zu ersetzen. ATLAS Clarus führt vor der Produktionsbewertung eine persistente Referenzidentität ein.

Ein klassischer ICC-Workflow beantwortet primär: Wie wird eine Farbe unter einer bestimmten Geräte- oder Druckbedingung ausgegeben?

Eine Delta-E-Auswertung beantwortet: Wie groß ist der Abstand zwischen zwei definierten Farbwerten?

Das Reference-Bound-Prinzip ergänzt davor die Frage: Auf welche konkrete, versionierte Referenz bezieht sich diese Farbe überhaupt?

ATLAS Clarus trennt deshalb Identität, Analyse, Produktionsauswahl, ICC-Ausgabe und Messkontrolle. Ein Profilwechsel kann neue CMYK-Gerätewerte erzeugen, ohne rückwirkend die ursprüngliche Referenzidentität zu ändern.

Auf Basis der derzeit dokumentierten Evidenz lässt sich keine dieser Erweiterungen seriös als bereits industriell bestätigt bezeichnen.

Als technische Priorisierung erscheinen zunächst Konzepte am besten prüfbar, die eine klare Referenz, einen messbaren Eingang und ein eindeutiges Erfolgskriterium besitzen.

Critical Region Protection ist klar eingegrenzt und gegen manuell bestätigte Referenzmasken prüfbar, bleibt aber experimentell. Batch/Supplier Lock und Recipe Lock sind konzeptionell mit dem Reference-Bound-Prinzip kompatibel, benötigen jedoch industrielle Validierung. Inline Spectral Gate setzt belastbare reale Spektralmessungen und validierte Entscheidungsschwellen voraus. Appearance Passport und FISQ sollten besonders streng darauf geprüft werden, ob zusätzliche Kennzahlen tatsächlich robuste, reproduzierbare Information liefern.

Derzeit gibt es keinen ausreichenden Grund, eine dieser Richtungen pauschal zu verwerfen. Der sinnvolle nächste Schritt ist die kontrollierte Falsifikation ihrer jeweiligen Kernhypothese.

Erstens: ein unabhängiger Reproduzierbarkeitsversuch der Referenz- und Spektralkennwerte in mindestens zwei Laboren, mit mehreren Geräten und Wiederholungsmessungen. Zu prüfen wären Reproduzierbarkeit, Geräteabhängigkeit und Stabilität von λ*_V2, λ*_EE, Δλ und weiteren spektralen Descriptoren.

Zweitens: ein blindes Produktions-A/B mit realen Druckbedingungen. Für dieselben Motive sollten die normative POSTHOC-Variante, die ACTIVE-Variante und eine definierte konventionelle ICC-Baseline produziert und anschließend spektral, per ΔE00, visuell und über Wiederholungen verglichen werden.

Drittens: ein Stresstest der Reference-Bound-Identität. Originalbilder sollten kontrolliert durch RGB ±1/±2, Kompression, Helligkeitsänderungen und unterschiedliche Eingangscharakterisierungen verändert werden. Gemessen werden sollte, wann source_atlas_row_id stabil bleibt und wann sie kippt.

Diese Priorisierung ist ein Vorschlag für die wissenschaftliche Prüfung und keine bestehende Projektnorm.

Für Forschung und industrielle Erprobung besitzt insbesondere die Trennung von Referenzidentität, Produktionsauswahl, ICC-Ausgabe und gemessener Qualitätskontrolle eine klar dokumentierte technische Struktur.

Auch das Zwei-ID-Modell aus source_atlas_row_id und production_atlas_row_id ist als Audit- und Nachweismodell konkret genug, um in realen Produktionsversuchen geprüft zu werden.

Als Forschungsfragen sollten dagegen insbesondere gelten: die metrologische und industrielle Aussagekraft einzelner λ-Descriptoren, die Frage, ob minimales |Δλ| systematisch einen Produktionsvorteil liefert, universelle Entscheidungsschwellen für spektrale Gates, FISQ- und Appearance-Proxies ohne unabhängige physische Validierung sowie automatische Schutzregionen ohne breite Realbildtests.

Für eine mögliche Standardisierung wäre derzeit vor allem die Architektur und Nachweislogik als Diskussionsgegenstand geeignet – nicht die Behauptung, einzelne neue Kennzahlen seien bereits allgemein validierte industrielle Standards.