4:44 p.m.
Hallo Jan-Peter,
du sprichst bei PDF/X-3 nur von dem angehängten Profile, welches den
anzunehmenden Wiedergabefabraum beschreibt. Um jetzt aber die Objekte
des PDF richtig zu separieren brauche ich noch weit mehr. Es können in
diesem PDF ja RGB (ECI-RGB), CMYK (DVSPlus) oder auch Lab Daten
enthalten sein. Ich muß also ein Objektorientiertes Color Management
machen, welches als Zielfarbraum das " default Dokumenten Profile"
oder ein vom RIP bereitgestelltes Profile annimmt. Da ich an jedes
Objekt ein anderes Profile hängen kann, kann auch die Separation für
Vektor und Pixeldaten unterschiedlich sein. Jetzt zum Renderintent, in
jedem Profile steht ein default Renderintent (meistens perceptual)
welchen man benutzen kann. Wenn dieser Renderintent richtig gewählt
ist, funktioniert auch der ECI-Workflow wieder, da der Endanwender
sich nicht um den Renderintent kümmern muß, sondern der Profile
Ersteller Sorge dafür zu tragen hat, daß der richtige Renderintent
eingetragen ist. Eine feste Umsetzung durch das RIP (die CMM) ist
jedoch auch möglich, wenn von Aussen feste Intents übergeben werden.
Ich persönlich glaube aber, daß wir von diesem Workflow noch weit weg
sind und das Caos beim Proofen von solchen Dateien vorprogrammiert
ist. Ein wahrer Proof kann dann nur noch von 1-Bitdaten gemacht
werden, bei denen das Color Management (Separation) ja durch das
Belichter RIP gemacht wurde.
Beste Grüße
Ulf Grossmann
-----Original Message-----
From: Jan-Peter Homann [mailto:homann@colormanagement.de]
Sent: Friday, June 14, 2002 3:40 PM
To: eci(a)lists.transmedia.de
Subject: [Eci] ECI Workflow-Problem ( grundsätzliche Designfehler )
Hallo Herr Hürten
Der gesmate ECI-RGB-Workflow funktioniert nur sehr
eingeschränkt, wenn sie
tatsächlich das gesamte Dokument medienneutral halten wollen.
Spätestens dann,
wann sie versuchen eine Schmuckfarbe medienneutral in einer
Vektorgrafik und
einem Bild anzulegen, bricht der ECI-Workflow zusammen. Sie
müßten dann Bilder
und Grafiken mit dem gleichen Rendering Intent umsetzen.
Je nach Kombination aus Motiv, Schmuckfarbe, Ausgabefarbraum und
Rendering-Intent kann das mal gut gehen, oder auch nicht.
Für welchen Intent Sie sich auch entscheiden, je nach
Ausgabefarbraum sind
jedesmal andere manuelle Korrekturen an den medienneutralen
Schmuckfarben-Definitionen und / oder den Bilddaten notwendig.
In diesem Fall sind sie allerdings gezwungen die manuell
korrigierten Daten zu
archivieren und der ECI-Workflow ist dann in der Praxis doch
erheblich
komplexer als im ECI-Whitepaper
Besonders heikel ist dabei, daß die ECI es ausdrücklich
empfiehlt das gesamte
medienneutrale Dokument als PDF/X-3 Datei mit angehängtem
Output-Intent für den
"blind exchange" medienneutraler Daten einzusetzen.
Aufgrund der oben beschreibenen Problematik kann es
passieren, daß die PDF-X-3
Datei auf dem idealisierten Proof zwar gut aussieht, aber bei
der Umsetzung auf
einen realen Ausgabefarbraum ohne manuelle Korrekturen
suboptimale bis nicht
akzeptable Ergebnisse heraus kommen.
Gerade im Bereich sehr hochqualitativer Arbeiten sollten
medienneutrale
Dokumente von einem erfahrenen Lithooperator in den
Zielfarbraum gewandelt
werden, geprooft, visuell begutachtet, wenn nötig manuell
korrigiert und als
CMYK-PDF/X-1a Datei mit eingebettetem Output-Intent
ausgeliefert werden.
Das gesamte ECI-Whitepaper beschreibt leider nur ideale
Abläufe und schummelt
sich um die nach wie vor notwendigen visuellen Kontrollen und
manuellen
Korrekturen herum.
In der Praxis sind daher medienneutrale Abläufe in der Regel
deutlich komplexer
als im ECI-Whitepaper beschrieben.
:-) Jan-Peter Homann
"Clemens M. Hürten" wrote:
...
des
Bei den ECI-RGB-Daten macht das Ganze ja nichts, weil die immer im
ECI-RGB-Farbraum bleiben und nur je nach Ausgabegerät mal mit dem
Proofer-Profil und mal mit dem Profil der Druckerei
transformiert werden.
> Bei den CMYK-Daten sagt aber InDesign ganz deutlich beim Wechsel Profils, dass
es die CMYK-Daten umrechnen wird. Damit aber
hätte ich keine
medienneutralen Daten mehr im Layout.
Unterliege ich hier einem Missverständnis? Wenn nein, wie
kann ich diesen
Konflikt im Sinne medienneutraler Datenhaltung
eines
kompletten Layout
lösen?--
---------------------------------
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
_______________________________________________
Eci mailing list
Eci(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci
7:19 p.m.
New subject: [Eci] Re: [Eci] RE: [Eci] ECI Workflow-Problem ( grundsätzliche Designfehler )
Hallo Herr Grossmann,
Sie haben zwar direkt Herrn Homann angesprochen, aber ich möchte zu Ihrem
Posting noch etwas fragen:
1.) Sie schreiben etwas von einem "Objektorientierten Farbmanagement". Die
grundlegende Idee, das Prinzip davon, finde ich absolut richtig. Genau so
müsste Farbmanagement eigentlich funktionieren. Aber welche Programme,
welche Color-Engines beherrschen das denn? Gibt es bereits Normen dafür?
Ich befürchte, Nein.
2.) Ich habe gerade auf das Posting von Herrn Homann geantwortet und den
Vorschlag gemacht, CMYK-Farben zu vermeiden und möglichst nur noch
Schmuckfarben ins Layout zu bringen während die Bitmap-Daten im ECI-RGB
bleiben.
Für die Druckdatenerstellung bedeutet dies natürlich die Umwandlung aller
Schmuckfarben in Prozessfarben mittels des (hoffentlich) von der Druckerei
beigestellten Profils.
Nur bei Drucken, in denen noch eine oder mehrere Schmuckfarben zusätzlich zu
den Prozessfarben gedruckt werden sollen, müsste man im Layout selbst
transformieren und dann die geforderten Schmuckfarben von Hand neu anlegen.
Und soll die Farbe eines grafischen Elementes identisch sein mit einer
bestimmten Farbe, die in einem Bitmap liegt, dann kann ich die Farb-Füllung
des grafischen Elementes doch auch als Bitmap im ECI-RGB Farbraum anlegen,
wodurch dann die gleichen RIs Anwendung fänden und damit der Farbton gleich
bliebe.
Für die Präsentation im Web besteht ja eh das Problem, dass die in der
Werbung gedruckten Werbemittel oder CorporateDesign-Grafikelemente im Web
genau so aussehen sollten. Da müsste man von den nach CMYK gewandelten Daten
zurück nach sRGB transformieren, um einen ähnlichen Eindruck zu erzeugen,
denke ich.
Mich interessiert Ihre Meinung sehr. Wenn meine Idee funktioniert, wäre das
immerhin auch ECI-konform, oder?
Und das von mir ursprünglich angesprochene Problem mit dem von InDesign
geforderten CMYK-Arbeitsfarbraum hätte sich dann auch geklärt, oder?
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
----- Original Message -----
From: "Ulf Grossmann" <ulf.grossmann(a)bestcolor.com>
To: <eci(a)lists.transmedia.de>
Sent: Friday, June 14, 2002 4:44 PM
Subject: [Eci] RE: [Eci] ECI Workflow-Problem ( grundsätzliche
Designfehler )
Hallo Jan-Peter,
du sprichst bei PDF/X-3 nur von dem angehängten Profile, welches den
anzunehmenden Wiedergabefabraum beschreibt. Um jetzt aber die Objekte
des PDF richtig zu separieren brauche ich noch weit mehr. Es können in
diesem PDF ja RGB (ECI-RGB), CMYK (DVSPlus) oder auch Lab Daten
enthalten sein. Ich muß also ein Objektorientiertes Color Management
machen, welches als Zielfarbraum das " default Dokumenten Profile"
oder ein vom RIP bereitgestelltes Profile annimmt. Da ich an jedes
Objekt ein anderes Profile hängen kann, kann auch die Separation für
Vektor und Pixeldaten unterschiedlich sein. Jetzt zum Renderintent, in
jedem Profile steht ein default Renderintent (meistens perceptual)
welchen man benutzen kann. Wenn dieser Renderintent richtig gewählt
ist, funktioniert auch der ECI-Workflow wieder, da der Endanwender
sich nicht um den Renderintent kümmern muß, sondern der Profile
Ersteller Sorge dafür zu tragen hat, daß der richtige Renderintent
eingetragen ist. Eine feste Umsetzung durch das RIP (die CMM) ist
jedoch auch möglich, wenn von Aussen feste Intents übergeben werden.
Ich persönlich glaube aber, daß wir von diesem Workflow noch weit weg
sind und das Caos beim Proofen von solchen Dateien vorprogrammiert
ist. Ein wahrer Proof kann dann nur noch von 1-Bitdaten gemacht
werden, bei denen das Color Management (Separation) ja durch das
Belichter RIP gemacht wurde.
Beste Grüße
Ulf Grossmann
_______________________________________________
Eci mailing list
Eci(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci
-----Original Message-----
From: Jan-Peter Homann [mailto:homann@colormanagement.de]
Sent: Friday, June 14, 2002 3:40 PM
To: eci(a)lists.transmedia.de
Subject: [Eci] ECI Workflow-Problem ( grundsätzliche Designfehler )
Hallo Herr Hürten
Der gesmate ECI-RGB-Workflow funktioniert nur sehr
eingeschränkt, wenn sie
tatsächlich das gesamte Dokument medienneutral halten wollen.
Spätestens dann,
wann sie versuchen eine Schmuckfarbe medienneutral in einer
Vektorgrafik und
einem Bild anzulegen, bricht der ECI-Workflow zusammen. Sie
müßten dann Bilder
und Grafiken mit dem gleichen Rendering Intent umsetzen.
Je nach Kombination aus Motiv, Schmuckfarbe, Ausgabefarbraum und
Rendering-Intent kann das mal gut gehen, oder auch nicht.
Für welchen Intent Sie sich auch entscheiden, je nach
Ausgabefarbraum sind
jedesmal andere manuelle Korrekturen an den medienneutralen
Schmuckfarben-Definitionen und / oder den Bilddaten notwendig.
In diesem Fall sind sie allerdings gezwungen die manuell
korrigierten Daten zu
archivieren und der ECI-Workflow ist dann in der Praxis doch
erheblich
komplexer als im ECI-Whitepaper
Besonders heikel ist dabei, daß die ECI es ausdrücklich
empfiehlt das gesamte
medienneutrale Dokument als PDF/X-3 Datei mit angehängtem
Output-Intent für den
"blind exchange" medienneutraler Daten einzusetzen.
Aufgrund der oben beschreibenen Problematik kann es
passieren, daß die PDF-X-3
Datei auf dem idealisierten Proof zwar gut aussieht, aber bei
der Umsetzung auf
einen realen Ausgabefarbraum ohne manuelle Korrekturen
suboptimale bis nicht
akzeptable Ergebnisse heraus kommen.
Gerade im Bereich sehr hochqualitativer Arbeiten sollten
medienneutrale
Dokumente von einem erfahrenen Lithooperator in den
Zielfarbraum gewandelt
werden, geprooft, visuell begutachtet, wenn nötig manuell
korrigiert und als
CMYK-PDF/X-1a Datei mit eingebettetem Output-Intent
ausgeliefert werden.
Das gesamte ECI-Whitepaper beschreibt leider nur ideale
Abläufe und schummelt
sich um die nach wie vor notwendigen visuellen Kontrollen und
manuellen
Korrekturen herum.
In der Praxis sind daher medienneutrale Abläufe in der Regel
deutlich komplexer
als im ECI-Whitepaper beschrieben.
:-) Jan-Peter Homann
"Clemens M. Hürten" wrote:
...
des
Bei den ECI-RGB-Daten macht das Ganze ja nichts, weil die immer im
ECI-RGB-Farbraum bleiben und nur je nach Ausgabegerät mal mit dem
Proofer-Profil und mal mit dem Profil der Druckerei
transformiert werden.
> Bei den CMYK-Daten sagt aber InDesign ganz deutlich beim Wechsel Profils,
dass es die CMYK-Daten umrechnen wird. Damit aber
hätte ich keine
medienneutralen Daten mehr im Layout.
Unterliege ich hier einem Missverständnis? Wenn nein, wie
kann ich diesen
Konflikt im Sinne medienneutraler Datenhaltung
eines
kompletten Layout
lösen?--
---------------------------------
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
_______________________________________________
Eci mailing list
Eci(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci
8010
days inactive
8011
days old
1 comments
2 participants
participants (2)
-
Clemens M. Hürten -
Ulf Grossmann