Guten Tag Herr Homann! vielen Dank für Ihre Antwort. Ich habe auch das Posting von Herrn Euler gelesen, möchte aber zunächst auf Ihre Anregungen / Denkanstöße eingehen. Ursprünglich war meine Frage ja auf die Gegebenheiten in InDesign bezogen und meine Befürchtung, dass ich mir durch die Wahl eines von InDesign geforderten CMYK-Arbeitsfarbraums den Weg zur medienneutralen Datenhaltung verbaue. Wenn ich jetzt Ihren Beitrag lese (Ihr Buch kenne ich ja schon :-) dann ist mir die Sache mit der vom RenderingIntent abhängigen Farbgleichheit zwischen CMYK-Farbe und ECI-RGB Farbe bekannt. Aber die Frage betr. des CMYK-Farbraums in InDesign bleibt. Nach einigem Überlegen ist mir klar, dass die Definition eines Farbtons über CMYK-Werte in einem Layout nie eindeutig sein wird, weil eine CMYK-Wertekombination auf unterschiedlichen Maschinen auch zu unterschiedlichen Farbeindrücken führt. Also müsste die Wertekombination, die ich mal definiert habe, vom Maschinenprofil umgerechnet werden und dann sind wir wieder bei meiner InDesign-Fragestellung. In Corel habe ich so einen Zirkus jedenfalls nicht. Da fragt niemand nach einem CMYK-Arbeitsfarbraum. Ich habe den ECI-RGB und damit basta. Und CMYK-Daten werden angezeigt mit dem jeweils dazu ausgewählten Druckerprofil oder aber sie werden gar nicht simuliert. Also wozu brauche ich einen CMYK-Arbeitsfarbraum? Wozu braucht InDesign einen, wenn Corel keinen braucht und die Farben dennoch stimmen? Erst wenn ich das Ausgabegerät bestimme, um Daten zum Drucker / zur Druckerei zu senden, dann brauche ich ein CMYK-Profil, sowhl bei Corel als auch bei InDesign. Hierauf zielte mein Frage und vielleicht bin ich ja missverstanden worden. Die einfache Idee mit den Schmuckfarben könnte ja nun auch eine "Lösung" darstellen: Denn wenn ich alle meine Grafikfarben in Sonderfarben (HKS oder Pantone) anlege und CMYK vermeide, dann hinterlege ich ja eigentlich Lab-Werte im Dokument und die werden von der Wahl eines ominösen CMYK-Arbeitsfarbraums in InDesign gewiss nicht angetastet. Wenn ich dann auf dem Proofer ausgebe, kann ich entweder InDesign die Umsetzung in die korrekten Farben überlassen indem ich bestimme, dass die Sonderfarben als CMYK-Prozessfarben ausgegeben werden und verwende dazu natürlich das Profil der Druckerei oder wenn ich idealisiert ECI-Proofen will eben das Profil des Proofers. Oder ich sende an meinen Proofer die Sonderfarben und überlasse BestColor die Umsetzung nach CMYK. Best hat nämlich Umrechnungstabellen integriert. Dieser Workflow aus ECI-RGB Bitmap-Daten und Sonderfarben unter Verzicht auf CMYK-Daten im Layout (vom Schwarz für die Schrift etc. abgesehen) müsste doch eigentlich perfekt funktionieren? Oder? Und zur PDF-X3 konformen Dateierstellung muss ich halt das Profil der Druckerei verwenden, um die Sonderfarben nach CMYK umzurechnen. Und wenn ich eine Schmuckfarbe definitiv in dem gleichen Ton haben will, wie sie in einem ECI-RGB-Bitmap vorkommt, dann muss ich eben mit der Pipette ausmessen und diese Schmuckfarbe als ECI-RGB-Bitmap anlegen. Dann wird sie eigentlich auch später mit dem gleichen RI behandelt und nach CMYK transformiert, wie das Bitmap und ich habe keine Probleme. ----- Original Message ----- From: "Jan-Peter Homann" <homann(a)colormanagement.de> To: <eci(a)lists.transmedia.de> Sent: Friday, June 14, 2002 3:40 PM Subject: [Eci] ECI Workflow-Problem ( grundsätzliche Designfehler ) dann, und Bilder Ist mir klar! Wenn das mein angefragtes Problem beträfe... ich würde es umgehen durch Anlegen der Schmuckfarbe als ECI-RGB-Bitmap, das dann bei der Transformation dem gleichen RI unterliegen müsste. Siehe mein Statement oben. Na das wundert mich jetzt aber! Schmuckfarben wie HKS und Pantone etc. sind aber doch medienneutral oder? Deswegen gibt es sie ja. Wieso sollte ich die korrigieren müssen? Daten zu Wenn ich wirklich gewzungen wäre, derart korrigierend und manuell, also nach subjektiven Kriterien, einzugreifen, dann brauche ich auch kein Farbmanagement mehr. Dann haben wir doch nur das Gleiche, was Agenturen und Druckereien schon vor 10 Jahren praktiziert haben: Rumprobieren bis es stimmt. gesamte für den Irgend etwas stimmt da nicht! Medienneutrales PDF X3? Ich denke das PDF X3 ist nicht medienneutral sondern stellt z.B. eine PDF-Datei dar die nach strengen Kriterien so aufgebaut ist, dass eie Druckerei damit farbrichtig und auch in anderer Hinsicht (Schrifteinbettung, Überfüllen etc.) richtig produzieren kann. Also kann PDF-X3 bereits mit einem CMYK-Profil passend zur Maschine erstellt werden. Gemäß meiner obigen Betrachtungen könnte ich aber genau so gut ein PDF X3 erstellen, in dem die Bilddaten im ECI-RGB und alle Grafikfarben etc. als Sonderfarben definiert sind. Pantone hat ja wohl genug verschiedene Tönungen. Das wäre zwar medienneutral, könnte aber z.B. nicht ohne Weiteres farbrichtig im Internet präsentiert werden. Es wäre ein theoretisches PDF, das weder im Druck (für jede Sonderfarbe eine Platte) noch im Web (Umrechnungsvorschriften für Pantone / Lab / RGB fehlen) korrekt dargestellt wird. PDF-X-3 Umsetzung auf nicht Siehe mein Vorschlag mit den Sonderfarben. als Dann wären wir wieder bei nahezu dem gleichen Zustand wie vor Einführung von Farbmanagement, wie ich schon bemerkte. schummelt Ich denke, es ist ein Arbeitspapier und keine Arbeits-Anleitung. komplexer Einen angenehmen und erfolgreichen Tag, das wünsche ich Ihnen Clemens M. Hürten IdeeCreativ - Werbung / Stuttgart Fon 0711 - 9 01 87 65 - Mobil 0170 - 38 58 079 www.ideecreativ.de werden. keine diesen

Henrik Schmidt wrote: Hallo Herr Schmidt Bei meiner Kritik am ECI Whitepaper geht es nicht um die Frage Lab oder ECI-RGB.. Ich finde die Arbeit der ECI im Großen und Ganzen nach wie vor wegweisend für das Colormanagement. Ich sehe es allerdings als äußerst heikel an, zum jetzigen Zeitpunkt die Übergabe von als PDF/X-3 kodierten medienneutralen Daten an die Druckerei als produktionsreif zu deklarieren. Immerhin hat das ECI-Whitepaper die Bezeichnung "Richtlinien für die medienneutrale Farbdatenverarbeitung gemäß des ICC-Standards" Auch im Medienstandard Druck 2001, der ja als Referenz für das Handling von Daten und Proofs in Deutschland gilt und von der ECI wesentlich mitgestaltet wurde, gibt es keine Unterschiedung zwischen PDF/X-1a und PDF/X-3 in der Datenanlieferung. Aufgrund der langen Gültigkeit eines ISO Standards ist es sehr gut, daß wir den PDF/X-3 Standard schon jetzt haben, damit wir klar wissen, wo wir drauf hinarbeiten müssen. Heutzutage aber so zu tun, als PDF/X-3 für den Massenmarkt produktionsreif ist - nichts anderes besagt der Medienstandard Druck 2001 - finde ich fatal, wenn wir breiten Anwenderkreisen beherrschbare Colormanagement-Workflows nahe bringen wollen. Weiterhin bin ich nach wie vor der Meinung, daß die Empfehlung der ECI-Richtlinien (Punkt 7.2) Bilder in ECI-RGB zu kodieren und Vektorgrafiken in anderen Farbräumen, sich um wesentliche Probleme im Colormanagement herumschummelt. Sobald die Gestaltungsvorgabe besteht in Bildern und Vektorgrafiken gleiche Farben zu spezifizieren, bricht der gesamte Workflow zusammen. Daraus folgt, daß ich bei einem datenbank gestützen Workflow-System für Repro, Reinzeichnung und Archivierung streng danach unterscheiden muß, ob in meinem Layout die Anforderung von gleichen Farben in Vektorgrafiken und Pixelbildern besteht oder nicht. Dies macht den gesamten Workflow erheblich komplexer. Weiterhin bin ich der Meinung, daß es im Anhang 1 der ECI-Richtlinien wenig Sinn macht zwischen Workflow 2 (Referenz-CMYK) und Workflow 3 (Verfahrens CMYK) zu unterschieden. Bei der Übergabe von CMYK-Daten ist allein maßgeblich, was laut Anlieferungsrichtlinien der Druckerei für einen druckverbindlichen Proof maßgeblich ist. Wenn die Druckerei ein Referenz-CMYK akzeptiert, kann ich mich im Falle einer Reklamation darauf berufen. Wenn nicht, dann muß ich Verfahrensspezifisch ausliefern. Für die Druckvorstufe ist ein Referenz-CMYK auf jeden Fall eine entscheidende Erleichterung. Ein nach wie vorher ungelöstes Problem ist die Frage, wie denn die ICC-Profile für ein Verfahrens angepaßtes CMYK einer Druckerei hergestellt wurden. Die wenigeten Druckereien sind in der Lage sauber und standardisiert zu Arbeiten. Falls sie das sind, dann können sie auf ein Referenz-CMYK standardisieren und machen uns allen das Leben erheblich leichter. Wenn sie das nicht können, dann sind die Verfahrensangepaßten CMYK-Profile, die so im Umlauf sind, mehr oder weniger Zufalls-Produkte. Dies wird noch heikler, wenn die Druckerein verfahrensangepßte CMYK-Profile zur Verfügung stellen, die zeigen daß die Testform nicht ordentlich gedruckt wurde und die Profile Ecken und Kante haben. Gerade hatte ich den Fall, daß das als gültig deklarierte Profil für die größte Auto-Zeitschrift in der Bundesrepublik unbrauchbar war. Wenn solche Fehler absoluten Profis unterlaufen, wie sieht es bei der Druckerei um die Ecke aus, die guten Willens ist und ein verfahrensangepaßtes Profil für ihre Kunden produziert ? Wie sieht eigentlich die Rechtslage aus, wenn ich ein Proof mit einem verfahrensangepaßten CMYK-Profil erstelle, und der Medienkeil nach der Messung eine für diese Papierklasse nicht akzeptable Abweichung zeigt. Kann ein abweichender Druck in diesem Fall reklamiert werden oder nicht ? Um es nochmals auf den Punkt zu bringen: Ich bin der Meinung, daß beherrschbare Colormanagement-Workflows für die breite Anwender-Masse nur über Referenz-CMYK und die Auslieferung von PDF/X-1a möglich sind. Alles andere ist Basteln und Experimentieren. Wenn die breite Masse in der Lage ist Referenz-CMYK mit PDF/X-1a Kodierung zu erzeugen, sollte der nächste Schritt sein, wie man aus einem medieneutralen PDF/X-3-Bestand mit möglichst guter Qualität und hohem Automatisierungsgrad verschiedene Referenz-CMYK / PDF/X-1a Dateien erzeugen kann. In Bezug auf die Druckereien sollten wir darauf hinarbeiten, daß sie sauber standardisieren und nach einem Referenz-CMYK PDF/X-1a Proof problemlos drucken können. Wenn Sie all diese Ansichten als politisch betrachten, dann bin ich ein Vollblut-Politiker. mfG Jan-Peter Homann -- --------------------------------- neue Rechnungs- und Lieferadresse --------------------------------- colormanagement.de ------------- fon / fax 030 611 075 18 Jan-Peter Homann -------------------- mobil 0171 54 70 358 Schönhauser Allee 6/7 ------ http://www.colormanagement.de 10119 Berlin ------------ mailto:homann@colormanagement.de

Hallo Herr Schmidt Ich meine bei der Übereinstimmung von Farben in Vektor und Pixelbildern nicht den Spezialfall, daß eine echte Sonderfarbe dort jeweils vorkommt. Of genugt wird komplett in CMYK gearbeitet und eine Hausfarbe die als Sonderfarbe komminiziert wird soll als CMYK-Definition im Bild und in der Vekorgrafik gleichartig erscheinen. Ich denke das dieser Fall häufiger als 0,125% vorkommt. Dies ist zumindest bei einem großen Kunden von mir der Fall. Wenn sie solch eine Gestaltung auf einen medienneutralen Workflow übertragen wollen, müssen sie für Vektoren und Pixelbilder den gleichen Arbeitsfarbraum verwenden und das gesamte Dokument mit einem einheitlichen Rendering Intent umsetzen. Wie dies zu lösen ist, schweigt sich die ECI in ihrem aktuellen Whitepaper bisher aus. Mit editierten Profilen kann man da eine Menge machen. Was passiert aber, wenn der Empfänger der medienneutralen PDF/X-3 Datei die Pixelbilder mit perceptual matcht und die Vektoren mit relativ farbmetrisch ? Wer ist in diesem Fall der Schuldige, wenn in der gedruckten Anzeige beim weich freigestellten Objekt als Pixelbild vor einem technischem Fond als Vektorgrafik miteinmal miteinmal ein Rechteck beim Übergang vom Pixelbild zum Vektorfond auftaucht. Wenn die PDF/X-3 Datei vor der Auslieferung in PDF/X-1a umgewandelt und geprooft wird, kann soetwas sicher ausgeschlossen werden. mfG Jan-Peter Homann Henrik Schmidt wrote: -- --------------------------------- neue Rechnungs- und Lieferadresse --------------------------------- colormanagement.de ------------- fon / fax 030 611 075 18 Jan-Peter Homann -------------------- mobil 0171 54 70 358 Schönhauser Allee 6/7 ------ http://www.colormanagement.de 10119 Berlin ------------ mailto:homann@colormanagement.de

Hallo Florian I beschäftige mich seit ungefähr einem Jahr sehr intensiv mit verschiedenen Ansätzen komplette Dokumente medienneutral anzulegen und möglichst automatisiert über Queues auf verschiedene Ausgabefarbräume umzusetzen. Vorgabe für alle Ansätze ist bei mir, daß gleiche Farben in Vektorgrafiken und Pixelgrafiken nach der Transformation auf den Ausgabefarbraum auch gleich bleiben. Wie du unten erwähnt hast, müssen dann die Daten mit dem gleichen Intent umgesetzt werden. Hier liegt nun der Hase im Pfeffer begraben. Wenn ich perceptual wähle, werden je nach Ausgabeprofil gesättigte Schmuckfarben nach einer anderen Methode gematcht. Desweiteren sind die derzeit verfügbaren Tools wie der Logo ColorPicker darauf ausgerichtet bei Angabe einer Pantonefarbe die passende Version für einen farbmetrischen Match zu berechnen. Es bliebe also die Version für Vektoren und Pixel relativ farbmetrisch zu nutzen. Hier habe ich das Problem, daß relativ farbmetrisch in den Tiefen wie absolut farbmetrisch arbeitet. Je heller das Vierfarbschwarz im Zielfarbraum ist, desto stärker ist der Verlust in der Tiefenzeichnung. Eine programmübergreifend zur Verfügung stehende Blackpoint-Kompensation wie in Photoshop würde da schon ein Verbesserung bringen. Desweiteren bietet relativ farbmetrisch keine Korrektur der Graubalance. Wenn ich eine medienneutrale Grundausarbeitung mache, die für ein typisches Bilderdruckpapier mit ISO-konformen Anteil an optischen Aufhellern ein tolles Ergebnis bringt, dann erhalte ich mit der relativ farbmetrischen Umsetzung auf ein gelbliches SC-Papier im Tiefdruck oder LWC-Papier im Rollenoffset nur ein suboptimales Ergebnis. Egal welchen Intent ich auch wähle, für die automatischer Umsetzung anspruchsvoller medienneutraler Dokumente reichen die klassischen Colormanagement-Workflows aus den obigen beschrieben gründen (noch) nicht aus. Immerhin kommt man aber durchaus mit weniger manuellen Korrektursteps als bisher aus und kann als Repro-Unternehmen Proofs erstellen, die sehr exakz mit denen in der Druckerei übereinstimmen. Allein das ist schon ein immenser Fortschritt. Wenn ich aber nach der Wandlung des medienneutralen Dokumentes immer noch manuell korrigieren muß, so stellt sich die Frage, ob ich den Aufwand für Korrekturen an Bilddaten und Farbdefinitionen weiter senken kann, wenn ich die Korrekturen statt ins Bild in das Profil hereinrechne. Hier kann ich nur bestätigen, daß ich hier für einen großen Kunden von mir deutliche Qualitätsverbesserungen erreicht habe. In diesem Workflow, der sich nach wie vor in der Optimierungsphase befindet, wird eine PDF/X-3 Masterdatei erzeugt, in der sowohl Pixel als auch Vektoren in ECI-RGB definiert sind. Das eigentliche matchen findet dann über einen ColorServer statt und ausgeliefert wird verfahrensangepasstes CMYK inkl. Proof. Herzliche Grüße Jan-Peter Florian Süßl wrote: -- --------------------------------- neue Rechnungs- und Lieferadresse --------------------------------- colormanagement.de ------------- fon / fax 030 611 075 18 Jan-Peter Homann -------------------- mobil 0171 54 70 358 Schönhauser Allee 6/7 ------ http://www.colormanagement.de 10119 Berlin ------------ mailto:homann@colormanagement.de

Hallo Herr Homann, entschuldigung, wenn ich mich hier einklinke, weil meine Thematik das Gleiche betrifft. ----- Original Message ----- From: "Jan-Peter Homann" <homann(a)colormanagement.de> To: <eci(a)lists.transmedia.de> Sent: Thursday, June 20, 2002 11:36 AM Subject: [Eci] Re ECI Workflow-Problem Vektor und Pixel verschiedenen automatisiert und bleiben. Ist das nicht ein zu anspruchsvoller Ansatz, eine zu hohe Forderung? Dann müsste nämlich wirklich jedem Objekt innerhalb eines Layout ein RI zugeordnet werden. In meiner alltäglichen Arbeit habe ich nur in wenigen Ausnahmefällen die Situation, dass eine Vektorgrafik den absolut gleichen Farbton haben soll, wie ein zugehöriges Bild. In diesen Fällen kann ich das Problem doch sicher dadurch lösen, dass ich die Farbe mittels Pipette aus dem Bild entnehme und dann das Vektor-Objekt als ECI-RGB mit dieser Farbe fülle. Falls erforderlich (wegen des RI, der je nach späterem Prozess eventuell zwischen Bitmap- und Vektordaten unterscheidet), könnte ich sogar eine Bitmap-Füllung für die Vektorgrafik anlegen. umgesetzt Bei meinem obigen Vorschlag nicht. -----------------snipp manuell Korrekturen an Korrekturen statt Beziehen sich solche Korrekturen auf die RenderingIntent-abhängigen Tabellen? sich nach erzeugt, eigentliche Heißt das, dass Ihr "ColorServer" objektbezogene RenderingIntents verarbeitet? Einen angenehmen und erfolgreichen Tag, das wünsche ich Ihnen Clemens M. Hürten IdeeCreativ - Werbung / Stuttgart Fon 0711 - 9 01 87 65 - Mobil 0170 - 38 58 079 www.ideecreativ.de