Hallo,

wir haben zwei Probleme mit Indesign beim Erzeugen von PDFs im Zusammenhang mit Transparenz (und Farbmanagement?).

Vorab kurz unsere CM-Einstellungen:
- medienneutraler CM-Workflow (mit eci.org-Kochrezept)
- CM-Einstellungen in PS7, Illu10 und Ind2 stimmen überein
- PDFs erstellen wir via PS-Datei (PS-Farbmanagement, CRD: Std) und
Distiller 5
- mit PDF/X3-Inspektor erstellen wir daraus PDF/X3
(versehen mit dem jeweiligen ICC-Profil unserer Druckerei),
das unsere Druckerei prooft (und später mal druckt).

Problem 1:
Wird ein PDF/X3 von unserer Druckerei geprooft, wird aus CMYK-weiss
(0/0/0/0) als auch RGB-weiss (255,255,255) ein leichter "rosa"-Ton
(Test-Datei: http://www.buero-s.de/ind/rosa.pdf (die weissen
Buchstaben)). Weiss jemand, woran das liegt?

Problem 2:
Wir haben eine rote Fläche in Indesign, darüber ist ein PSD-Datei
platziert. Die PSD-Datei enthält eine Scheibe, der Rest der das
quadratische Format ausfüllt, ist transparent.
Dort, wo sich die Transparenzen der PSD-Datei mit der roten
Indesign-Fläche überlappen, ist die rote Indesign-Fläche
aufgehellt (Test-Datei: http://www.buero-s.de/ind/1.pdf).
Wenn wir dann in Indesign unter Bearbeiten den Transparenzfarbraum
von Dokument-CMYK auf Dokument-RGB umstellen, tritt der Effekt
in der PDF-Datei nicht auf
(Test-Datei: http://www.buero-.de/ind/22.pdf).
Jedoch meldet uns dann der callas PDF/X3-Inspektor beim Versuch,
eine PDF/X3 Datei zu erstellen, den Fehler "Verwendet RGB (Basisfarbraum DeviceRGB)".
Weiss jemand, warum im PDF DeviceRGB ankommt, obwohl in Indesign
als Arbeitsfarbraum eciRGB eingestellt ist?
Weitere Ideen zur Lösung des Problems?

(Momentan versuchen wir den Workaround, den Transparenzfarbraum auf Dokument-CMYK zu belassen und für die Scheibe einen runden Bildrahmen in Indesign zu verwenden. Ist aber keine wirkliche Lösung.)


Über Tipps wären wir sehr dankbar,
Gruß Dieter.

Hallo Dieter,

ein erster schneller Blick auf Ihre Daten ergab folgendes:

Zu 1) Sie geben Ihre Dokumente aus Adobe InDesign offensichtlich mit der Druckeinstellung "Druckprofil: PostScript-Farbmanagement" aus. Dies führt dazu, dass alle im Dokument verwendeten geräteabhängigen Farbräume bei der Ausgabe in eine PostScript-Datei in eine geräteunabhängige Variante konvertiert werden indem aus dem jeweiligen in InDesign gewählten Arbeitsfarbraum ICC-Profil ein PostScript CSA (Color Space Array), dem PostScript-Gegenstück zu einem ICC-Profil, gebildet wird.
Somit findet unter Umständen bei der Weiterverbeitung der Daten z.B. im Ausgabegerät eine Farbraumtransformation in den laut Ausgabegerät gewählten Zielfarbraum statt. Da der Text vermutlich in Weiss, also 0% CMYK eingefärbt wurde, entsteht im PostScript-Code ein CIEBasedDEFG-Farbraum, welcher wiederum im PDF als kalibrierter CMYK-Farbraum endet. Im Ausgabegerät findet dann eine CMYK-XYZ-CMYK-Transformation statt (sofern die Kalibrierungsinformation des PDF-Farbraums vorher nicht entfernt oder durch eine auf PDF-Ebene angwendete Farbraumtransformation egalisiert wird), die je nach Rendering Intent, Kalibrierungsinformation und Zielfarbraum natürlich durchaus zu einem Rot- bzw. Rosastich führen kann.

Zu 2) Das Rot des Logo-Hintergrunds liegt im RGB-Farbraum vor. Wenn nun ein transparentes Objekt darauf gelegt wird so wie es hier in Form des "freigestellten" Photoshop-Bildes geschah, muss zwangsweise bei PostScript- oder PDF 1.3 Ausgabe eine Transparenz-Reduzierung durchgeführt werden. Da hier zwei Objekte in RGB-Farbräumen verflacht werden müssen, muss ein passender Transparenzreduzierungs-Farbraum vom Anwender vorgegeben werden. Der einzig sinnvolle Farbraum ist hier natürlich RGB, da ansonsten die Schnittfläche beider Objekte einer RGB-nach-CMYK-Transformation unterworfen werden müssten, die nicht ohne sichtbare Folgen bleibt.
Die Meldung bzgl. der Verwendung eines RGB-Farbraums resultiert aus der tasächlichen Verwendung dieses auf der Seite. Das Graustufen-Bild links außen, welches Sie einfach durch ein Beschneiden der Seite visuell ausgeblendet haben, liegt in DeviceRGB vor. Wahrscheinlich haben Sie es als EPS platziert und somit konnte es von Adobe InDesign nicht getaggt werden.
Ein Croppen einer komplexen PDF-Seite, um störende Seitenobjekte auszublenden, ist keine empfehlenswerte Strategie. Einen der vielen Gründe haben Sie jetzt selbst am eigenen Leibe erfahren.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo Herr Zacherl,

herzlichen Dank für Iher Antwort!

zu 1)
Ja, beim Drucken als PS ist in Indesign wählen wir unter Farbmanagement tatsächlich das Druckprofil: PostScript-Farbmanagement" aus.
So steht es im PDF/X-3 Kochbuch-Rezept.
Als Endresultat soll ein geräteunabhängiges PDF entstehen.
Wie kann man das erreichen? Wo liegt der Fehler in unserem Workflow?

>welcher wiederum im PDF als kalibrierter CMYK-Farbraum endet
Wenn ich Sie richtig verstehe, ist unser PDF gar nicht
geräteunabhängig, aber genau das soll er ja sein.
Wie vermeidet man die Umwandlung RGB->CIEBasedDEFG-Farbraum->CMYK
im PDF?
Wie kann man die Kalibrierungsinformation des PDF-Farbraums
entfernen? Mit Pitstop?


zu 2)
Wir haben das PDF in Acrobat nur deshalb beschnitten, damit es
kleiner wird wg. Upload. Das hat ja aber offensichtlich nichts
gebracht ...
Das mit der Reduzierung verstehe ich.
Bzgl. dem Graustufenbild: Es ist kein EPS sondern ein platziertes
PSD mit eingebettetem allg. Graustufenprofil. Müssten wir hier ein
anderes Profil verwenden? Welches? Im Kochrezept steht, man solle
den Schwarzkanal des Auflagenprofil als Profil verwenden. Ist das
die Lösung?

Viele Grüße,
Dieter

Hallo Dieter,

wir (als Druckerei) hatten vor etlicher Zeit auch große Probleme mit unerwünschten rosa Einfärbungen beim Belichten/Proofen von PDF. Wir dachten zunächst, es wäre ein Problem in den PDF. Ich habe sogar ein PDF Herrn Stephan Jaeggi zur Prüfung gegeben, der nichts merkwürdiges daran finden konnte. Schließlich konnte wir feststellen, dass unser RIP (Scangraphic Combo / Monotype RipExpress) bei aktivierter Postscript-Farbverwaltung diese falschen Farbverschiebung erzeugt. Die Postscript-Farbverwaltung war entweder vorhanden, weil wir sie selbst irrtümlich bei der Druckausgabe aus Acrobat aktiviert hatten, oder aber weil das PDF entsprechende Tags mitliefert. Seit wir die Einstellung in Acrobat deaktiviert halten und gelegentlich in PDF vorhandene Postscript-Farbmangement-Tags mit Pitstop eleminieren haben wir keine Probleme mehr mit Rosa-Farben in Proofs und Drucken.

Zum medienneutralen CM-Workflow nach ECI-Kochbuch möchte ich anmerken: Ich finde das im (schrecklich umfangreichen) ECI-Indesign-Kochrezept vorgeschlagene Verfahren recht ... sagen wir mal avantgardistisch. Ich glaube zwar, dass die Zukunft im ICC-basierten (RGB)-Workflow liegt, aber eben die Zukunft und nicht die Gegenwart. Ich finde es zwar toll, dass einige Mutige die Vorreitersstellung einnehmen und das ausprobieren, denn irgendjemand muss ja die Erfahrungen sammeln, von denen später alle profitieren können. Ich selbst würde aber aus Gründen der Vorsicht und Sicherheit beim Datenaustausch mit der Druckerei einen gerätespezifischen CMYK-Farbraum empfehlen (möglichst nach ISO-Standard), den man ja bei PDF aus Indesign problemlos generieren kann. Ich weiss, wovon ich rede, ich arbeite selbst in der Druckvorstufe einer Druckerei;-) Zuviele Hürden sind noch zu nehmen, sowohl auf Seiten der Anwendungen (siehe die Schwierigkeiten, die im Indesign-Kochrezept auftauchen), als auch auf Seiten der Dienstleister (egal ob es am Know-How oder der verfügbaren Technik scheitert).

Martin

Hallo Herr Schüle,

zu 1)
Ich habe nicht behauptet, dass die Ausgabe per Druckoption "PostScript-Farbmanagement" falsch ist. Aber es muss Ihnen eben klar sein, dass dies zu einer geräteneutralen (oder eben kalibrierten) Farbbeschreibung innerhalb der Ausgabedatei führt. Dies wiederum macht unbedingt eine Farbraumtransformation in einen geräteabhängigen Zielfarbraum erforderlich. Je nachdem wie dieser parametrisiert wird kann das durchaus dazu führen, dass aus Weiss plötzlich Rosa wird.

Wenn Sie eine Wandlung von Farbräumen vermeiden bzw. vorhandene Profilierungs-/Kalibrierungs-Information entfernen möchten, warum denken Sie dann überhaupt über einen geräteneutralen Farbworkflow nach? Diese Dinge gehören untrennbar zusammen. Wenn mit geräteneutralen Farbdaten produziert wird, muss an geeigneter Stelle des Workflows unter Verwendung korrekter Parameter (wie Quellprofil, Zielprofil, Rendering Intent, CMM usw.) eine gesteuerte Farbraumtransformation stattfinden die als Ergebnis einen geräteabhängigen Zielfarbraum produziert.
Wer diesen Prozess aufgrund des Fehlens von Knowhow oder entsprechend leistungsfähiger Werkzeuge nicht in den Griff bekommt sollte tunlichst diese Produktionsweise meiden, da sie fast unweigerlich zu schlechteren Ergebnissen führt als ein klassischer, aber verlässlicher CMYK-Workflow.

zu 2) Ein Beschneiden der PDF-Seite mit den Acrobat-eigenen Funktionen stellt nur ein visuelles Ausblenden von Seitenbereichen dar. Hier wird nicht entfernt oder gelöscht.
Das Problem des Graustufen-Bildes ist weniger die Art des Profils als dass es pauschal unprofiliert von Adobe InDesign ausgegeben wird. Ob dies nun mit dem gewählten Bilddatenformat (PSD) oder anderen Dingen zusammenhängt müsste geprüft werden.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo Herr Zacherl,

danke für Ihre Antwort.

zu 1)
>>Wie kann man die Kalibrierungsinformation des PDF-Farbraums
>>entfernen? Mit Pitstop?
> ... vorhandene Profilierungs-/Kalibrierungs-Information entfernen
> möchten, warum denken Sie dann überhaupt über einen geräteneutralen > Farbworkflow nach? Diese Dinge gehören untrennbar zusammen
Ich habe da etwas in ersten Antwort falsch verstanden.
Natürlich will einen geräteneutralen Farbworkflow und mir ist auch
klar, dass deshalb im PDF die Profile vorhandenen sein müssen.
Probleme habe ich beim letzten Schritt: Wenn ich ein solches PDF habe und dann daraus ein PDF/X3 generiere - mit dem ICC-Profil, dass mir die Druckerei für die Kombination Zieldruckmaschine/Papier gegegeben hat - dann ging ich davon aus, dass es funktionieren muss.
Bitte korigieren Sie mich, falls ich da was falsch verstanden habe:
Beim RIP vor Proofen/Druck findet dann doch eine letzte Transformation des geräteunabhängigen Farbraums des PDFs in den Zielfarbraum statt, also in den Farbraum, der durch das ICC-Profil beschrieben wird, das ich beim Erstellen des PDF/X3s ausgewählt habe.
Wenn das so ist, dann würde das doch bedeuten, dass entweder etwas beim Erzeugen des ICC-Profils in der Druckerei schiefgeht oder aber beim Rippen!?

> ... aufgrund des Fehlens von Knowhow oder entsprechend
> leistungsfähiger Werkzeuge nicht in den Griff bekommt sollte > tunlichst diese Produktionsweise meiden ...
Wir möchten genau dieses Know-how aufbauen und die notwendigen Werk-
zeuge ggf. anschaffen. Und genau deshalb wenden wir uns an ein Forum,
um auftauchende Fragen/Probleme zu lösen.


zu 2)
> Ob dies nun mit dem gewählten Bilddatenformat (PSD) oder anderen
> Dingen zusammenhängt müsste geprüft werden.
In Indesign selbst ist das PSD-Bild getaggt (Allg. Graustufenbild).
Warum es dann ungetaggt im PDF ankommt, ist mir nicht klar.
Können Sie uns einen Ansatz sagen, wie man das rausbekommen kann?


Danke + Gruß,
Dieter

Hallo Martin,

danke für Deine Tipps und das Mitteilen Deiner Erfahrungen!

Wir haben gerade ein kleines Projekt, dass wir einfach als Test des RGB-Workflows verwenden. Wir hoffen immer noch, dass wir das hinbekommen, damit wir den kommenden 80-Seiter gleich angehen können.
Aber gut möglich, dass wir auch wieder zu gerätespezifischen CMYK-Workflow zurückkehren ...


Gruß Dieter

"Beim RIP vor Proofen/Druck findet dann doch eine letzte Transformation des geräteunabhängigen Farbraums des PDFs in den Zielfarbraum statt, also in den Farbraum, der durch das ICC-Profil beschrieben wird, das ich beim Erstellen des PDF/X3s ausgewählt habe."

Nein, dies ist nicht so. Ein PDF-X3 erlaubt nur CMYK-Daten + Schmuckfarben. Also muss das PDF bereits im Zielfarbraum vorliegen. Das gewählte Profil beschreibt nur, in welchem Zielfarbraum das PDF vorliegt, damit der Druckdienstleister "Bescheid" weiß.

Der andere Weg ist, ein PDF zu generieren, in dem alle Daten in ECI-RGB vorliegen und dann erst im Rip von ECI-RGB in den Zielfarbraum zu konvertieren. Dies ist mit PDF-X3 jedoch nicht möglich.s.o.

Hallo loethelm,

wenn im RIP das gleiche Profil verwendet wird, wie das im PDF/X3,
dann wird doch in den gleichen Farbraum transferiert, d.h. es kann hier doch keine Farbverschiebung auftreten, oder?

Gruß Dieter

Hallo Dieter,

Sie schrieben:
>Beim RIP vor Proofen/Druck findet dann doch eine letzte >Transformation des geräteunabhängigen Farbraums des PDFs in den >Zielfarbraum statt, also in den Farbraum, der durch das ICC->Profil beschrieben wird, das ich beim Erstellen des PDF/X3s >ausgewählt habe.
>Wenn das so ist, dann würde das doch bedeuten, dass entweder >etwas beim Erzeugen des ICC-Profils in der Druckerei schiefgeht >oder aber beim Rippen!?

Sofern die geräteneutrale PDF/X-3 nicht vor der Ausgabe per Software in den benötigten Ziel-/Prooferfarbraum transformiert wird (z.B. mit Heidelberg Supercolor oder GretagMacbeth iQueue) findet diese Farbraumtransformation tatsächlich im Ausgabegerät selbst statt. Da in einem PostScript-Ausgabegerät aber nicht mit ICC-Profilen, sondern mit CSAs und CRDs gearbeitet wird muss die RIP-Lösung entweder eine vorgeschaltete ICC-basierte Farbraumtransformation einsetzen (um dann bereits farblich transformierten Code zu verarbeiten) und eine spezielle PDF/X-3 Unterstützung bieten, welche in der Lage ist das in die PDF/X-Datei eingebettete Output Intent Profil zu extrahieren und als Zielprofil zu nutzen (außer man gibt den Zielfarbraum "manuell" vor). Außerdem ist der global im PDF definierte und/oder die auf Objektebene definierten Rendering Intents zu honrieren bzw. muss die RIP-Lösung (wie die oben genannten Software-Tools) in der Lage sein, bei fehlenden oder falsch definierten Rendering Intents, am besten für Bild- und Vektordaten und pro Grundfarbraum getrennt jeweils einen bevorzugten Standard Rendering Intent vorzugeben.

Sie sehen schon, dass es um weit wehr geht als "nur" ein Zielprofil in Form eines Output Intents in ein PDF/X-3 File einzubetten damit die Farbe dann richtig aus dem Ausgabegerät kommt. Die Anzahl der Dienstleister die Wissens- und Equipment-seitig in der Lage sind das alles zu berücksichtigen und in die richtigen Bahnen zu lenken ist meiner Meinung nach sehr begrenzt.

Zur PSD-Problematik: In einem solchen Fall bleibt Ihnen wohl nur empirisches Vorgehen übrig. Vereinfachen Sie die Testumgebung so weit wie möglich und prüfen Sie, ob die Ausgabe dann noch dem entspricht was Sie erwarten. Platzieren Sie also z.B. das PSD-File in ein leeres Adobe InDesign Dokument und geben Sie dieses mit den verwendeten Druckeinstellungen aus. Erzeugen Sie daraus Ihr PDF und prüfen Sie es per Preflight (oder besser noch Enfocus PitStop weil Sie es dort direkt auswählen können). Wenn das noch korrekt ist, dann bringen Sie langsam andere Objekte und Transparenz ins Spiel.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Hallo loethelm,

das ist falsch.
Sie verwechseln hier PDF/X-1a mit PDF/X-3. PDF/X-3 ist die Erweiterung des PDF/X-1a Standards um die Möglichkeit eines geräteneutralen Farbworkflows. Somit sind sehr wohl geräteneutrale Farbbeschreibungen zulässig.

Es macht aus unserer Sicht auch nur dann Sinn PDF/X-3 zu erzeugen/verwenden, wenn man diesen geräteneutralen Farbworkflow ausnutzen will. Wenn man an einem klassischen CMYK-Workflow interessiert ist, dann ist der Einsatz von PDF/X-1a unkritischer, weil er nicht die Gefaht in sich birgt, dass versehentlich in den Auftragsdaten enthaltene nicht-CMYK Farben übersehen werden und es dann zu einer unkontrollierten Farbraumtransformation kommt.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Dieter,

um es nochmals ganz klar zum Ausdruck zu bringen: Ein normaler PostScript 3 RIP, welcher PDF-Dateien direkt verarbeiten kann, hat keine Ahnung davon was PDF/X ist! Er wird in der zu verarbeitenden PDF/X-Datei einfach nur eine PDF 1.3 Datei sehen die er genauso abarbeiten wird wie jede andere PDF 1.3 Datei auch. Die PDF/X-3 Unterstützung einiger RIP/Proof-Systeme hat nichts mit dem Adobe PostScript-Standard zu tun, sondern ist eine Hersteller-spezifische Erweiterung die dafür sorgt, dass z.B. vor dem eigentlichen Interpretationsprozess das im Output Intent definierte ICC-Profil extrahiert und als Zielprofil für eine evtl. stattfindende Farbraumtransformation genutzt wird.
Ist diese Fähigkeit nicht gegeben, dann ist die zu verarbeitende PDF/X-Datei aus der Sicht des RIPs erst einmal unnötigerweise um 1 bis 1,5 MB zu groß, weil sie ein CMYK ICC-Profil in sich birgt, was aber nie zur Anwendung kommt. Zweitens würde das im RIP als Standard definierte CRD benutzt werden um die Transformation in den Zielfarbraum zu steuern. Solange der RIP-Anwender dieses CRD nicht selbst erstellt, auf den RIP übertragen und dort als Standard deklariert hat ist dies das CRD das der RIP-hersteller standardmässig auf dem RIP vorinstalliert hat. Und dies kann irgendeines sein das irgeneinen CMYK-zielfarbraum definiert und somit ist auch das farbliche Eregbnis nicht voraussagbar.

Wenn Ihr Dienstleister auch diesem Irrglauben erlag, dann könnte dies auch schon die Erklärung für den Rosa-Stich sein, weil unsere Erfahrung auch belegt, dass unkontrolliert im RIP stattfindende Farbraumtransformationen häufig einen Rotstich produzieren.

Mit freundlichen Grüßen

Robert Zacherl

************************
IMPRESSED GmbH
http://www.impressed.de

Sorry,

Asche auf mein Haupt. Natürlich meinte ich PDF-X1a. Demnächst denke ich mal schneller, als ich tippe. Ich hoffe ich habe keine Verwirrung gestiftet und bin froh, dass Sie, Herr Zacherl mich so schnell korrigiert haben.

Hallo Herr Zacherl,

danke für Ihre ausführlichen Erklärungen.
Ich war der Meinung, dass unser Dienstleister weiss, was er mit einem
von uns erzeugten PDF/X3 zu tun hat. D.h. dass er sich dann um die Rendering Indents etc. kümmert. Ich glaub(te) auch, dass der RIP beim Dienstleister korrekt eingestellt war, da mir gesagt wurde, dass ein Techniker von Heidelberger Einstellungen gemacht hätte, weil alles immer so rotstichig gewesen sei.
Bin jetzt an dem Punkt, an dem ich mir eingestehen muss, dass für uns wohl derzeit der Weg über PDF/X3 keinen Sinn macht. Dazu bräuchte ich wohl sebst den 100%igen Durchblick und unser Dienstleister auch.

Ich habe mir jetzt folgenden Workflow überlegt. Wäre toll, wenn Sie noch kurz Ihre Meinung/Verbesserungsvorschläge schreiben könnten:

- Bilder als auch Farben in Indesign weiter als RGB (getaggt mit
ECIRGB) -> Arbeitsfarbraum ECIRGB
- CMYK Arbeitsfarbraum = Zielfarbraum für aktuell anstehendes Projekt
==> z.B. Euroscale Coated/uncoated oder eben ein Profil von der
Druckerei
- Erzeugen einer PS-Datei, in Farbeinstellungen vom Druckdialog
dann das gleiche CMYK-Profil angeben, dass dem Arbeitsfarbraum
enspricht
- PS distillen (Farbmanagement in Distiller deaktivieren)
- In Pitstop prüfen

==> Indesign nimmt dann die Umwandlung von RGB nach CMYK vor.
Da wir Farbwerte als RGB anlegen und auch alle Bilder
RGB getaggt sind, sind wir bis zum endgültigen Erstellen
der PS-Datei flexibel, welchen CMYK-Arbeitsfarbraum/CMYK-Profil
wir verwenden (weil dann kein CMYK in Dokument vorhanden ist und
wir somit einfach den Arbeitsfarbraum wechseln können).
==> Im PDF sind dann keine ICC-Profile mehr vorhanden


Vielen Dank für Ihre Mühen
Dieter

Hallo Herr Zacherl,

bei meinem oben beschriebenen "neuen" Workflow have ich auch noch
ein Problem: In Indesign platzierte Illustrator-Objekte (eciRGB getaggt) sind auch im PDF noch RGB, d.h. bei Erstellung von PS wird
wider Erwarten hier nicht von RGB nach CMYK gewandelt.
Bei platzierten PSD (auch getaggt) funktioniert es hingegen prima, d.h. die RGB-Bilder werden von Pitstop als CMYK deklariert.

Bug? Oder ein Denkfehler?

Gruß Dieter