Vielleicht trage ich damit ja Eulen nach Grafiker-Athen, aber mir ist vor wenigen Monaten erstmals aufgefallen, dass manche PDFs in Vorschau und in Acrobat (inklusive Acrobat Reader) unterschiedlich aussehen, was die Farben betrifft. Dabei hatte, gemessen an der Quelle, aus der das PDF generiert wurde, mal Vorschau recht, mal Acrobat und manchmal beide nicht. Das hat mich ziemlich geschockt, denn bis dahin war ich wie selbstverständlich davon ausgegangen, dass jeder, der ein PDF von mir in die Hände bekommt, das in Vorschau farblich korrekt aussieht, dieselben Farben sehen (oder drucken) wird wie ich, auch wenn er Acrobat (Reader) benutzt.

Also habe ich versucht herauszufinden, wie so etwas trotz Farbmanagement möglich ist. Die Antwort: Es gibt zwei unterschiedliche Stellen, an denen Farbräume in PDFs definiert werden können. Zum einen kann jedem farbigen Objekt (Pixelbild oder Vektorgrafik) ein ICC-Farbprofil zugeordnet werden. Zum anderen kann das PDF einen sogenannten Output Intent (deutsch Ausgabebedingung, eine wie so oft falsche Übersetzung) enthalten, der einen Farbraum definiert und optional das entsprechende ICC-Farbprofil einbettet. Dabei sind beliebige Kombinationen denkbar (Farbräume nur in Objekten definiert, nur im Output Intent, in beidem, dabei der Output Intent mit oder ohne eingebettetes ICC-Farbprofil) und das Problem ist, dass Vorschau und Acrobat diese Kombinationen unterschiedlich auswerten. Dazu kommt dann als weitere Variable auch noch, ob das PDF einem Standard (PDF/A oder PDF/X) entspricht oder nicht. Das totale Chaos, das der Idee des Farbmanagements völlig zuwiderläuft, aber leider bittere Realität ist.

Wichtige PDFs habe ich seitdem immer in Vorschau und Acrobat Reader mit dem Digital Color Meter kontrolliert. Aber was kann man machen, wenn in einem von beiden (oder gar beiden) die Farbe nicht stimmt? Hier sind zwei Fälle zu unterscheiden: PDFs, die zum Betrachten auf einem Bildschirm gedacht sind und PDFs, die als Druckvorlage dienen sollen.


1. PDFs zum Betrachten auf einem Bildschirm

PDFs, die zum Betrachten auf einem Bildschirm gedacht sind, sollten die Farben in einem RGB-Farbraum, standardmäßig sRGB, definieren. Die in jedem macOS-Programm zumindest über den Druckdialog vorhandene PDF-Exportfunktion tut genau dies und Vorschau stellt das dann stets 100% korrekt dar – Acrobat aber nicht unbedingt. Hier gibt es aber eine sehr einfache Lösung (ab macOS 12): Man sichert das PDF im PDF/A-Format (macOS verwendet PDF/A-2b); das hat in all meinen Tests für identische (und korrekte) Farbwiedergabe in Vorschau und Acrobat Reader gesorgt.


2. PDFs als Druckvorlage

Hier ist die Situation leider ungleich komplizierter und nachgerade chaotisch. PDFs als Druckvorlage müssen in der Regel, um unliebsame Überraschungen zu vermeiden, die Farben in einem CMYK-Farbraum definieren, hierzulande meist ISO Coated v2 (ECI). Je nachdem, wie ein solches PDF generiert wurde, können hier alle denkbaren Kombinationen von Objekten zugeordneten Farbräumen und Output Intent auftreten.

Die folgende Grafik zeigt anhand einer willkürlichen Beispielfarbe die Originalfarbe (sRGB 99 61 45) in der mittleren der 3 Farb-Zeilen und die vom Bildschirm aus Vorschau (= Preview, oben) und Acrobat (unten) abgenommene CMYK-Farbe ebenfalls in sRGB:



Unveränderte (≤ ±1 pro Komponente) sRGB-Farbwerte sind grün dargestellt, sRGB-Farbwerte mit leichten Abweichungen orange und drastisch abweichende, völlig unbrauchbare sRGB-Farbwerte rot.

In der obersten Titelzeile sind Spalten grün markiert, wenn die beiden sRGB-Farbwerte für Vorschau und Acrobat grün sind, orange, wenn sie mindestens orange mit ganz geringen Abweichungen sind und hellorange, wenn sie mindestens orange mit etwas größeren Abweichungen sind.

Wie man auf einen Blick sieht, geben nur in einem einzigen Fall (Spalte 2) Vorschau und Acrobat die Farben korrekt wieder: wenn ausschließlich den Objekten ein Farbraum zugeordnet wird und es keinen Output Intent gibt. Das heißt allerdings auch, dass das PDF nicht dem PDF/X-Standard genügen kann, der einen Output Intent vorschreibt; das kann dann andere Probleme beim Druck ergeben (Transparenzen usw.).

Will man ein PDF/X-konformes PDF im ISO Coated v2 (ECI)-Farbraum, so bleibt nur Spalte 10 mit zumindest annähernd korrekter Farbwiedergabe in Acrobat.

Vorschau ignoriert offenkundig den Output Intent und ist auf das den Objekten zugeordnete und eingebettete ICC-Farbprofil angewiesen; fehlt das, so interpretiert Vorschau die CMYK-Werte stets als dem Allgemeinen CMYK-Farbprofil von macOS zugehörig; das ergibt dann den entsprechenden sRGB-Wert 83 57 45 (Spalten 1, 4, 8 und 9). Acrobat hingegen bevorzugt den Output Intent und zeigt korrekte Farben dann an, wenn der definiert ist (Spalte 4).

Man könnte meinen, man ginge auf Nummer Sicher, wenn man einfach stets die den Objekten zugeordneten Farbprofile und den Output Intent samt eingebettetem Farbprofil spezifiziert, doch das Gegenteil ist der Fall, wie die Spalte 6 zeigt: dann hauen Vorschau und Acrobat beide völlig daneben. Konvertiert man das PDF zudem noch ins PDF/X-Format, zeigt zumindest Vorschau korrekte Farben (Spalte 11). Entfernt man zusätzlich im Output Intent das eingebettete ICC-Farbprofil, dann bekommt es auch Acrobat in etwa hin (Spalte 10).

Eine Sonderrolle spielt das ICC-Farbprofil Coated FOGRA39 (ISO 12647-2:2004), ein proprietäres ICC-Farbprofil, das Adobe mit Acrobat mitliefert und das den ISO-Standard FOGRA39 abbildet, den bei PDF/X für beschichtetes Papier zumindest in Europa üblichen Output Intent. Das tut zwar das (davon unterschiedene) Standard-Farbprofil ISO Coated v2 (ECI) der European Color Initiative (ECI) ebenso, aber Adobe wollte offenbar seine Extrawurst haben. Dieses Profil scheint intern in Acrobat und Acrobat Reader zumindest annähernd die Rolle eines Default-Profiles zu spielen ähnlich wie das Allgemeine CMYK-Farbprofil von macOS in Vorschau; daher sind die Farben in Acrobat auch dann nicht völlig daneben, wenn überhaupt kein ICC-Farbprofil in das PDF eingebettet ist (Spalten 1 und 8). Und mit diesem – und nur mit diesem – ICC-Farbprofil zeigt Acrobat auch dann korrekte Farben an, wenn man in einem PDF/X den Output Intent mit eingebettetem ICC-Farbprofil spezifiziert (Spalten 12 und 13), was mit ISO Coated v2 (ECI) in Acrobat wie gesagt zu falschen Farben führt (Spalten 9 und 11).


Wenn man feststellt, dass die Farben in Vorschau und/oder Acrobat nicht stimmen, dann braucht man für die nähere Problemanalyse natürlich die Möglichkeit, sich die in das PDF eingebetteten ICC-Farbprofile anzusehen. Acrobat bietet hierzu die Preflight-Werkzeuge; wer Acrobat nicht zur Verfügung hat, für den ist PDF Checkpoint von Zevrix eine preiswerte (43€) und übersichtliche Alternative, die allerdings zur Zeit nur die Pixelbildern, nicht aber Vektorgrafiken zugeordneten ICC-Farbprofile anzeigen kann.

PDF Checkpoint kann allerdings nur analysieren, aber das PDF nicht modifizieren. Dazu braucht man dann doch Acrobat oder aber die in macOS mitgelieferten Quartz-Filter. Leider funktioniert aber der Filter für die Zuordnung von ICC-Farbprofilen zu Objekten nicht. Einen Quartz-Filter zur Konvertierung in PDF/X-3 (ohne die für Acrobat fatale Einbettung des zugehörigen ICC-Farbprofils) kann man sich higegen leicht anlegen:





Vielleicht ist das für einige von Euch hilfreich; mir war es vollkommen neu und ich bin immer noch geschockt ob dieses unausgegorenen Chaos’.

Weia
ohne es im Detail gelesen zu haben: die Vorhschau unterstützt, meines Wissens, nicht die Überdruckenfunktion. Im Acrobat (und auch im Reader) kann man sich eine entsprechende „Simulation“ anzeigen lassen (irgendwo in den Einstellungen suchen). Dort gibt es auch noch weiter Einstellungen zum Thema Farbdarstellung (bei Schwarz). Daher ist die Ansicht der Vorschau bei Druckpdfs „eh nicht zu gebrauchen“
Das trifft wohl bei dir im speziellen Falle nicht zu, aber man sollte es im Hinterkopf haben (als Grafiker)

Aber darum geht es hier nicht. Zum einen ist die Farbwiedergabe in Acrobat ja genauso fehlerbehaftet, zum anderen repräsentiert Vorschau die PDF-Engine von macOS, die systemweit die Farbwiedergabe in allen Cocoa-Programmen steuert, also beileibe nicht nur für Vorschau selbst gilt. Das genannte (Cocoa-)Programm PDF Checkpoint etwa ist explizit ein Programm für die Druckvorstufe, stellt die Farben aber genauso dar wie Vorschau. Und mit PDFs, die zum Betrachten am Bildschirm gedacht sind und wo die falsche Farbwiedergabe in Acrobat ebenso zum Problem wird, hat Überdrucken sowieso nichts zu tun.

Das "Vorschau" nicht für Drucksimulationen geeignet ist, ist allgemein seit MacOS 10.5 und Adobe CreativeSuite CS3 bekannt (wenn ich es aus dem Kopf richtig weiß). Sagt ja schon der Name.
Und dass z.B. "Coated FOGRA39 (ISO 12647-2:2004)" nur im Namen etwas mit der FOGRA und ISOkonformer Druckvorstufe zu tun hat, ist ebenfalls allgemein bekannt.

Es geht hier aber nicht um Drucksimulation, sondern um korrekte Farbwiedergabe und da ist Acrobat keinen Deut besser als Vorschau. Im Gegenteil, Vorschau zeigt in 4 Fällen meiner Tabelle die korrekte Farbe an, Acrobat nur in 3.
Was sagt uns denn der Name Acrobat? Dass die Benutzung dieses Programms ein Hochseilakt mit Absturzgefahr ist?
Hier aber ebenfalls nicht das Thema. Es geht ausschließlich darum, dass dieses Adobe-proprietäre ICC-Farbprofil in Acrobat offenkundig eine Sonderrolle spielt, was die korrekte Farbwiedergabe betrifft.

Ich glaube. du verstehst hier ein grundsätzliches Problem nicht:
Die Voraussetzungen der Druckereien.
Diese erwarten Acrobat X-3 Dateien mit den entsprechenden Profilen.
Und die kannst du in Vorschau nicht erstellen.

Aber darum geht es doch nicht. Das Problem, um das es mir geht, ist vollkommen unabhängig davon, wie und mit welchem Programm PDFs erstellt werden.

Es geht darum, dass bei existierenden PDFs mit bestimmten, in der Tabelle aufgelisteten Eigenschaften die Farben entweder in Vorschau oder in Acrobat oder in beiden nicht korrekt wiedergegeben werden. Und das ist natürlich ein Unding. Ich habe ein PDF, und dessen Farben sehen in Vorschau (und damit auch allen anderen macOS-Cocoa-Programmen) anders aus als in Acrobat. WTF? Und nein, es ist mitnichten so, dass sie immer in Vorschau falsch und in Acrobat korrekt sind, genauso häufig ist es umgekehrt. Das dürfte niemals sein, ist aber so.

Ich weiß nicht, was daran so schwer zu verstehen ist.

Ganz abgesehen davon kannst Du prinzipiell sehr wohl mit Vorschau PDF/X-3-Dateien im ISO Coated v2 (ECI)-Farbraum oder einem vergleichbaren erstellen durch die Verwendung von Quartz-Filtern. Das praktische Problem ist nur, dass der Quartz-Filter zur Farbkonvertierung in den ISO Coated v2 (ECI)-Farbraum im Augenblick buggy ist, sodass es faktisch momentan tatsächlich nicht funktioniert. Aber nochmal: Darum geht es hier überhaupt nicht.

Was Druck PDFs angeht hat Acrobat immer recht. Womit hast du dein PDF erstellt? Ist dort Farbmanagemant korrekt eingerichtet? Wird dort genauso geprooft wie in Acrobat Pro? Worauf beziehst du die Fehler?
Und: Für Europa gibt es als neuen Workflow die Profile PSO Coated V3 und neue uncoated Profile. Einige Onlinedruckereien haben darauf umgestellt. Das bringt aber wieder ganz andere Komplikationen mit sich, leider.
Das die Abweichungen in Vorschau nerven ist klar und leider schon ewig so.

Hängt davon ab, was Du damit meinst.

Wenn Du damit meinst, dass das Druckergebnis immer so aussieht wie in Acrobat, dann kann ich Dir das gerne glauben.

Das nützt aber nichts, wenn die Farben in Acrobat auch schon falsch sind.

Aufgefallen ist mir das an PDFs aus diversen Quellen, meist PDF-Versionen wissenschaftlicher Bücher. Die sahen in Vorschau und Acrobat immer wieder mal unterschiedlich aus, und da ich manchmal aus dem Kontext die korrekten Farben kannte, wusste ich auch, dass mal Vorschau richtig lag und mal Acrobat. Das war dann der Anlass, den internen Aufbau der PDFs näher zu untersuchen, um die Ursachen für diese Abweichungen zu finden.
Das Test-PDF mit der braunen Testfarbe habe ich als Pixelbild in Pixelmator Pro erstellt und als PDF exportiert. Das ist die Standard-macOS-Funktion über den Druckdialog und wäre also auch in allen anderen macOS-konformen Programmen dieselbe. Das ergibt ein PDF im sRGB-Farbraum, das sowohl in Vorschau als auch in Acrobat die Ausgangsfarbe aus Pixelmator Pro korrekt wiedergibt. An dieser Stelle ist also noch alles OK und dieses PDF ist mein Referenz-PDF. Alle darauf folgenden Modifikationen habe ich in Acrobat Pro mithilfe der entsprechenden Funktionen samt ihrer Optionen vorgenommen – also etwa die Farbkonvertierung nach CMYK wahlweise über eingebettete Farbprofile (Spalte 2; funktioniert für Vorschau und Acrobat) oder den Output Intent (Spalte 4; funktioniert nur für Acrobat). Usw.
Wieder ein anderes Thema.
Die Abweichungen in Acrobat (Spalten 6, 7, 9 und 11) nerven aber genauso.

Nein. Druckdateien werden mit Acrobat erstellt, weil das die Druckereien so erwarten. Ende vom Lied.

Erstens stimmt das nicht. Erwartet werden PDFs im PDF/X-3-Format, aber doch nicht zwingend aus Acrobat. Ich hatte bei meinen (zugegeben seltenen) Druckaufträgen nie Probleme damit, wenn die PDF/X-3-Dateien von anderen Programmen generiert wurden. Das wurde auch nie von einer Druckerei gefordert, dass die Daten aus Acrobat sein müssten.

Zweitens habe ich für das Erstellen der Dateien für diesen Test ja Acrobat Pro verwendet, eben um auszuschließen, dass die Probleme von dritter Seite kämen.
Ich singe aber halt gerade ein ganz anderes Lied als Du.

Ich erstelle auch nicht im Acrobat, sondern in Quark 2024 mit den minimal angepassten Presets. Perfekt und fehlerfrei. Die Technologie dahinter kommt von Callas. Acrobat benutze ich zum checken. PDF-X3 nutze ich schon lange nicht mehr, aber PDF-X 4, meist mit cmyk Workflow. Vorschau scheint Probleme zu haben wenn ein PDF nicht -X ist.

Puh Weia.

Den genauen Vorgang kann ich Dir nicht erklären, da ich die Ingenieurleistungen die dafür notwendig sind und die die einzelne Software / Hardware verwendet, weder programmiert habe, noch kenne. Die daran Beteiligten könnten Dir Deine Fragen (eventuell) beantworten.

Du hattest Dich hier ja mal als ABSOLUTEN Farbpapst präsentiert, der an die ABSOLUTE Farbwiedergabe bei korrekt kalibrierten System glaubtest und dies vehement verteidigt hat. Wie gesagt, sind hier Entwickler beteiligt (Soft- und Hardware), deren Arbeit ich nicht kenne.

Es gäbe theoretisch die Möglichkeit ALLE Farben über den Umweg von LAB-Farben (ABSOLUTER) Farbraum korrekt darzustellen. Ob und wie das möglich ist, entzieht sich – siehe oben – meiner Kenntnis. In den meisten Fällen sind Umrechnungen notwendig.

Obwohl Du seinerzeit an ABSOLUTE Farben glaubtest, fehlt – aus meinem bescheidenen Kenntnisstand heraus – einiges an notwendigem Detailwissen bei Deinen Tests. Hier kurz zusammengefasst ein paar Anmerkungen, die mir die Farbinkonsistenz erklären könnten.

Der Druckstandard PDFX3 hat schon etliche Jahre auf dem Buckel und kann NICHT gleichzeitig RGB- und CMYK-Daten verarbeiten. Er erwartet Eindeutigkeit! In Deinem Beispiel handelt es sich um reine CMYK-Farben im Standard ISO Coated v2. Bildschirmdarstellungen müssen also immer WIEDER in RGB UMGERECHNET werden!

Vorgenanntes machst Du am besten in der Software, die dann den richtigen Farbraum für Wiedergabe und Ausgabe berücksichtigt oder berücksichtigen kann. Welche ist das? Kann sie das? Welche Umwege benutzt sie dabei?

ISO Coated v2 ist ein „alter“ Druckstandard, der seinerzeit Beleuchtungssituationen auf Papieren ohne UV-Aufheller voraussetzte. Das seinerzeit entsprechende Normlicht hatte also auch keine UV-Beleuchtung implementiert.

Seit 2015 !!!! existiert der Druckstandard ISO coated v3. Der fordert eine definierte Menge UV-Licht in der Betrachtung UND Druckmaterial, das über UV-Aufheller verfügt.

Sind diese Standards bei der Umrechnung durch die Software in die Farbprofile (KORREKT) berücksichtigt worden?

Das PDFX4-Format kann GLEICHZEITIG RGB UND CMYK-Farben beschreiben. Es sind also ggf. bei der Bildschirmdarstellung KEINE Umrechnungen notwendig (s.o. PDFX3 kann das NICHT). Die Darstellung / Interpretation / Ausgabe wird also dem Ausgabemedium übertragen. Hier spielen System (Win / Mac / Linux / X) / Software / Hardware (Monitor / Druckgerät / RIP / etc.) mit.

Meines Wissens nach stellen Windows- und Mac-Systeme RGB-Farben unterschiedlich dar. Zu einer (einigermaßen) identischen Farbwiedergabe zwischen den beiden Systemen verwendet man sicherheitshalber das sRGB-Profil, das beide Systeme beherrschen, aber im Gegensatz zu anderen RGB-Systemen im Farbraum arg kastriert ist (kleinster gemeinsamer Nenner).

Die vorgenannten Fakten sind alles Einflussfaktoren, die die Software-Entwickler in Ihre Übersetzungstabellen implementieren, oder auch nicht. Jeder meint es „richtig“ zu machen oder zu interpretieren. Hast Du alle Rahmenbedingungen als Voraussetzung erfüllt (Umgebungs-/Normlicht)? Haben alle beteiligten (Software)entwickler diese Rahmenbedingungen implementiert? Wie haben sie sie interpretiert? Haben sie daraus die richtigen Umrechnungen abgeleitet? Hast Du zu allen diesen Fragen Zugriff? Kannst Du nachvollziehen und verstehen, was dort im Detail gemacht wurde? Hat das Programm „Vorschau“ den Anspruch, alle Ausgabesituationen von Farben korrekt darzustellen? Ist es also zum Softproof geeignet? Oder weist der Programmname (Preview/Vorschau) bereits auf etwas anderes hin? Ist der Acrobat READER dafür geeignet? Werden professionelle Tools vorausgesetzt? Gibt es PDF-Darstellungs-Software die darauf spezialisiert ist? Wie ist diese programmiert? Beherrschen das die von Dir benannten und kontrollierten Softwaren ALLES? Sind sie ggf. auf spezielle Szenarien (Druckwiedergabe in CMYK / Ausgabe auf Monitoren) spezialisiert? Wie viel Wert haben die Programmier auf eine „KORREKTE“ Interpretation (Übersetzung/Umrechnung) gelegt?

Mein Credo in unserer Diskussion seinerzeit war, Du meintest erwarten zu können, dass Farben ABSOLUT darstellbar sind. Meine Erkenntnis war, es gibt so viele Einflussfaktoren, die NICHT ALLE GLEICHZEITIG berücksichtig werden können, dass es (aktuell noch) KEINE ABSOLUTE Farbdarstellung gibt.

Vielleicht magst Du an Lösungen gerne forschen. Das wäre aller Ehren wert. Meine Einschätzung ist, das Ziel ist (noch) nicht erreicht. Dein Anspruch (siehe Ausgangspost) ist (noch) Wunschdenken. Dein Ausgangspost beschreibt Deine Erkenntnis, dass Du in der Realität angekommen bist.

Nur weil Zitrone und Orange beides Zitrusfrüchte sind, sehen sie nicht gleich aus oder schmecken gleich. Und nur weil ich aus Word ein PDF nach X3-Spezifikationen erzeugen kann, heißt es nicht, dass es den Anforderungen einer sauberen Druckvorstufe genügt. Der Unterschied mag bei einem textlastigen, bebilderten wissenschaftlichen Buch nicht auffallen, bei einem Bildband auf Kunstdruckpapier eben schon.

Ich habe Dir bereits in der ersten Antwort geschrieben, dass "Vorschau" nicht für Drucksimulationen gedacht ist. Vorschau und Systemdruckdialog erzeugen PDFs auf Basis von Quartz/DisplayPDF. Das ist zum Anzeigen und notfalls passabel drucken gedacht. Acrobat Reader oder - Pro können das spätere Druckergebnis simulieren. Daher machen sich Schwarzaufbau mit 300% oder nur 260% sehr deutlich bemerkbar.

Du verwendest das falsche Werkzeug und erwartest das gleiche Ergebnis. Diese Denkweise ist etwas schwierig. Damit bin ich raus, weil ich nicht meine Zeit mit einem Rechthaber vergeuden möchte.

Gute Güte, selten ist mir eine Diskussion so entgleist. Um die Druckvorstufe, um Umrechnungsverluste bei der Konvertierung via Lab (dem Profile Connection Space) nach CMYK und wieder zurück zu Bildschirm-RGB, um die Untauglichkeit von Vorschau aus Sicht von Prepress-Leuten, um den besten/aktuellsten Druckstandard, um die Begrenztheit von sRGB, und und und … um all das geht es nicht. Es geht um etwas viel viel Schlichteres.

Ich gebe jetzt nochmal ein ganz simples Beispiel, das nur Acrobat Pro verwendet, und dann gebe ich auf.

Also:

• Ich habe ein Ausgangs-PDF, das ein Pixelbild mit der Farbe sRGB 99 61 45 enthält.
• Ich öffne dieses PDF in Acrobat Pro. Auf dem Bildschirm zeigt Acrobat Pro die RGB-Farbe (Bildschirm-RGB umgerechnet in sRGB) 99 61 45 an. Passt.
• Ich konvertiere dieses PDF in Acrobat Pro mit der Funktion Erweitert → Druckproduktion → Farben konvertieren… mit der Option Konvertierungsprofil einbetten aktiviert nach ISO Coated v2 (ECI). Damit lande ich in Spalte 2 in meiner Tabelle. Acrobat-Bildschirmanzeige in sRGB: 99 61 45. Passt.
• Ich konvertiere das PDF in Acrobat Pro mit der Funktion Erweitert → Preflight… und dort dem Profil Nach PDF/X-3 konvertieren (ISO Coated v2 (ECI)) nach PDF/X-3 und lande damit in Spalte 9 meiner Tabelle. Acrobat-Bildschirmanzeige in sRGB: 106 65 47. Passt nicht. Die Farbe hat sich verändert und zwar nicht um eine der Unvollkommenheit der Farbmanagement-Technologie geschuldete Nuance, sondern deutlich.

Das ist ein klarer Bug. Oder will hier irgend jemand behaupten, es sei in Ordnung oder gar beabsichtigt, dass eine Konvertierung eines PDFs nach PDF/X die Farben deutlich verändert? Von wegen Acrobat hat immer recht …

Nur darum geht es. Vorschau spielt in diesem Beispiel keine Rolle und all die anderen hier genannten, teils äußerst subtilen Aspekte auch nicht. Es ist Acrobat Pro und nur Acrobat Pro, das hier (deutlichen) Mist baut.

Tschuldigung, das muss Spalte 11 heißen.

Und am Rande bemerkt: Vorschau stellt in diesem Fall im Gegensatz zu Acrobat die Farbe korrekt dar. Ich mein ja nur …

Acrobat (Pro) wertet auch das Monitorprofil aus UND das Output Intent. Dann ergibt sich logischerweise eine Addition, weil Du ja vorher alle (Dokument - Farbraum - Output) als gleiches ICC-Profil angegeben hast.

VORSCHAU wertet das Monitorprofil nicht aus, deswegen schaut es auch identisch (richtig) aus.

Nebenbei bemerkt: Alle ICC-Profile auf das gleiche Profil zu stellen ist nicht unbedingt Sinn und Arbeitsweise von Colormanegement. Da kannst Du du CM auch komplett deaktivieren.

Das weiß ich nun zufällig ganz genau, weil ich einen ewigen Kampf um dieses Thema geführt habe. Apples Video-Technologie (das ist ja längst nicht mehr QuickTime, nur der Video-Player heißt noch so) ist (oder war jedenfalls bis vor kurzem) die einzige Video-Technologie, die Farbmanagement korrekt hinbekommt (weswegen Final Cut Pro für mich alternativlos ist). Alle anderen Video-Player scheitern entweder daran, dass sie entweder überhaupt kein Farbmanagement implementieren oder aber falsch. 🙄

Ja, hatte ich für mich auch so festgestellt, im VLC sah das einfach etwas zu blaß, verwaschen aus, mal laienhaft ausgedrückt. Habe aber jetzt recht gute Erfahrungen mit IINA (basiert auf mpv) gemacht, dort lassen sich sogar nicht optimal kodierte Videos, z. B. mit mehr oder weniger geclippten Highlights noch ganz gut hinbiegen über die Video-Einstellungen. Jedenfalls mit 4K-Rec.709-Videos klappt das ganz gut.

„Addiert“ wird da gar nichts, sondern von Farbraum zu Farbraum konvertiert.
Wie kommst Du denn auf die Idee? Alle Cocoa-Apps (und Vorschau vorne dran) unterliegen dem systemweiten Farbmanagement von macOS. Du kannst überhaupt kein Cocoa-Programm schreiben, das bei der Bildschirmausgabe nicht automatisch das Monitorprofil mit einbezieht.
Es ergibt in der Regel aber auch keinerlei Vorteile, das nicht zu tun.
Kannst Du nicht – mindestens die Konvertierung ins Monitorprofil muss ja stattfinden.

Vielleicht mal noch direkt aus InDesign ein PDF rausschreiben, und schauen ob es sich da anders verhält, oder geht es nur um das Konvertieren von bestehenden PDFs?

Denke das PDF-Format ist wohl auch nicht geeignet, exakte Ergebnisse zu liefern, wenn es durch mehrere "Interpreter-Programme" läuft. Da ist einfach zu viel mehrfach "encapsuled", klappt ja schon manchmal bei reinen Image-Formaten nicht. Oder bei den ICC-Profilen; erinnere mich dass ein Display Profile in der LUT-Version nicht richtig funktionierte, aber in der Matrix-Version schon.

Muss zugeben, dass ich bei den Anforderungen für Print schon länger nicht mehr up to date bin, zuletzt InDesign und Ausgabe als PDF/X-3 unter Snow Leopard. Von daher keine große Hilfe.

Falls wider Erwarten doch von Interesse: Thread zu dem angesprochenen LUT-Profile-Problem: (war bei macOS Sierra und High Sierra noch der Fall)

Au Weia. Ein Versuch noch:
In allen Deinen Test kommt das Wort KONVERTIEREN vor. Wer konvertiert wie wo was? Was sind die Ausgangswerte, die konvertiert werden. Welche Umrechnungstabellen verwendet die Software, die zur Konvertierung nötig sind? …

Wie gesagt, Du gehst von PDFX3-Profilen aus, die für die Ausgabe auf CMYK-Geräten gedacht sind (und nur CMYK verwenden können/dürfen). Diese konvertierst Du hin und her. Da liegt der Hase im Pfeffer. Mach die Tests mal mit PDFX4. Das kann RGB UND CMYK. Vielleicht kommst Du aus Deinem Dilemma heraus. Helfen kann ich Dir nicht. Vielleicht Deinen Blick erweitern.

Da Deine Diskussionen bekannterweise ausufern, bin auch ich hier raus!

Kann sein, dass ich mich irre aber ich verstehe das so:
Weia sucht nach Anhaltspunkten, wem er die Schuhe aufpumpen kann: Apple oder Adobe oder sonst wem. vor allem braucht er Hilfe um festzuhalten, wer an welchem Punkt „schuld“ ist und wenn möglich wieso.

Denn der eigentlich anzunehmende Idealzustand wäre: ein Parameter ist ein Parameter ist ein Parameter.
Konvertierung hin oder her.

Schon auf seinem eigenen Gerät gibt es verschiedene Darstellung je nach Software - mal so, mal so und das schon ohne Druckerei und sonstigen Dritten.

Die Diskussion ging teilweise in eine ganz andere Richtung.

Ich nehm ebenfalls an, dass hier ein RGB-Wert je nach Programm bei der Dirsplay-Anzeige unterschiedlich und mehrmals zurück-konvertiert und interpretiert wird.

Quelle: - PDF/X und Colormanagement

hypophora

Danke für Dein geistiges Update. Hast Recht. PDX3 kann CMYK und RGB, PDFX1 nicht. PDFX4 kann auch RGB und CMYK UND Transparenzen. Wie die Daten konvertiert wurden, ist im Ergebnis nicht unerheblich.

Und Danke für den Cleverprinting-Link, den hatte ich auch im Kopf. Da steht das meiste sehr ausführlich erklärt. Auch wenn es sich um ein Dokument aus 2016 handelt

Es ging mir einfach darum, dass solche Inkonsistenzen auftreten können (nicht müssen), egal aus welcher Quelle. Daher habe ich speziell das noch nicht überprüft – werde ich noch, wenn ich wieder Zeit habe; jetzt habe ich erstmal genug Zeit darauf verwendet.
Doch, prinzipiell muss das gehen, aber da ist einfach manches noch nicht klar genug definiert/implementiert. Dass die Unstimmigkeiten bei der Farbwiedergabe daran liegen, wo und wie genau die Farbräume im PDF definiert sind (den Objekten zugeordnet oder im Output Intent oder beides), soweit hat sich die Sache ja geklärt. Warum das so ist, ist noch unklar; ich vermute, es ist eine unglückliche Mischung aus verschiedenen Rendering Intents, anderen Default-Farbprofilen und letztlich auch schlichten Bugs in den verschiedenen Programmen.
Ja, aber das war eben so ein schlichter Bug (in macOS in diesem Fall).

Ich kann mittlerweile nur noch den Kopf schütteln, was mir hier alles unterstellt wird.

Ich wolle einen Schuldigen suchen/finden, endlos diskutieren, Hilfe bekommen, über die Basics des Farbmanagements belehrt werden … 🙄 Nichts davon ist der Fall. Ich wollte einfach eine Info weitergeben, von der ich dachte, sie könnte für manche nützlich sein: Im Falle von PDFs zum Lesen am Bildschirm, die man anderen zugänglich machen will, dass man die als PDF/A speichern sollte, wenn einem Farbtreue wichtig ist; im Falle von CMYK-PDFs für Softproof oder Druck, dass man sich nicht darauf verlassen kann, dass Vorschau und Acrobat dieselben Farben anzeigen und dann unklar ist, welche Anzeige stimmt (nein, das ist eben nicht immer die von Acrobat).

Daher ist dies mein letzter Betrag in diesem verunglückten Thread.
Ist die Frage ernst gemeint? Farbmanagement konvertiert Farbwerte von einem Farbraum in einen anderen, das tut das CMM, die Ausgangswerte sind die des Quellfarbraums, die Umrechnungstabellen stecken in den ICC-Farbprofilen. Das weißt Du ja aber alles. Ich habe keinen Schimmer, was Du damit sagen willst (außer provozieren).
Tue ich nicht. Ich gehe von PDFs mit einem Pixelbild im CMYK-Farbraum aus. im PDF/X-Format sind nur die Hälfte der PDFs in meiner Tabelle.
Ich konvertiere überhaupt nichts „hin und her“. Ich konvertiere zu Beginn ein einziges Mal von RGB nach CMYK, und das auch nur, um beide Methoden zu testen, die Acrobat dafür anbietet. Die daraus resultierenden beiden CMYK-PDFs sind die Basis für alles weitere. Aber natürlich muss jedes Programm, das diese PDFs auf dem Bildschirm anzeigen will, sie dafür in das Bildschirm-RGB konvertieren – das ist prinzipbedingt immer so.
Ich bin in keinem Dilemma. Ich weise nur darauf hin, dass es mit PDF/X-3 Probleme gibt.
Keine Ahnung, wie Du darauf kommst. Von Schuld habe ich nirgendwo geredet.
Ja, das stimmt ja auch. Funktioniert das nicht, sind Standard oder Software fehlerhaft. Farbmanagement als solches funktioniert viel zu präzise, als dass sich solch teils eklatante Farbabweichungen durch Rundungsfehler o.ä. erklären ließen.
In den Test-PDFs gibt es keine RGB-Werte. Die einzige Konvertierung nach RGB, die prinzipbedingt für die Anzeige des PDFs auf dem Bildschirm stets stattfinden muss, ist die in das Bildschirm-RGB. Hin und her geht da gar nichts.

Deine Antwort, ("...nach RGB... hin und her") richtet sich offenbar nicht an meinen Text, der vielleicht zu knapp war. Drum hier, was ich meinte:

Vermutung: bei deinen Tests kommt es je nach Programm und Profil-Kombination möglicherweise zu RGB-CMYK-CMYK Transformationen (also mehrfach). Die Profil-spezifischen Änderungen samt Rendering-Intents bringen dann Vorschau und Acrobat in's Stolpern und zu unterschiedlichen Interpretationen.
Begründung: Würde erklären, warum bei 13 Tests 10 verschiedene Farben zustande kommen, und nur Test 2 korrekt zu sein scheint. Maximal würde ich hier 4-5 Farbtöne erwarten, ISO, Fogra, sRGB und eventuell zwei unterschiedliche "Fallbacks" in den Programmen bei Ratlosigkeit,.

Meine Annahme war aber nur unwichtiges Beiwerk, auf den Lösungsansatz gehst du leider gar nicht ein. Drum wiederhole ich den nochmal:
Zitierte Empfehlung: beim Object muss für PDF/X das passende Profil (hier sRGB) eingebettet werden, weil es sonst unbekannt sei.
Da die Quelle nicht ganz unseriös zu sein scheint und die Begründung durchaus stimmig sein könnte, ist es ein wenig, hmm, sonderbar, dass du das vollständig ignorierst. Ich kann's leider nicht testen, weil kein Acrobat...

Allgemein: Der Wunsch, CMYK-PDFs an andere zur möglichst farbgetreuen Display-Anzeige zu senden ist mir noch nicht gekommen und Softproofs simuliere ich nicht über PDF-Exports, insofern hast du hier zum einen eher spezielle, für die meisten vermutlich nicht relevante und daher nie getestete Anforderungen. Hinzukommt, dass du mit Pixelmator/Acrobat als Werkzeuge Umwege nehmen musst, andere Grafikprogramme sind vielseitiger, da erscheint dann (und nur) beim PDF/X-Export auch "embed Profiles" (ich geh´mal davon aus, dass es das tut, was oben empfohlen wurde, bei Affinity zB ist dies auch nur eine Info, keine Option).
Ob's hilft kann ich wie gesagt nicht ausprobieren. Mich haben deine Experimente auch eher zu anderen Versuchen inspiriert. Hätte man aber testen sollen bei der Beweisführung. Im Netz findet man öfters den Rat, kein PDF/X zu verwenden, wird aber nicht weiter begründet.
Hier bleibt nun offen, was denn letztlich q.e.d.´wurde...

Jein.

Natürlich müssen die Farbräume definiert sein. Es gibt aber (und das ist wesentlicher Teil der Wirrnis) 2 Möglichkeiten dazu: als dem Objekt zugeordnetes, eingebettetes Profil und/oder im Output Intent.

Wenn Du in Acrobat eine Konvertierung nach PDF/X vornimmst, dann konvertiert Acrobat die Farben aller CMYK-Objekte oder aller (CMYK und RGB) Objekte (abhängig davon, ob die Option Geräteunabhängiges RGB in Zielfarbraum konvertieren aktiviert ist) in den Farbraum des Output Intents und löscht danach sämtliche den Objekten zugeordneten eingebetteten Farbprofile, sodass nur die „nackten“ CMYK-Komponentenwerte (im Farbraum des Output Intents) übrig bleiben. Acrobat macht das bei der Anzeige des PDFs nichts, da er alle objektbezogenen CMYK-Komponentenwerte ohne zugeordneten Farbraum als dem Farbraum des Output intents zugehörig interpretiert. Vorschau tut das aber nicht, sondern nimmt dann den Allgemeinen CMYK-Farbraum von macOS an. Das ist das basale Farbwiedergabe-Problem zwischen Acrobat und Vorschau. Da die PDF/X3-Spezifikation beide Verhalten erlaubt, verhält sich kein Programm „richtiger“ oder „falscher“ als das andere.

Die meisten Druckdienstleister, mit denen ich zu tun hatte (nicht viele), bestehen darauf, dass ausschließlich CMYK in dem PDF verwendet wird (wohl um jeden Streit um die korrekte Konvertierung von RGB nach CMYK zu vermeiden), also RGB-Farben nach CMYK konvertiert werden müssen. Damit ein solches PDF/X-3 sowohl in Acrobat als auch in Vorschau korrekt angezeigt wird, müssen daher sowohl die objektbezogenen CMYK-Farbprofile als auch das CMYK-Farbprofil für den Output Intent eingebettet bleiben. Das ist (allein) mit Acrobat nicht zu machen, da dessen Preflight-Konvertierungsprofile immer auch nicht erwünschte Dinge tun (wie z.B. eben die eingebetteten Farbprofile zu löschen), die man ihnen nicht abtrainieren kann (jedenfalls habe ich es nicht geschafft), was dann zu den weiteren Farbinkonsistenzen führt.

Ich hatte gerade selbst einen konkreten Fall, wo ein farbkritisches Pages-Dokument in eine PDF/X-3-Druckvorlage konvertiert werden musste, die auch in Vorschau farblich perfekt ist (um sie in einer Cocoa-Dokumentenverwaltung ablegen zu können, die natürlich die macOS-PDF-Engine benutzt, die Farben also wie Vorschau wiedergibt). Dafür habe ich eine Lösung gefunden, die ein PDF/X-3 erzeugt, das die Farben sowohl in Vorschau als auch in Acrobat perfekt wiedergibt. Rein technisch geht das also – nur eben nicht (allein) mit Acrobat (oder anderen Adobe-Programmen). Ich warte noch ab, ob das Druckergebnis wie erwartet ebenso perfekt ausfällt, und wenn es das tut, werde ich den Workflow hier zur Info posten (auch wenn ich von den Prepress-Aficionados dafür dann wieder ausgezählt und belehrt werde, dass Adobe (ausgerechnet!) das Maß aller Dinge ist und das, was ich will, sowieso nicht geht 😝).

Eigentlich nicht nötig, weil Du immer wieder und immer noch unbelehrbar Deine Fehler wiederholst. Deine Aussagen sind nicht hilfreich für jemanden, der sich gerade mit Farbmanagement und PDF beschäftigen will. Um es mal in aller Deutlichkeit zu sagen. Meine Meinung dazu.

Welche Fehler? Ich kann nicht erkennen, worin ein Fehler liegen sollte, wenn ein gestecktes Ziel zu 100% erreicht wird. Dass Du möglicherweise das Ziel nicht sinnvoll findest, mag sein, aber Ziele kannst Du ja getrost jedem selbst überlassen. Für mich ist aus mehreren Gründen eben von großer Bedeutung, ein PDF/X-3 zu generieren, das ein perfektes Druckergebnis ermöglicht und gleichzeitig Farben 100% korrekt in Vorschau (und damit allen Cocoa-macOS-Programmen) wiedergibt. Du hast für diese Aufgabenstellung keine Lösung parat, sondern erklärst einfach Vorschau als dafür ungeeignet. Ich hingegen habe eine Lösung.

Und unbelehrbar? Wer sollte mich denn warum belehren? Du mit Deinem offenkundigen Halbwissen, was Farbmanagement anbelangt (VORSCHAU wertet das Monitorprofil nicht aus, deswegen schaut es auch identisch (richtig) aus – mehr Fehler lassen sich in einem solch kurzen Satz ja kaum unterbringen)?
Zügle Dich mal ein bisschen, statt Dir anzumaßen, für alle Forumsmitglieder zu sprechen. Wenn Du die Informationen nicht hilfreich findest (was augenscheinlich daran liegt, dass Du sie nicht verstehst), dann lies sie halt nicht. Ich wollte ja eigentlich nichts mehr schreiben, aber hypophora hatte noch einen konstruktiven Beitrag verfasst, den ich nicht unbeantwortet ins Leere laufen lassen wollte. Jetzt bereue ich das wieder, denn auf Deine persönlichen Angriffe kann ich getrost verzichten.

Etwas Gebäck und eine schöne Tasse Bohnenkaffee dazu...?

Die meisten werden sich wohl an deinen ersten Ratschlag halten: "PDFs, die zum Betrachten auf einem Bildschirm gedacht sind, sollten die Farben in einem RGB-Farbraum, standardmäßig sRGB, definieren."
Das geht ja auch mit Proof-Farben, wenn man denn unbedingt will.

Im zweiten Teil gibst du eigentlich ein Beispiel dafür was passieren kann, wenn man sich nicht an Rat 1 hält.
Problematisch ist aber, dass du anschließend eine These mit großem Aufheizpotential aufstellst (Industriestandard hat Bugs) und fortan nur noch mit theoretischen Erklärungen verteidigst, obwohl man die Testmethodik durchaus in Zweifel ziehen darf, muss.

Die Aufgabenstellung: ein sRGB-Wert soll nach Export in eine CMYK-Profil-Datei in Vorschau und Acrobat identisch am Display ausgegeben werden, wobei du den ursprünglichen sRGB-Wert als "korrekt" bezeichnest. Finde den Fehler

Du erzeugst ein ein altes PDF-Format und exportierst es nach PDF3. Dem alten Format fehlen alle neueren Tags, werden möglicherweise nicht oder unerwünscht ersetzt, who knows. Hier hätte man zunächst wohl mit einem oder mehreren Programmen mit nativer PDF3 Export-Fähigkeit gegengetestet, um potentielle Fehlerquellen - auch in Werkzeugen, Einstellungen - auszuschließen, bevor man final schlussfolgert.

Du möchtest Farbmanagment, testest aber ausschließlich in CMYK pur mit der Begründung, dass es die PDF3-Spezifikation ja erlaubt. Stimmt, laut Spezifikation kann man sich entscheiden zwischen color managed und CMYK. Abgesehen vom Paradox, das Vorhandensein von Optionen bedeutet ja nicht, dass sie stets alle den Zweck erfüllen. Hier verlässt du die Aufgabenstellung zugunsten Dogma.

Einen Gegentest mit empfohlenen Einstellungen bei Acrobat und/oder Programm mit PDF3-Export machst du nicht, weil aus theoretischen Erwägungen als unnötig erachtet. (Das neue Fass mit Anforderungen von Druckdienstleistern lass ich mal außen vor, Änderung der Aufgabe, andere Baustelle.) Will's nur mal gesagt haben: Spätestens hier kann sich auch der geneigte Leser kaum noch des Eindrucks erwehren, das nicht sein kann, was nicht sein darf...

Du erläuterst, dass die 10 (wenn richtig gezählt) verschiedenen Farben in den Tests daher zustandekommen, weil hier 3 verschiedene Profile herangezogen werden. Dem kann ich schwer zu folgen. Hat mit der Aufgabenstellung nix zu tun, aber wenn du drauf eingehst, erklär's bitte nachvollziehbarer

...usw.. (falls mir noch mehr einfällt)

Liste das nur. Ist nicht mehr konstruktiv, ich weiss, sorry. Aber subtil wird überlesen. Muss da noch meine Aufgabenstellung überdenken...

Sorry, für Popcorn-Unterhaltung bin ich nicht zuständig, aber Unterstellungen zu meiner Person lasse ich ungern stehen.Ich habe mir bis heute nie angemaßt für "das Forum" zu sprechen. Und was Du als "persönliche Angriffe" verstehen willst, sind Kritik an Deiner Herangehensweise an das Thema und nicht an Deiner Person. Alles andere, wie "unbelehrbar" sind meine persönliche Meinung; ich meinte das deutlich gekennzeichnet zu haben.

Ich habe MactechNews gefunden, weil ich zu einem technischen Problem mit dem Mac eine Lösung gesucht habe. Und ich halte die versammelte Kompetenz, den Austausch und Erfahrung hier im Forum, bis auf wenige Ausnahmen, für sehr zielführend.
Dein Beitrag "Farbkonsistenz-Probleme bei PDFs" und Deine Schlussfolgerungen lassen begründete Zweifel aufkommen. @hypophora hat bereits mehrfach deutlich verständlich die Problemstellungen aufgezeigt; ich sehe keinen Grund, das gleiche zu wiederholen. Seine Ausführungen, die Du als "konstruktiv" empfindest, decken sich zu 100% mit meinen Erfahrungen zu dem Thema. Ich möchte für den suchenden Personenkreis, der wie ich damals, sich mit dem Thema "Farbmanagement und PDF" beschäftigen will, die genannten Zweifel deutlich in den Raum stellen.

Vielen Dank Weia, für die kompetent recherchierten Infos!

Rat 1 gilt aber eben explizit nur für PDFs, die zum Betrachten auf einem Bildschirm gedacht sind.
… wenn man sich nicht an Rat 1 halten kann, weil der Druckdienstleister (aus guten Gründen) ein PDF/X-3 im CMYK-Farbraum will.
Das habe ich nicht gesagt; wenn, dann haben PDF-Editoren Bugs, aber nicht der PDF-Standard. Das Problem mit dem PDF-Standard ist vielmehr, dass er derart viele Optionen erlaubt, dass praktisch kein PDF-Editor dem Anwender alle Optionen zugänglich machen kann. Stattdessen werden Vorannahmen getroffen, welche Einstellungen für den Anwender sinnvoll sein dürften, und die können im Einzelfall eben danebenliegen, sind aber von Anwender in der Software nicht zu korrigieren. Der Platzhirsch in diesem Bereich, Callas, dessen Softwaretechnologie zur PDF-Prepress-Bearbeitung von etlichen Anbietern von PDF-Editoren, Adobe und Acrobat inklusive, lizenziert wird, hatte ganz sicher nicht die Kompatibilität mit Vorschau auf dem Schirm, was man schon daran sehen kann, dass deren eigene Endanwender-Software, pdfToolbox, auf macOS PDFs auch in unproblematischen Fällen, in denen Acrobat und Vorschau übereinstimmen, nicht farblich korrekt darstellen kann; das Unternehmen kennt sich mit macOS offenkundig wenig aus.
Naja, über die Testmethodik im Einzelnen habe ich, um das Ganze nicht ausufern zu lassen, kaum etwas geschrieben; ich wollte lediglich das Ergebnis wochenlanger Arbeit als kompakte Info vorlegen für diejenigen, die damit etwas anfangen können. Auf die Idee, etwas verteidigen zu müssen, bin ich überhaupt nicht gekommen; das war nicht meine Absicht. Ich beschäftige mich seit 15 Jahren mit dem Thema, habe schon Unternehmen wie Apple und X-Rite beraten, da war ich dann doch etwas überrascht, als mir hier plötzlich Forumsmitglieder die Grundlagen des Farbmanagements erklären wollten.

Was ich mir vorwerfen lassen muss, ist, dass ich die Tabelle offenbar nicht gut genug erklärt habe, teils aus Zeitgründen, teils, weil mir meine langen Texte immer vorgehalten werden. Aber offensichtlich war das alles nicht so verständlich, wie ich dachte.

Deswegen habe ich mir ja vorgenommen, einen anderen Ansatz zu versuchen und in einem weiteren Thread statt theoretischer Erklärungen ein konkretes Fallbeispiel aus der Praxis zu beschreiben.
Ich kann beim besten Willen keinen Fehler finden. Der ursprüngliche sRGB-Wert ist trivialerweise korrekt, da er aus der Vorlage für das PDF stammt, die ich selbst erstellt und den ich selbst gewählt habe. Und da die Farbe mit Bedacht so gewählt ist, dass sie auch in CMYK problemlos darstellbar ist, muss die Farbe in den PDFs identisch sein, wenn alles korrekt funktioniert.
Jetzt verwechselst Du PDF und PDF/X. Das ursprüngliche sRGB-PDF war in PDF Version 1.3. Die ist von 2000, aber nach wie vor gültig und keineswegs „veraltet“. In aller Regel wird die PDF-Version verwendet, die alle benötigten Features unterstützt, das ist bei dem simplen Test-PDF Version 1.3. PDF/X-3:2002, das auch heute jede Druckerei akzeptiert, nutzt ebenfalls PDF Version 1.3, sodass hier prinzipiell keine Konvertierungsprobleme bei der PDF-Version auftauchen können.
Ich „möchte“ nicht Farbmanagement, sondern meine Fragestellung war an dieser Stelle, wann und warum es bei PDFs in CMYK zu Farbdifferenzen zwischen Acrobat und Vorschau kommt. Da muss ich logischerweise auch nur PDFs in CMYK testen.
Hat es sehr wohl, denn es ist die Antwort auf die Frage.

Ignoriere mal alle Spalten mit dem Coated FOGRA39 (ISO 12647-2:2004)-Farbprofil von Adobe, das ich nur zusätzlich aufgenommen habe, weil es in Acrobat eine Sonderrolle spielt. Dann bleibt lediglich 1 Farbprofil übrig, ISO Coated v2 (ECI) (woher Du das 3. Farbprofil nimmst, weiß ich nicht). Wie im Begleittext geschildert, können Farbprofile in PDFs als Objekten zugeordnete eingebettet werden (2. Tabellenzeile) oder als dem Output Intent zugeordnete (3. Tabellenzeile), die optional (4. Tabellenzeile) auch eingebettet werden.

Die Spalten zeigen dann einfach die Farbergebnisse aller möglichen, jeweils mit den Werkzeugen in Acrobat realisierten Kombinationen, als normales PDF (Spalten 1–7) und als PDF/X (Spalten 8–13). Spalte 4 z.B. zeigt die Farbwiedergabe in einem normalen PDF (nicht PDF/X; Zeile 5), bei dem den einzelnen Objekten keine Farbprofile zugeordnet und eingebettet wurden (Zeile 2), aber ein Output Intent mit zugeordnetem Farbprofil spezifiziert ist (Zeile 3), das auch eingebettet wurde (Zeile 4).

Das stimmt nicht. Wenn Du schreibstlegst Du mir nahe, auf den angekündigten Beitrag zu verzichten. Dann kann ihn aber niemand im Forum lesen. Ebenso schreibst Du nicht, dass meine Aussagen für Dich nicht hilfreich sind (was natürlich gut sein kann), sondern jemanden, sprich: alle (hier im Forum), die sich gerade mit Farbmanagement und PDF beschäftigen wollen.
Jeder Angriff auf eine Person ist eine „persönliche Meinung“, das ist doch kein Widerspruch.

Reg.: Kann keinen Fehler finden

Für mich ist die Problemstellung wie gesagt nicht interessant. Wenn ich was drucke, hab ich immer eine RGB-Quellversion. Wenn sich andere die anschauen möchten, schick ich die (brauch die eh für Web).
Ein Druck-PDF ist nur für die Druckerei, wenn's mies ist, bin ich schuld, da kann ich mich bei anderen - auch mit kalibrierten Monitoren - nicht rückversichern.

Du möchtest eine identische Druck-DarstellungsSimulation auf allen Betriebsystemen und mit allen Programmen. Dein Monitor-sRGB-Wert muss dann dem Druckerzeugnis-Wert entsprechen, weil der Wert in CMYK theoretisch darstellbar ist. Das Profil (zB Papiersorte, Maschine) spielt hier keine Rolle, sRGB = CMYK. Ok.

Wie hättest du denn gerne die Simulation. Unter Normlicht? Bei Print ist das ja wesentlich problematischer. Was schwebt dir da als Standard vor?

Nachdem ich hier jetzt mehrere Meinungen und Aussagen zu Druck-Standards und Profilen und Falsch und Richtig und Alt und Neu gelesen habe...

Zunächst entscheidet die Vorgabe der Druckerei, welches Profil oder welchen Standard man auszuliefern hat.
Das kann bei der einen Druckerei PDF-X3, bei der nächsten PDF-X4 oder bei der übernächsten ein PDF-X1a sein.

Zum Profil: das zu liefernde Profil richtet sich nach dem jeweiligen Verarbeitungsprozess (Druckmaschine, Papier, etc.)
Das kann dann ISO Coauted v2 sein, ISO Coaoted v2 300, oder eines der anderen vielen Profile ISO Newspaper 26v4, PSO..., PSR..., usw.
Und auch hier, muss es nicht sein, dass die Druckerei den neuesten aktuellen Standard auch verwendet.
Als Beispiel: Ich habe ISO Coated v3 bisher noch nie ausgeliefert... und arbeite seit mehr als 20 Jahren in der Reinzeichnung/Druckvorstufe. Das wollte bisher noch niemand haben.

Zur Anzeige: In Acrobat lässt sich übrigens auch ein Anzeigeprofil in den Voreinstellungen wählen.
Wichtig ist aber in den Daten der OutputIntent.

Ich schreibe meine PDFs übrigens aus InDesign raus. Das Dokument wird im Voraus im entsprechenden Profil angelegt. Die Bilder werden schon im entsprechenden Farbprofil in Photoshop abgespeichert und eingeladen. Beim Export wird keine Farbkonvertierung vorgenommen. Jedoch muss das Ausgabeprofil bestimmt werden. Es gibt auch Workflows, wo man die Bilder in RGB belässt und diese dann in InDesign einlädt und dann das Profil bei der Ausgabe erstellen lässt. Das hat sich allerdings in der Vergangenheit als nicht so Farbgenau herausgestellt. Es gibt übrigens auch in Photoshop unterschiede, wie man ein Dokument in ds entsprechende Profil bekommt. Wenn man hier den falschen Weg einschlägt, kann es hier ebenso schon zu Farbverfälschungen kommen.
Ich könnte mich jetzt hier auslassen und meinen Workflow detailliert beschreiben, aber warum sollte ich meine langjährige Erfahrung kostenlos verschenken.

Es sollte egal sein, ob du mit dem passenden Profil die Bilder in Photoshop vorab nach CMYK konvertierst oder wenn dies InDesign erst beim Export macht. Beide Programme benutzen dasselbe CMM (Color Management Module). Wenn’s da Unterschiede gab/gibt, dürfte das von nicht identische Einstellungen herrühren. Ich hatte zuletzt mit CS6 Kontakt zu diesen Programmen und damals war diese Aussage vielfach zu hören. Wir hatten zu CS3-Zeiten Experimente gemacht und es kamen mit den korrekten Einstellungen immer dieselben Werte heraus. Ein Praktikant hatte über hundert CMYK-Werte von exakten Positionen miteinander verglichen.

Da liegen allerdings auch einige Versionen zwischen CS3 CS6 und Creative Suite im Allgemeinen...

Uns ist damals sogar innerhalb von Photoshop aufgefallen, dass es einen unterschied macht, ob man vor der Profilwandlung alle Ebenen vorher manuell auf eine Hintergrundebene reduziert, oder das in dem Dialogfeld mit dem Klick auf die Funktion auf Hintergrundebene reduzieren macht. Über das Kontrollkästchen hat er schon die Farbe zerschossen. Ich blieb dann unserer Arbeitsweise treu, da sie sich am zuverlässigsten erwiesen hat.

Innerhalb von Photoshop sollte ja auch die gleiche Engine tätig sein, aber es machte eben doch einen Unterschied. Es soll ja sogar verrückte geben, die nur über die Menüleiste Bild/Modus/CMYK-Farbe umwandeln

Ah, ich erinnere mich an die Inkonsistenzen von Photoshop. Das war dann aber eher ein Photoshop-Problem. Kann mich auch an verschiedene Umsetzungen von Schlagschatten erinnern, je nachdem, wie man eine Bild umwandelte. Diese Fallstricke hatten wir damals aber auf dem Schirm und konnten problemlos darauf verzichten pro Druckverfahren/Papier separate Bilder erzeugen und speichern zu müssen. Am schwierigsten war die Umgewöhnung für die Bildbearbeiter, die jahrelang in CMYK gedacht haben. Ich selbst kann mir auch heute noch besser CMYK vorstellen, was wohl auch der frühkindlichen Prägung mit Pelikanfarbkasten geschuldet ist. Ich weiß leider nicht mehr, woran ein LAB-Workflow scheiterte.

Das ist ja völlig legitim, wertet aber die Problemstellung nicht ab.
Das ist bei mir nicht anders, aber darum geht es nicht. Es gibt ein konkretes und ein prinzipielles Problem.

Das konkrete Problem: Ich vermute, Du wirst die CMYK-Datei für die Druckerei bei Dir nicht sofort entsorgen, wenn Du sie der Druckerei geschickt hast, sondern irgendwo auf Deinem Mac aufbewahren, einfach in einem Ordner des Dateisystems via Finder oder in einem Dokumenten-Archivierungsprogramm. In beiden Fällen wird zur Anzeige des PDF-Inhalts aber die PDF-Engine von macOS benutzt, die eben falsche Farben anzeigt, wenn man keine entsprechenden Vorkehrungen trifft.

Du kannst Dich natürlich auf den pragmatischen Standpunkt stellen, dass Dir das egal ist; im Druck stimmen die Farben und auf dem Mac musst Du halt immer im Kopf haben, dass die angezeigten Farben falsch sind. Mir ist dieser Pragmatismus allerdings vollkommen fremd; ich bin einfach prinzipiell nicht bereit, solche technischen Inkonsistenzen klaglos hinzunehmen, wenn ich weiß, dass sie vermeidbar wären. Das mag „weltfremd“ klingen, aber das war Steve Jobs auch, wenn er darauf bestand, dass Computerplatinen ästhetischen Ansprüchen genügen müssten, obwohl sie kein Nutzer je zu Gesicht bekommen würde. Und doch war es diese Haltung, die Apple groß gemacht hat. Und das führt unmittelbar zum zweiten Punkt:

Das prinzipielle Problem: Sich mit Inkonsistenzen nicht abzufinden, hat den Vorteil, dass man so auf Bugs stößt, die durchaus auch pragmatisch Probleme an anderer Stelle machen könnten.

So ist mittlerweile klar, dass Adobes PDF-Engine buggy ist, was PDF/X-3 betrifft, weil sie Farbfehler erzeugt, wenn das PDF gleichzeitig Objekt-ICC-Quell-Farbprofile im Zielfarbraum und nochmals dasselbe ICC-Farbprofil eingebettet für den Output Intent enthält – was aber für PDF/X-3 erlaubt ist (für PDF/X-4 ist es das nicht). Dieser Fehler existiert nachprüfbar bereits 2008 und er existiert heute noch. Allerdings ändert er seine Ausprägung im Laufe der Jahre, d.h. die Farbsprünge waren 2008 andere als heute. Falsch waren die Farben aber immer.

Alle anderen PDF-Engines, die ich überprüft habe, die von Apple, von Callas, von Serif und von Foxit, haben dieses Problem nicht (dafür haben sie andere … 🙄).

Dass es in der Farbdarstellung eines Werkzeugs einen Bug gibt, sollte eigentlich für alle von Interesse sein, die dieses Werkzeug intensiv einsetzen. Wer freilich stets innerhalb des Adobe-Universums verweilt und sich an deren Defaults hält, wird damit nie konfrontiert werden; möglicherweise rührt daher die für mich nur schwer nachvollziehbare Gelassenheit und die völlig unkritische Haltung gegenüber Adobe („Was den Druck betrifft, haben Adobe-Programme immer recht“).
Den Standard gibt es doch in Form von D50? Meine gesamte Wohnung ist mit annähernd D50 ausgeleuchtet und alle Computer-Displays sind exakt darauf eingemessen. Dieses Thema spielt aber keinerlei Rolle, was Adobe-Bugs betrifft.

Was ich vergessen habe zu erwähnen, ist, dass ich nicht weiß, ob der Farbfehler auch im Druck auftritt (was ich vermute) oder nur bei der Bildschirmausgabe. Das ließe sich nur feststellen durch tatsächliche Drucke; dafür fehlt mir die Verbindung zu Druckereien. Falls die jemand hat und das testen will, kann ich ihm gerne die Dateien schicken.

Das müsste sich dann doch auch in farbseparierten Auszügen erkennen lassen, oder? Oder direkt die sperarierten Daten extrahieren einmal aus PDF/X-3 und einmal aus X-4. Sobald die Druckerei mit ins Spiel kommt hätte man ja wieder einen "Unsicherheitsfaktor" mehr. Ein gutes RIP müsste da doch hilfreich sein, das korrekt (je nach gewünschtem Rendering Intent) auszugeben.

Ist halt dann noch die Frage, wie gut das visuell zu beurteilen ist oder doch nur numerisch, wenn die Abweichungen noch eher gering sein sollten.

Ja, müsste. Aber die Farbe müsste bei einer Konvertierung nach PDF/X-3 auch gleich bleiben … Insofern würde ich da eher der Praxis vertrauen, auch wenn das dann natürlich zunächst wieder nur ein Einzelfall ist.

Jedenfalls, wenn Deine (ja völlig plausible) Annahme stimmt, dann ändert sich auch die Farbe im Druck. Die farbseparierten Auszüge differieren klar.
Naja, wäre es visuell nicht zu beurteilen, wäre es letztlich ja auch wurscht. Aber zumindest am Bildschirm ist der Unterschied z.B. in Spalte 11 ja doch deutlich sichtbar.

Einmal schalte ich mich noch ein:
Lieber Weia. Du Kluger, lebend im D50-Farbraum. Ich hatte vorher schon einmal angemerkt, dass es so viele Parameter gibt, die DU bei der KONVERTIERUNG!!! von Daten einstellen kannst. Ich weiß nicht WAS Du gemacht hast und ich bin mir nicht sicher, ob Du dabei auch alles RICHTIG gemacht hast. Oder ob irgendwo ein Fehler in DEINER Vorbereitung liegt, oder in den von den Softwareherstellern verwendeten UMRECHNUNGSTABELLEN. Mir fehlt dazu die Fachkenntnis, ich kann es NICHT beurteilen. Du meinst es beurteilen zu können.

Angefangen von der AUSGANGSSOFTWARE (ggf. Adobe-Produkte) und AUSGANGSMATERIAl musst Du ALLE FARBEINSTELLUNGEN KORREKT verwenden. Außerdem den ARBEITSFARBRAUM. Und die KONVERTIERMECHANISMEN. Auf manches davon HAST Du Einfluss. Auf manches NICHT.

Einen Test sei es wert: Früher kamen Adobeprodukte beim Hin- und Herkonvertieren von dort originär angelegten Farben bei der Rückkonvertierung nicht mehr zum Ausgangsergebnis. CMYK-Farbe > RGB-Farbe (oder LAB-Farbe) > CMYK-Farbe brachte am Ende der Kette einen anderen CMYK-Wert als am Anfang. Den Eintrag „RGB-Farbe“ kannst Du jetzt beliebig mit HEX, PANTONE, HKS etc. ersetzen. Hier müssen KORREKTE Umrechnungstabellen existieren. Eine Farbe im RGB-Farbraum kann in CMYK allerdings nicht nur durch einen CMYK-Wert dargestellt werden, sondern durch andere Farbwerte in unterschiedlichem Bunt- oder Unbuntaufbau. Das heißt: Der Softwarehersteller muss sich damit beschäftigen, oder erkennen, dass bestimmte Farbräume Ursprung waren und diese wieder IDENTISCH zurück interpretieren. Wie gesagt konnte z.B. InDesign das lange auch nicht, mittlerweile (kurzer Test von mir) scheint es zu klappen.

Probier das Vorgenannte mal mit den Serif-Produkten. Da kommt bei jedem Konvertiervorgang ein anderer Farbwert raus!!! Ich erinnere: Du hinterfragst penentrant Deine KONVERTIERUNGEN nicht!

So. Nun habe ich mir mal den Spaß gemacht und in Acrobat Professional die verschiedenen Voreinstellungen durchsucht, an denen man definieren kann, wie etwas dargestellt und wie es konvertiert werden kann. Ich weiß nicht, ob ich die Screenshots dazu hier alle hochladen kann. Es sind (kein Anspruch auf Vollständigkeit) und 5 Minuten Recherchezeit 26 Stück an der Zahl. Ich bin mir sicher, dass Du mit Deiner wissenschaftlichen Fachkenntnis bei allen Vorkommen genau weißt, was einzustellen ist, und auch das richtige eingestellt hast. Außerdem verstanden und kontrolliert hast, wie das funktioniert, und wo ggf. Fehler eingebaut wurden. Ich persönlich wage es nicht, mich mit allem zu beschäftigen. Dazu ist mir das Tool zu mächtig, und gestehe auch ein, dass ich die Finger davon lasse, weil ich einiges NICHT beurteilen kann. Ich freue mich aber, wenn Du hier oder anderswo genaue Erklärungen und Anleitungen vorbereitest, was KORREKT ist. Ich bin gespannt, ob Du alles im Griff hast, oder bei dem Ein oder Anderen auch zugeben kannst, dass es Deine Fachkenntnis übersteigt.

Dein Ansatz in allen Ehren. Und natürlich wäre es klasse, wenn es in – naher oder ferner – Zukunft Möglichkeiten gäbe, Farben reproduzierbar und identisch darzustellen. Wegen der vielen zu berücksichtigten Parameter weiß ICH nicht, ob das überhaupt möglich ist. Mir fehlt die Fachkenntnis. Ich bin der Hoffnung, es arbeiten Menschen mit Fachkenntnis daran. Fertig sind sie – möglicherweise – noch nicht. Insofern würde ich mich freuen, wenn auch Du Deine Einstellung ändern und anerkennen könntest, wo Probleme verortet sind. Es wäre ja möglich, der folgende Spruch besäße Wahrheit: „Das Problem sitzt häufig VOR dem Computer“.

P.S.
Auch hier gebe ich meine Unkenntnis zu: Ist im D50-Normfarbraum UV-Licht zwingend vorgeschrieben oder nicht? Bei IsoCoatedv2 gehört es NICHT zum Farbraum. Bei PSOcoated v3 wird es ZWINGEND vorausgesetzt.

P.P.S.
Leider kann ich keine 26 Screenshots hochladen...

Ich weiß nicht, warum Du darauf so herumreitest. Aus der Tatsache, dass Du dieses zugegeben sehr komplexe Thema nicht beurteilen kannst, folgt doch nicht, dass niemand es kann. Im Rahmen der trivialen Einsicht, dass Menschen prinzipiell immer fehlbar sind, bin ich mir hier sehr sicher zu wissen, was ich tue. Wäre ja schlimm, wenn nicht, ich habe mich seit 17 Jahren (nicht kontinuierlich, aber immer wieder) wissenschaftlich mit Farbphysik beschäftigt.
Das ist doch aber was gänzlich anderes. Natürlich kann es Fehler in der Software geben. Die aufzuspüren ist doch gerade ein Motiv meiner Untersuchungen.

Mir ist nicht wirklich klar, worauf Du hinauswillst. Dass aus einem Bündel unterschiedlicher Ursachen Farbmanagement nicht 100% perfekt funktioniert? Das stimmt, aber es könnte ohne Softwarefehler weit besser funktionieren, als es das tut; deshalb ist es wichtig, die zu isolieren.
Ja, das ist doch trivial. Natürlich führen falsche Einstellungen zu falschen Ergebnissen.

Ich verwende für meine Untersuchungen übrigens nicht Adobe-Programme (sondern nur zur Feststellung von deren Fehlverhalten), sondern pdfTools von Callas. Adobe hat deren Software für seine Prepress-Werkzeuge lizenziert (was Bände spricht über deren Software-Kompetenz inhouse). pdfTools ist nochmals mächtiger als Acrobat. Und ja, man muss deren Funktionen natürlich alle verstehen.
Die Einstellmöglichkeiten von pdfTools reichen sehr tief. Wo sie enden, hilft die Kommunikation mit Callas.
Ein bekanntes Problem bei fehlerhafter Implementierung von Farbmanagement.
Wie kommst Du zu diesem Vorwurf? Du weißt doch überhaupt nicht, wie ich im einzelnen vorgegangen bin, um zu den hier vorgestellten Ergebnissen zu kommen. Wissenschaftliche Methodik besteht zu einem Großteil aus Hinterfragen.

Dass Du zudem das hier völlig deplatzierte Wort penetrant verwendest, suggeriert, dass es Dir eigentlich um etwas gänzlich Anderes geht. Nur um was?
Warum arbeitest Du dich derart an meiner Person ab? Bleib doch bitte bei der Sache.
Natürlich ist das möglich. Das ist ein reines Softwareproblem. Und fast alle Software ist zum Haareraufen buggy, was Farbmanagement betrifft.
Du sprichst in Rätseln. Welche Einstellung wozu meinst Du? Warum sollte ich sie ändern? Was für Probleme erkenne ich nicht an?
Der besitzt ganz sicher Wahrheit. Allerdings – falls Du schon wieder auf meine Person und nicht die Sache hinauswillst – bei diesem Thema nicht in Bezug auf mich. Aber nochmal: Es geht hier nicht um mich.


Bei aller Komplexität ist der hier vorliegende Sachverhalt doch eigentlich sehr einfach: Sobald ein PDF/X-3 die ICC-Farbprofile für die Quellfarbräume einbettet und diese identisch zu dem Output Intent sind, dessen ICC-Farbprofil ebenfalls eingebettet ist (gemäß PDF/X-3-Spezifikation zulässig), stellt Acrobat die Farben falsch dar, während das kein anderes Programm (von allen überprüften Programmen) tut, das PDFs darstellen oder editieren kann.

Wie wahrscheinlich ist es angesichts dieser Tatsachen, dass das kein Software-Fehler in Adobes PDF-Engine ist?

Warum sollte die sonstige (unstrittige) Komplexität von Farbmanagement bei diesem klar definierten Sachverhalt irgendeine Rolle spielen?