WP Stand Dezember
by Andre Schützenhofer
Hallo zusammen,
anbei der aktuelle Stand unseres Papiers mit der Dokumentation der
ersten Ergebnisse. Es ist alles noch in Arbeit und nicht endgültig.
Gruß, Andre Schützenhofer
20 years, 3 months
- 7
- 12
Antwort: Re: [AK-Workflow] 1. b) Workflow Konzept - Konzentration auf PDF/X
by Markus_Mertmann＠arburg.com
Hallo Herr Schützenhofer,
als ich Ihre "Darstellung des Ideals" gelesen habe, dachte ich nur: Was, das
soll funktionieren ?!
Und da habe ich auch wirklich meine Zweifel ob sich so etwas umsetzen lässt.
Diese Zweifel sind übrigens keinesfalls technisch begründet. Dazu kenne ich die
Möglichkeiten oder Probleme zu wenig.
Aber: ein solcher Workflow wäre aus meiner Sicht absolut wünschenswert!
Vorgaben für die spätere Konvertierung sollten bei der Erstellung des Bildes
(Scanneroperator / Bildbearbeiter / Digitalfotograf) festgelegt werden. Hat der
Ersteller nicht das nötige Wissen sollten Default-Vorgaben für die Ausgabe im
Offsetdruck, Papierklasse 1 der Datei zugeordnet werden.
Die bei Dateierstellung gesetzen Vorgaben müssen jederzeit zu ändern sein. Z. B.
im Fall von späteren Veränderungen an der Datei selbst, welche andere Vorgaben
erfordern. Es ist sicher sinnvoll, früher eingestellte Vorgaben weiter in der
Datei zu dokumentieren. Erst wenn die Datei nicht mehr Medienneutral vorliegt
(ECI_RGB ist für mich noch Medieneneutral) sollten keine Änderungen an den
Vorgaben mehr möglich sein.
Für mich stellt sich immer die Frage nach den "Alt-Daten". Cmyk-Daten müssten
für den beschriebenen Workflow sicher auch mit den entsprechenden Vorgaben
gespeichert werden. Diese müssted dann wohl die Einstellungen beim
ursprünglichen Scan wiedergeben. Dieser kann ja schon Jahre zurückliegen. Da ist
dann wohl "schätzen" angesagt, oder?
Die Frage nach dem "zulässigen" Speicherdarf von Bildateien aufgrund von
getaggten Profilen hatten wir ja schon mal. Ich vermute mal das die diversen,
mit dem Bild gespeicherten Vorgaben den Speicherbedarf einer Bilddatei doch
deutlich vergrössern würden. Zumindest im Verhätniss gesehen, wenn es sich um
kleine Bilder handelt.
grüsse
Markus Mertmann
KINZIG WERBUNG GmbH
Arthur Hehl Straße
72290 Lossburg
Tel.: +49 (0) 7446 33 32 85
Fax.: +49 (0) 7446 33 31 69
mailto:markus_mertmann@arburg.com
http://www.arburg.com
Ich würde gerne trotzdem noch ein paar weitere Fragen klären. Dazu
nachfolgend eine kurze Darstellung des Ideals:
---------------------------------------
Retusche, Montage und Seitenaufbau, Grafik, Logos und Schrift komplett
in LAB (16bit), Sonderfarben durch Nummern mittels Bibliotheken
LAB-Werten zuordbar.
Speichern, Editieren, Verarbeiten: Editier- und Seitenlayoutprogramme
Übergabeformat: PDF/X-3 mit OutputIntent (LAB zu Output).
Transformation in den OutputIntent erfolgt dann während der Ausgabe als
letzter Schritt im Workflow.
---------------------------------------
(Weitgehend ist das natürlich noch absolute Zukunftsmusik.)
Stellen wir uns nun vor, wir wollen Farbtransformationen einer
beliebigen PDF/X-3 Datei von Farbraum X nach Farbraum Y durchführen.
Stellen wir uns weiterhin vor, dass nach Durchsicht der PDF/X-3 Datei
einige Motive sehr farbig, andere jedoch eher neutral gehalten sind,
fast grau. Übertragen wir das ganze weiterhin auf möglichst
medienneutrale Datenverarbeitung.
Um von hier aus eine Brücke zu den anderen Themen zu schlagen: Was für
Informationen müssten zusätzlich bestimmten Daten mit auf den Weg
gegeben werden, um eine korrekte und prozessstabile Weiterverabeitung
zu gewährleisten?
Beispiele (aus der Themensammlung):
- individuell kontrollierbarer Schwarzaufbau
- individuell kontrollierbares und/oder einheitliches Gamut Mapping
- Rendering Intent generell
- USM
- Trapping
- ...
Diese und andere Sachen sind in der Themensammlung aufgekommen. Im
Hinblick auch auf medienneutrales Datenhandling sowie
Prozesskonvertierungen und auch auf den Gesamtworkflow bezogen: Wo
genau darf und muss eine Entscheidung getroffen werden, welches Bild
mit welchem Schwarzaufbau und welchem Gamut Mapping mit welchem
Rendering Intent und eventuell noch anzuwendenem USM verarbeitet werden
soll?
Zunächst steht der Gedanke im Raum, solches über optionale (optional =
nur bei Vorhandensein erfolgt Aktion) Tags regeln zu können. Von der
Funktion her ähnlich wie das Zuweisen eines Rendering Intents könnten
"Black Generation Intents" und "USM Intents" einem Objekt oder auch
einer gesamten PDF zugewiesen werden, die dann von der CMM oder anderen
speziellen Modulen ausgelesen und exekutiert werden können, auch
mittels Zusatzfunktionen.
Vorstellbar wäre: Der Operator (Scanner-Operator oder Bildbearbeiter)
stellt fest, dass ein bestimmtes Motiv neutralton-lastig ist und
möchte, dass zukünftige Prozess-Konvertierungen mit anteilig viel
Schwarz erstellt werden sollen. Er weist dem (LAB / RGB) Bild den
"Black Generation Intent = max K GCR" zu. Ein anderes Bild ist sehr
bunt und ein zu starkes Ausgrauen durch zu hohes GCR ist nicht
erwünscht. Er weist diesem Bild den "Black Generation Intent = min K
UCR" zu.
(Die unterschiedlichen Schwarzaufbauten können "on-the-fly" generiert
werden wie auch zusätzlich als fester Bestandteil im Profil vorhanden
sein. Beispiel: Bei der Profilgeneration werden 3 (oder mehr)
unterschiedliche Separationparameter festgelegt, etwa wie max - medium
- min K und jede in einer seperaten LUT abgelegt. Durch das zuweisen
des "Black Generation Intents" weiß die CMM, welche der vorhandenen LUT
angewendet werden soll. Falls nur eine vorhanden ist, ist das das
default. Default wäre auch umgekehrt die "medium" Tabelle bei nicht
vorhandensein des Tags. Es geht hierbei auch nicht nur um
medienneutrale Daten, auch bei Prozesskonvertierungen wäre so eine oder
eine ähnliche Lösung vorstellbar.)
Um nun den Kreis zu schließen: Von der eigentlichen Funktionalität
abgesehen, ist eine solche oder ähnliche Vorgehensweise in absehbarer
Zukunft handhabbar?
Ist der Gedanke, schon bei der Bilddatenerstellung die Grundregeln für
die weitere Weiterverarbeitung möglichst weitgehend festzulegen, etwas
zu weit hergeholt und gar nicht zwingend relevant (80 bis 90 Prozent
der Bilddaten wären wahrscheinlich mit dem Default bestens bedient)?
Andererseits könnten einige der bestehenden Unwägsamkeiten bei vor
allem medienneutraler Datenverarbeitung beseitigt werden.
...?
Gruß, Andre Schützenhofer
Am Freitag, 12.12.03, um 16:16 Uhr (Europe/Berlin) schrieb Jan-Peter
Homann:
> Hallo Zusammen
>
> Im Vergleich zum Papier "Themensammlung" vermisse ich im aktuellen
> Stand des Whitepapers die Bereiche Rendering Intents und > Gamut-Mapping.
>
> Ich halte dies für einen absolut zentralen Punkt, der auf jeden Fall
> mit in das Whitepaper hinein gehört.
>
> Um das Thema hier etwas voran zu treiben, möchte ich folgende
> Worflow-Varianten und Rahmenbedingungen kurz skizzieren.
>
> Gamut-Mapping Methoden:
> ------------------------
> Standard Rendering-Intents
> - relativ farbmetrisch
> - absolut farbmetrisch
> - perceptual
> - Saturation (wird in der Praxis nicht genutzt)
>
> DeviceLink-Profile (bieten theoretisch die Möglichkeit ein optimiertes
> Gamut-Mapping von Quelle zu Ziel zu berechnen)
>
> Aktuell verfügbare Ergänzungen einzelner Produkte:
> - Blackpoint Compensation
> - Schwarz erhalten
>
>
> Aufbau und Gamut von Quell-Dokumenten
> --------------------------------
> 1) Durchgängiger Aufbau in einem CMYK Druckstandard wie ISOcoated oder
> PSR
> 2) Durchgängiger Aufbau in einem virtuellen CMYK Druckstandard, der
> Offset, Tiefdruck und High-Gamut Printing umschließt.
> 3) Durchgängiger Aufbau in einem RGB-Farbraum, der im Gamut am Druck
> orientiert ist
> 4) Durchgängiger Aufbau in einem High-Gamut Farbraum wie ECI-RGB
> 5) Einzelne Bilder und Objekte können in beliebigen Farbräumen
> vorliegen, solange sie über ein eingebettes ICC-Profil verfügen.
>
>
> Steuerung des Gamut Mapping von der Quelle zum Ziel
> ---------------------------------------------------
> Bei der Steuerung des Gamut-Mappings muß zwischen verschiedenen
> Varianten unterschieden werden. Entweder werden Pixelbilder und und
> Vektorgrafiken grundsätzlich mit der gleichen Methode umgesetzt, was
> die Integrität der Farben zueinander sicher stellt, oder es sind
> verschiedene Methoden erlaubt, was bei Pixelbildern und Vektorgrafiken
> und Standard Rendering Intents in einigen Fällen bessere Ergebnisse
> bringt.
> Weiterhin kann die Methode des Gamut-Mapping fest in der Quell-Datei
> verankert sein, wie es in PDF/X-3 festlegt ist, oder je nach
> Zielfarbraum können unterschiedliche Methoden angewendet werden, wie
> es mit ColorServern möglich ist.
>
> Je ähnlicher sich die Gamuts von Quelle und Ziel sind, desto
> vorhersagbarer ist das Ergebnis meistens, was gerade bei
> automatisierten Abläufen wichtig ist.
>
> Standard ICC-Profile verfügen über ein festgelegtes Gamut-Mapping,
> während DeviceLink-Profile in der Theorie die Möglichkeit bieten ein
> optimiertes Gamut-Mapping von Quelle zu Ziel zu berechnen.
>
>
> Wie hängen Gamut des Quell-Dokuments und Gamutmapping Steuerung
> zusammen ?
> -----------------------------------------------------------------------
> Baut man Master-Dokumente für ColorServer in einem Gamut auf, der in
> der Form einem Druckfarbraum (Version 1-3) entspricht, so wird man mit
> Standard-ICC-Profilen im allgemeinen mit relativ farbmetrisch (evt.
> mit Blackpoint Compensation) ein sehr gutes Ergebnis bekommen, wenn
> der Zielfarbraum im Gamut ungefähr der Quelle entspricht. Fotos und
> Grafiken werden mit der gleichen Methode gematcht, was die
> Farbintegrität des Dokumentes sichert.
> Mit dem Einsatz von DeviceLink-Profilen ist theoretisch eine noch
> bessere Optimierung und Automatisierung möglich.
>
> Liegen Fotos und Grafiken in einem High-Gamut Farbraum wie ECI-RGB
> vor, so ist es vom Motiv und Zielgamut abhängig welche Gamut-Mapping
> Methode (perceptual oder relativ farbmetrisch) das bessere Ergebnis
> bringt.
> Für einige Standard-Aufgabenstellung bringt die Variante Fotos mit
> perceptual und Grafiken relativ farbmetrisch zu matchen gute
> Ergebnisse.
> Bei kleinen Zielfarbräumen wie z.B. Zeitungsdruck kann ein relativ
> farbmetrischer Match für Grafiken allerdings ungeeignete Resultate
> bringen.
> Weiterhin gibt es Dokumente, bei denen die Farbintegrität zwischen
> Bildern und Grafiken unbedingt gewahrt werden muß.
>
> Aus diesen Gründen ist es manchmal notwendig mit unterschiedlichen
> Gamut-Mapping Methoden zu arbeiten. Dies läßt aber es nicht sinnvoll
> erscheinen das Gamut-Mapping in der PDF/X-3 Datei fest zu schreiben.
>
>
> Eine Optimierung des Workflows in Richtung höchstmögliche
> Automatisierung ist für solche Dokumente daher schwieriger als für
> Dokumente die in einem Druckgamut (Version 1-3) vorliegen).
>
> Da in diesem Fall der tatsächliche Gamut einzelner Objekte
> motivabhängig ist, sind auch die Voraussetzungen für die Berechnung
> optimierter DeviceLink-Profile weniger gut.
>
> Noch schwieriger wird der Fall, wenn in einem Dokument Objekte in
> beliebigen Farbräumen vorliegen dürfen (Version 5), wie es in PDF/X-3
> durchaus möglich ist. Dies ist in meinen Augen Gift für die
> Optimierung des Gamutmappings in ColorServern.
>
>
> Qualitätssicherung und ColorServer
> ----------------------------------
> Hat man das Ziel ColorServer möglichst automatisiert zu betreiben, so
> kommen wir aus meiner Sicht um Testdateien, Testprozeduren und
> Freigabekriterien für das Gamut-Mapping nicht drum herum.
> Beschränkt man sich auf Quell-Dokumente die in einem Druck-Gamut
> vorliegen mit der Vorgabe eines einheitlichen Gamut-Mappings für Fotos
> und Grafiken, so ist der Aufbau von Testdateien, Testprozeduren und
> Freigabekriterien wesentlich einfacher als bei Dokumenten der
> Versionen 4-5) und der Notwendigkeit je nach Bild, Grafik und
> Zielfarbraum mal diesen oder jenen Rendering Intent zu wählen.
>
>
> Fazit
> -----
> Ich selber konzentriere mich in meiner Arbeit mit
> Colorserver-Workflows, auf Quelldokumente die in einem Druck-Gamut
> vorliegen und die mit einem einheitlichen Gamutmapping für Fotos und
> Bilder zum Zielfarbraum umgesetzt werden.
> Erst wenn unter diesen Rahmenbedingungen Testbilder, Testprozeduren
> und Freigabekriterien erabeitet wurden, entscheide ich mich, ob es
> sinnvoll ist, sich auch ander Optimierung von komplexeren
> Rahmenbedingungen zu versuchen, oder ob es sinnvoller ist auf Basis
> der gesammelten Erfahrungen den ersteren Ansatz weiter zu optimieren.
>
> Für die Erarbeitung von Testbildern, Testprozeduren und
> Freigabekriterien und der anschließenden Workflow-Optimierung für die
> Zielfarbräume PSR LWC/SC, ISO-Profile und QUIZ rechne ich mit einem
> Zeitraum von ca. 2 Jahren
> Erst dann rechne ich mit einer Automatisierung, die auch bei
> schwierigen Motiven keine manuellen Eingriffe mehr benötigt.
>
> :-) Jan-Peter Homann
>
>
>
>
>
>
>
> Andre Schützenhofer schrieb:
>> Hallo zusammen,
>> anbei der aktuelle Stand unseres Papiers mit der Dokumentation der
>> ersten Ergebnisse. Es ist alles noch in Arbeit und nicht endgültig.
>> Gruß, Andre Schützenhofer
>
>
> --
> -------------------------------------------------------
> - Neue Adresse -
> -------------------------------------------------------
>
> colormanagement.de ---------- fon/fax +49 30 611 075 18
> Jan-Peter Homann ------------- mobile +49 171 54 70 358
> Kastanienallee 71 ------- http://www.colormanagement.de
> 10435 Berlin --------- mailto:homann@colormanagement.de
>
> _______________________________________________
> AK-Workflow mailing list
> AK-Workflow(a)lists.transmedia.de
> http://lists.transmedia.de/mailman/listinfo/ak-workflow
>
>
PRO·CON·CEPT GmbH - production and consulting by concept
???????????????????????????????????????????????????????????????????????
Standort Köln: Ehrenstraße 88 · 50672 Köln
phone|fax: +49 (0) 221 - 255 254 | cell +49 (0) 172 - 21 28 104
j.erpenbach(a)pro-con-cept.com
???????????????????????????????????????????????????????????????????????
Standort Langenfeld: Kronprinzstraße 54 · 40764 Langenfeld
tele +49 (0) 2173-3993 phone +363 fax +308 | cell +49 (0) 172-208 32 73
a.schuetzenhofer(a)pro-con-cept.com
???????????????????????????????????????????????????????????????????????
http://www.pro-con-cept.com · info(a)pro-con-cept.com
20 years, 4 months
- 3
- 3
Antwort: Re: Antwort: Re: [AK-Workflow] 1. b) Workflow Konzept - Konzentration auf PDF/X
by Markus_Mertmann＠arburg.com
Hallo Herr Faber,
>>>>>Was ist mit vom Kunden gelieferten Daten? Wie gehen wir in unserem
perfekten Workflow damit um?
Oder noch gemeiner ist die Kombination aus Inhouse Daten
(medienneutral) und Kundendaten (????neutral oder auch nicht)
Ein Thema welches sich bisher nur händisch lösen lässt - meine ich.<<<<<<
Da haben Sie recht. Das ist der selbe Punkt wie mit den Cmyk-Altbeständen.
Sobald in diesen Workflow Daten übernommen werden die keine Vorgaben enthalten
(Vorgaben wie sie der Herr Schützenhofer bereits skizziert hat), müssen diese
Vorgaben der jeweiligen Datei hinzugefügt werden. Und zwar von jemandem der sich
damit auskennt.
"Früher" hat die Lithoanstalt das Dia des Fotografen gescannt und durch den Scan
die Separationsparameter für die geplante Ausgabe festgelegt. Jetzt muss jemand
mit diesem Wissen eben die Vorgaben für eine bestimmte Datei festlegen. Im
Prinzip egal ob es sich um eine neue oder eine vorhandene, nicht definierte
Datei handelt.
Wer diesen Schritt nicht von der / dem entsprechenden Fachfrau / mann ausführren
lassen will, muss einen Default definieren und mit der evtl. schlechteren
Qualität in Endergebniss leben.
Einverstanden?
Grüsse
Markus Mertmann
KINZIG WERBUNG GmbH
Arthur Hehl Straße
72290 Lossburg
Tel.: +49 (0) 7446 33 32 85
Fax.: +49 (0) 7446 33 31 69
mailto:markus_mertmann@arburg.com
http://www.arburg.com
Hallo Herr Mertmann,
Ich bin ebenfalls Ihrer Meinung, so könnte der perfekte Workflow
aussehen.
Aber ...
Am Dienstag, 16.12.03, um 11:35 Uhr (Europe/Berlin) schrieb
Markus_Mertmann(a)arburg.com:
>
>
>
>
> Hallo Herr Schützenhofer,
>
> als ich Ihre "Darstellung des Ideals" gelesen habe, dachte ich nur:
> Was, das
> soll funktionieren ?!
> Und da habe ich auch wirklich meine Zweifel ob sich so etwas umsetzen
> lässt.
> Diese Zweifel sind übrigens keinesfalls technisch begründet. Dazu
> kenne ich die
> Möglichkeiten oder Probleme zu wenig.
>
> Aber: ein solcher Workflow wäre aus meiner Sicht absolut wünschenswert!
>
> Vorgaben für die spätere Konvertierung sollten bei der Erstellung des
> Bildes
> (Scanneroperator / Bildbearbeiter / Digitalfotograf) festgelegt
> werden. Hat der
> Ersteller nicht das nötige Wissen sollten Default-Vorgaben für die
> Ausgabe im
> Offsetdruck, Papierklasse 1 der Datei zugeordnet werden.
>
> Die bei Dateierstellung gesetzen Vorgaben müssen jederzeit zu ändern
> sein. Z. B.
> im Fall von späteren Veränderungen an der Datei selbst, welche andere
> Vorgaben
> erfordern. Es ist sicher sinnvoll, früher eingestellte Vorgaben weiter
> in der
> Datei zu dokumentieren. Erst wenn die Datei nicht mehr Medienneutral
> vorliegt
> (ECI_RGB ist für mich noch Medieneneutral) sollten keine Änderungen an
> den
> Vorgaben mehr möglich sein.
>
> Für mich stellt sich immer die Frage nach den "Alt-Daten". Cmyk-Daten
> müssten
> für den beschriebenen Workflow sicher auch mit den entsprechenden
> Vorgaben
> gespeichert werden. Diese müssted dann wohl die Einstellungen beim
> ursprünglichen Scan wiedergeben. Dieser kann ja schon Jahre
> zurückliegen. Da ist
> dann wohl "schätzen" angesagt, oder?
Was ist mit vom Kunden gelieferten Daten? Wie gehen wir in unserem
perfekten Workflow damit um?
Oder noch gemeiner ist die Kombination aus Inhouse Daten
(medienneutral) und Kundendaten (????neutral oder auch nicht)
Ein Thema welches sich bisher nur händisch lösen lässt - meine ich.
>
> Die Frage nach dem "zulässigen" Speicherdarf von Bildateien aufgrund
> von
> getaggten Profilen hatten wir ja schon mal. Ich vermute mal das die
> diversen,
> mit dem Bild gespeicherten Vorgaben den Speicherbedarf einer Bilddatei
> doch
> deutlich vergrössern würden. Zumindest im Verhätniss gesehen, wenn es
> sich um
> kleine Bilder handelt.
>
>
>
> grüsse
>
>
>
>
>
> Markus Mertmann
>
>
>
>
> KINZIG WERBUNG GmbH
> Arthur Hehl Straße
> 72290 Lossburg
> Tel.: +49 (0) 7446 33 32 85
> Fax.: +49 (0) 7446 33 31 69
> mailto:markus_mertmann@arburg.com
> http://www.arburg.com
Mit freundlichen Grüßen,
Axel Faber, Geschäftsführer
FaberPublish GmbH
Cross Media Publishing
Friedensallee 120
22763 Hamburg
Tel: 040/88 91 91 30
Fax: 040/88 91 91 40
Mobil: 0172/404 9000
e-mail: a.faber(a)faberpublish.de
>
>
>
>
>
>
> Ich würde gerne trotzdem noch ein paar weitere Fragen klären. Dazu
> nachfolgend eine kurze Darstellung des Ideals:
>
> ---------------------------------------
> Retusche, Montage und Seitenaufbau, Grafik, Logos und Schrift komplett
> in LAB (16bit), Sonderfarben durch Nummern mittels Bibliotheken
> LAB-Werten zuordbar.
>
> Speichern, Editieren, Verarbeiten: Editier- und Seitenlayoutprogramme
> Übergabeformat: PDF/X-3 mit OutputIntent (LAB zu Output).
>
> Transformation in den OutputIntent erfolgt dann während der Ausgabe als
> letzter Schritt im Workflow.
> ---------------------------------------
>
> (Weitgehend ist das natürlich noch absolute Zukunftsmusik.)
>
> Stellen wir uns nun vor, wir wollen Farbtransformationen einer
> beliebigen PDF/X-3 Datei von Farbraum X nach Farbraum Y durchführen.
> Stellen wir uns weiterhin vor, dass nach Durchsicht der PDF/X-3 Datei
> einige Motive sehr farbig, andere jedoch eher neutral gehalten sind,
> fast grau. Übertragen wir das ganze weiterhin auf möglichst
> medienneutrale Datenverarbeitung.
>
> Um von hier aus eine Brücke zu den anderen Themen zu schlagen: Was für
> Informationen müssten zusätzlich bestimmten Daten mit auf den Weg
> gegeben werden, um eine korrekte und prozessstabile Weiterverabeitung
> zu gewährleisten?
>
> Beispiele (aus der Themensammlung):
> - individuell kontrollierbarer Schwarzaufbau
> - individuell kontrollierbares und/oder einheitliches Gamut Mapping
> - Rendering Intent generell
> - USM
> - Trapping
> - ...
>
> Diese und andere Sachen sind in der Themensammlung aufgekommen. Im
> Hinblick auch auf medienneutrales Datenhandling sowie
> Prozesskonvertierungen und auch auf den Gesamtworkflow bezogen: Wo
> genau darf und muss eine Entscheidung getroffen werden, welches Bild
> mit welchem Schwarzaufbau und welchem Gamut Mapping mit welchem
> Rendering Intent und eventuell noch anzuwendenem USM verarbeitet werden
> soll?
>
> Zunächst steht der Gedanke im Raum, solches über optionale (optional =
> nur bei Vorhandensein erfolgt Aktion) Tags regeln zu können. Von der
> Funktion her ähnlich wie das Zuweisen eines Rendering Intents könnten
> "Black Generation Intents" und "USM Intents" einem Objekt oder auch
> einer gesamten PDF zugewiesen werden, die dann von der CMM oder anderen
> speziellen Modulen ausgelesen und exekutiert werden können, auch
> mittels Zusatzfunktionen.
>
> Vorstellbar wäre: Der Operator (Scanner-Operator oder Bildbearbeiter)
> stellt fest, dass ein bestimmtes Motiv neutralton-lastig ist und
> möchte, dass zukünftige Prozess-Konvertierungen mit anteilig viel
> Schwarz erstellt werden sollen. Er weist dem (LAB / RGB) Bild den
> "Black Generation Intent = max K GCR" zu. Ein anderes Bild ist sehr
> bunt und ein zu starkes Ausgrauen durch zu hohes GCR ist nicht
> erwünscht. Er weist diesem Bild den "Black Generation Intent = min K
> UCR" zu.
>
> (Die unterschiedlichen Schwarzaufbauten können "on-the-fly" generiert
> werden wie auch zusätzlich als fester Bestandteil im Profil vorhanden
> sein. Beispiel: Bei der Profilgeneration werden 3 (oder mehr)
> unterschiedliche Separationparameter festgelegt, etwa wie max - medium
> - min K und jede in einer seperaten LUT abgelegt. Durch das zuweisen
> des "Black Generation Intents" weiß die CMM, welche der vorhandenen LUT
> angewendet werden soll. Falls nur eine vorhanden ist, ist das das
> default. Default wäre auch umgekehrt die "medium" Tabelle bei nicht
> vorhandensein des Tags. Es geht hierbei auch nicht nur um
> medienneutrale Daten, auch bei Prozesskonvertierungen wäre so eine oder
> eine ähnliche Lösung vorstellbar.)
>
> Um nun den Kreis zu schließen: Von der eigentlichen Funktionalität
> abgesehen, ist eine solche oder ähnliche Vorgehensweise in absehbarer
> Zukunft handhabbar?
>
> Ist der Gedanke, schon bei der Bilddatenerstellung die Grundregeln für
> die weitere Weiterverarbeitung möglichst weitgehend festzulegen, etwas
> zu weit hergeholt und gar nicht zwingend relevant (80 bis 90 Prozent
> der Bilddaten wären wahrscheinlich mit dem Default bestens bedient)?
>
> Andererseits könnten einige der bestehenden Unwägsamkeiten bei vor
> allem medienneutraler Datenverarbeitung beseitigt werden.
>
> ...?
>
> Gruß, Andre Schützenhofer
>
>
>
>
>
>
> Am Freitag, 12.12.03, um 16:16 Uhr (Europe/Berlin) schrieb Jan-Peter
> Homann:
>
>> Hallo Zusammen
>>
>> Im Vergleich zum Papier "Themensammlung" vermisse ich im aktuellen
>> Stand des Whitepapers die Bereiche Rendering Intents und >
>> Gamut-Mapping.
>>
>> Ich halte dies für einen absolut zentralen Punkt, der auf jeden Fall
>> mit in das Whitepaper hinein gehört.
>>
>> Um das Thema hier etwas voran zu treiben, möchte ich folgende
>> Worflow-Varianten und Rahmenbedingungen kurz skizzieren.
>>
>> Gamut-Mapping Methoden:
>> ------------------------
>> Standard Rendering-Intents
>> - relativ farbmetrisch
>> - absolut farbmetrisch
>> - perceptual
>> - Saturation (wird in der Praxis nicht genutzt)
>>
>> DeviceLink-Profile (bieten theoretisch die Möglichkeit ein optimiertes
>> Gamut-Mapping von Quelle zu Ziel zu berechnen)
>>
>> Aktuell verfügbare Ergänzungen einzelner Produkte:
>> - Blackpoint Compensation
>> - Schwarz erhalten
>>
>>
>> Aufbau und Gamut von Quell-Dokumenten
>> --------------------------------
>> 1) Durchgängiger Aufbau in einem CMYK Druckstandard wie ISOcoated oder
>> PSR
>> 2) Durchgängiger Aufbau in einem virtuellen CMYK Druckstandard, der
>> Offset, Tiefdruck und High-Gamut Printing umschließt.
>> 3) Durchgängiger Aufbau in einem RGB-Farbraum, der im Gamut am Druck
>> orientiert ist
>> 4) Durchgängiger Aufbau in einem High-Gamut Farbraum wie ECI-RGB
>> 5) Einzelne Bilder und Objekte können in beliebigen Farbräumen
>> vorliegen, solange sie über ein eingebettes ICC-Profil verfügen.
>>
>>
>> Steuerung des Gamut Mapping von der Quelle zum Ziel
>> ---------------------------------------------------
>> Bei der Steuerung des Gamut-Mappings muß zwischen verschiedenen
>> Varianten unterschieden werden. Entweder werden Pixelbilder und und
>> Vektorgrafiken grundsätzlich mit der gleichen Methode umgesetzt, was
>> die Integrität der Farben zueinander sicher stellt, oder es sind
>> verschiedene Methoden erlaubt, was bei Pixelbildern und Vektorgrafiken
>> und Standard Rendering Intents in einigen Fällen bessere Ergebnisse
>> bringt.
>> Weiterhin kann die Methode des Gamut-Mapping fest in der Quell-Datei
>> verankert sein, wie es in PDF/X-3 festlegt ist, oder je nach
>> Zielfarbraum können unterschiedliche Methoden angewendet werden, wie
>> es mit ColorServern möglich ist.
>>
>> Je ähnlicher sich die Gamuts von Quelle und Ziel sind, desto
>> vorhersagbarer ist das Ergebnis meistens, was gerade bei
>> automatisierten Abläufen wichtig ist.
>>
>> Standard ICC-Profile verfügen über ein festgelegtes Gamut-Mapping,
>> während DeviceLink-Profile in der Theorie die Möglichkeit bieten ein
>> optimiertes Gamut-Mapping von Quelle zu Ziel zu berechnen.
>>
>>
>> Wie hängen Gamut des Quell-Dokuments und Gamutmapping Steuerung
>> zusammen ?
>> ----------------------------------------------------------------------
>> -
>> Baut man Master-Dokumente für ColorServer in einem Gamut auf, der in
>> der Form einem Druckfarbraum (Version 1-3) entspricht, so wird man mit
>> Standard-ICC-Profilen im allgemeinen mit relativ farbmetrisch (evt.
>> mit Blackpoint Compensation) ein sehr gutes Ergebnis bekommen, wenn
>> der Zielfarbraum im Gamut ungefähr der Quelle entspricht. Fotos und
>> Grafiken werden mit der gleichen Methode gematcht, was die
>> Farbintegrität des Dokumentes sichert.
>> Mit dem Einsatz von DeviceLink-Profilen ist theoretisch eine noch
>> bessere Optimierung und Automatisierung möglich.
>>
>> Liegen Fotos und Grafiken in einem High-Gamut Farbraum wie ECI-RGB
>> vor, so ist es vom Motiv und Zielgamut abhängig welche Gamut-Mapping
>> Methode (perceptual oder relativ farbmetrisch) das bessere Ergebnis
>> bringt.
>> Für einige Standard-Aufgabenstellung bringt die Variante Fotos mit
>> perceptual und Grafiken relativ farbmetrisch zu matchen gute
>> Ergebnisse.
>> Bei kleinen Zielfarbräumen wie z.B. Zeitungsdruck kann ein relativ
>> farbmetrischer Match für Grafiken allerdings ungeeignete Resultate
>> bringen.
>> Weiterhin gibt es Dokumente, bei denen die Farbintegrität zwischen
>> Bildern und Grafiken unbedingt gewahrt werden muß.
>>
>> Aus diesen Gründen ist es manchmal notwendig mit unterschiedlichen
>> Gamut-Mapping Methoden zu arbeiten. Dies läßt aber es nicht sinnvoll
>> erscheinen das Gamut-Mapping in der PDF/X-3 Datei fest zu schreiben.
>>
>>
>> Eine Optimierung des Workflows in Richtung höchstmögliche
>> Automatisierung ist für solche Dokumente daher schwieriger als für
>> Dokumente die in einem Druckgamut (Version 1-3) vorliegen).
>>
>> Da in diesem Fall der tatsächliche Gamut einzelner Objekte
>> motivabhängig ist, sind auch die Voraussetzungen für die Berechnung
>> optimierter DeviceLink-Profile weniger gut.
>>
>> Noch schwieriger wird der Fall, wenn in einem Dokument Objekte in
>> beliebigen Farbräumen vorliegen dürfen (Version 5), wie es in PDF/X-3
>> durchaus möglich ist. Dies ist in meinen Augen Gift für die
>> Optimierung des Gamutmappings in ColorServern.
>>
>>
>> Qualitätssicherung und ColorServer
>> ----------------------------------
>> Hat man das Ziel ColorServer möglichst automatisiert zu betreiben, so
>> kommen wir aus meiner Sicht um Testdateien, Testprozeduren und
>> Freigabekriterien für das Gamut-Mapping nicht drum herum.
>> Beschränkt man sich auf Quell-Dokumente die in einem Druck-Gamut
>> vorliegen mit der Vorgabe eines einheitlichen Gamut-Mappings für Fotos
>> und Grafiken, so ist der Aufbau von Testdateien, Testprozeduren und
>> Freigabekriterien wesentlich einfacher als bei Dokumenten der
>> Versionen 4-5) und der Notwendigkeit je nach Bild, Grafik und
>> Zielfarbraum mal diesen oder jenen Rendering Intent zu wählen.
>>
>>
>> Fazit
>> -----
>> Ich selber konzentriere mich in meiner Arbeit mit
>> Colorserver-Workflows, auf Quelldokumente die in einem Druck-Gamut
>> vorliegen und die mit einem einheitlichen Gamutmapping für Fotos und
>> Bilder zum Zielfarbraum umgesetzt werden.
>> Erst wenn unter diesen Rahmenbedingungen Testbilder, Testprozeduren
>> und Freigabekriterien erabeitet wurden, entscheide ich mich, ob es
>> sinnvoll ist, sich auch ander Optimierung von komplexeren
>> Rahmenbedingungen zu versuchen, oder ob es sinnvoller ist auf Basis
>> der gesammelten Erfahrungen den ersteren Ansatz weiter zu optimieren.
>>
>> Für die Erarbeitung von Testbildern, Testprozeduren und
>> Freigabekriterien und der anschließenden Workflow-Optimierung für die
>> Zielfarbräume PSR LWC/SC, ISO-Profile und QUIZ rechne ich mit einem
>> Zeitraum von ca. 2 Jahren
>> Erst dann rechne ich mit einer Automatisierung, die auch bei
>> schwierigen Motiven keine manuellen Eingriffe mehr benötigt.
>>
>> :-) Jan-Peter Homann
>>
>>
>>
>>
>>
>>
>>
>> Andre Schützenhofer schrieb:
>>> Hallo zusammen,
>>> anbei der aktuelle Stand unseres Papiers mit der Dokumentation der
>>> ersten Ergebnisse. Es ist alles noch in Arbeit und nicht endgültig.
>>> Gruß, Andre Schützenhofer
>>
>>
>> --
>> -------------------------------------------------------
>> - Neue Adresse -
>> -------------------------------------------------------
>>
>> colormanagement.de ---------- fon/fax +49 30 611 075 18
>> Jan-Peter Homann ------------- mobile +49 171 54 70 358
>> Kastanienallee 71 ------- http://www.colormanagement.de
>> 10435 Berlin --------- mailto:homann@colormanagement.de
>>
>> _______________________________________________
>> AK-Workflow mailing list
>> AK-Workflow(a)lists.transmedia.de
>> http://lists.transmedia.de/mailman/listinfo/ak-workflow
>>
>>
>
>
>
> PRO·CON·CEPT GmbH - production and consulting by concept
> ???????????????????????????????????????????????????????????????????????
> Standort Köln: Ehrenstraße 88 · 50672 Köln
> phone|fax: +49 (0) 221 - 255 254 | cell +49 (0) 172 - 21 28 104
> j.erpenbach(a)pro-con-cept.com
> ???????????????????????????????????????????????????????????????????????
> Standort Langenfeld: Kronprinzstraße 54 · 40764 Langenfeld
> tele +49 (0) 2173-3993 phone +363 fax +308 | cell +49 (0) 172-208 32 73
> a.schuetzenhofer(a)pro-con-cept.com
> ???????????????????????????????????????????????????????????????????????
> http://www.pro-con-cept.com · info(a)pro-con-cept.com
>
>
>
>
>
>
> _______________________________________________
> AK-Workflow mailing list
> AK-Workflow(a)lists.transmedia.de
> http://lists.transmedia.de/mailman/listinfo/ak-workflow
>
>
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow
20 years, 4 months
- 2
- 1
WP 13-12-2003
by Andre Schützenhofer
Anbei eine aktualisierte Version mit vollständigem Inhaltsverzeichnis.
Gruß, Andre Schützenhofer
20 years, 4 months
- 1
- 0
Re: Re(2): [AK-Workflow] Einbettung oder Tagging von Profilen
by Andre Schützenhofer
Am Donnerstag, 27.11.03, um 22:27 Uhr (Europe/Berlin) schrieb Olaf
Drümmer:
> Einige Anmerkung zum Einbetten von ICC-Profile in PDF:
>
> - ECI-RGB (gilt auch fuer andere Arbeitsraumprofile) ist ca. 500 Byte
> gross
> - die meisten PDF-Erzeugungsapplikationen betten dasselbe ICC-Profil
> selten mehr als einmal ein
Das bedeutet also, dass eine Art "Referenzierung" schon stattfindet. Da
beim Weg über PostScript bekannterweise keine ICC-Profile unterstützt
werden, ist das Einbetten von verschiedenen Profilen zur Zeit nicht
wirklich relevant, da es verfahrensbedingt unmöglich bzw. nur über
eigentlich nicht praktikable Umwege (EPS mit PostScript-CM und Profil
auf dem Distiller-Rechner) zu erreichen ist.
Das Problem des expliziten Zuweisens von verschiedenen Ausgabeprofilen
besteht vor allem dann, wenn mindestens zwei absichtlich
unterschiedliche Profile der selben Klasse (CMYK-CMYK) in einer
PDF-Datei enthalten sein sollen. Es gäbe dann immer einen (Klassen-)
Zustand mehr als unterschiedliche Profile vorhanden sind:
Beispielsweise = 1. Objekte zugewiesen mit Profil A, 2. Objekte
zugewiesen mit Profil B, 3. Objekte ohne Zuweisung beschrieben durch
den Output Intent. Um nun nicht jede Datei (und Objekt) explizit mit
einem Profil versehen zu müssen, macht eine Referenzierung m.E. Sinn.
(Auf den direkten Export einer PDF aus InDesign CS bin ich ziemlich
gespannt. )
> - ein CMYK-Printer-Profil neigt dazu sehr gross zu sein (bis zu 1.5
> MB);
> da es im PDF nur als Quellprofil verwendet wird, koennte man es zu
> einem
> Scanner-Profil umkodieren, so dass nur das je nach rendering intent
> benoetigte Device-to-PCS tag enthalten ist, damit duerfte der
> Platzbedarf
> auf wenige hundert KB schrumpfen.
Finde ich grundsätzlich OK. Der WPTag müsste ebenfalls enthalten sein,
um einen absolut farbmetrischen Proof erstellen zu können. Also kann es
sich hier nur um eine farbmetrische Tabelle handeln, was dann jedoch
proprietäre Routienen wie inversGM verhindert.
InversGM: Ungeachtet von Sinn und Nutzen des Inversen Gamut Mapping
bleibt zunächst die Tatsache, dass es 1. in der grundsätzlichen
Implementierung und 2. durch das zusätzlich herstellerspezifische Gamut
Mapping eine höchst proprietäre Routine ist.
Mit "Einverständnis" und Unterstützung von Herrn Bestmann halte ich ein
näheres Betrachten dieser Thematik für sinnvoll, wie auch schon in
unserer Sammlung angedeutet.
> - in Grafikdateien, die Schriften benoetigen, ist ungetruebtes
> Produktionsgeschehen nur sichergetsellt, wenn die Schriften eingebettet
> sind (je Schrift einige zig KB, bei mehreren Schriften ist man da auch
> schnell bei 100 oder 200 KB).
Yes.
> Das Referenzieren von externen Profilen sehe ich als problematisch an,
> vor allem wenn man bedenkt, dass die Daten evtl. viele Jahre lang
> 'halten' muessen. Nicht immer kann sichergestellt werden, dass Jahre
> spaeter die noetigen Profile noch im Zugriff sind. Und wenn man Daten
> mit
> anderen austauschen muss, muessen die Profile im Zweifelsfall eh'
> eingebettet sein.
Yes. Was uns dann die wahrscheinlich zu Recht befürchteten OPI bzw.
Schriften-Probleme bringen wird / kann.
> Als allgemeine Strategie scheint mir da am sinnvollsten zu sein,
> bevorzugt in einem Arbeitsfarbraum Daten vorzuhalten.
>
> Zu PDF/X:
> Hier muss ein ICC-Printer-Profil (eine als Scanner-Profil abgespeckte
> Variante wuerde hier nicht zulaessig sein) immer dann eingebettet sein,
> wenn das PDF/X-Dokument geraeteneutrale Daten enthaelt. Fuer den Fall,
> dass lediglich CMYK-Daten enthalten sind, kann man theoretisch auf das
> Einbetten verzichten und lediglich auf einen Eintrag in der ICC
> registry
> www.color.org verweisen. Bestimmte Automatismen (Proof- und
> Ausgabesystem, Color-Konverter wie SuperColor oder iQueue) laufen aber
> nur dann sicher, wenn das Profil enthalten ist.
>
> Olaf Druemmer
>
> PS: Zur Terminologie 'tagging vs. einbetten vs. ich weiss nicht was':
> genau genommen gibt es z.Z. in den ueblichen Dateiformaten (TIFF, JPEG,
> PDF) nur zwei Optionen
> - Rohdaten ohne farbmetrische Charakterisierung; welche
> Charakterisierung
> zutrifft, kann man sich 'merken', produktionssicher ist das allenfalls
> in
> geschlossenen Ablaeufen
> - das ICC-Profil ist eingebettet, die farbmetrische Charakterisierung
> ist
> eindeutig zugeordnet und erreichbar.
> Eine kleine Ausnahme: wie oben beschrieben, kann man in PDF/X
> CMYK-Daten
> (und theoretisch auch RGB-Drucker-Daten) mit einem Verweis auf die ICC-
> Registry charakterisieren.
An sich hat Herr Richard am Anfang recht treffend formuliert:
> Das würde uns auf lange Sicht ähnliche Probleme mit inkonsistenten
> Profilnamen/-Versionen bereiten, wie wir sie von den Schriften gewohnt
> sind, aber GB an redundanten Profildaten ersparen.
Also:
1.) Wir sehen die Probleme jetzt schon kommen
(Profilnamen/Versionen/Zeitfaktor/...)
2.) Florian Süßl ist meines Erachtens richtigerweise der Meinung, dass
Festplatten/Speicherplatz nicht wirklich das Problem sind
3.) Allgemein haben wir (siehe auch Olaf Drümmer bzw. s.o.) bestätigt,
dass allenfalls in in sich geschlossenen Systemen wie PDF/X eine
Referenzierung mit entsprechender Sicherheit möglich ist bzw. auch
schon gemacht wird.
4.) Weiterführende Lösungen wie Umkodierungen müssten auf
"Tauglichkeit" und Nutzen überprüft werden (allerdings stellt sich mir
persönlich und wahrscheinlich auch Olaf selbst die Frage nach 2.),
sowie auch "wenn schon nur maximal ein Profil von jeder Sorte dann
wenigstens ein vollständiges" :-)
OK?
Gruß Andre Schützenhofer
PRO·CON·CEPT GmbH - production and consulting by concept
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Standort Köln: Ehrenstraße 88 · 50672 Köln
phone|fax: +49 (0) 221 - 255 254 | cell +49 (0) 172 - 21 28 104
j.erpenbach(a)pro-con-cept.com
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Standort Langenfeld: Kronprinzstraße 54 · 40764 Langenfeld
tele +49 (0) 2173-3993 phone +363 fax +308 | cell +49 (0) 172-208 32 73
a.schuetzenhofer(a)pro-con-cept.com
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
http://www.pro-con-cept.com · info(a)pro-con-cept.com
20 years, 4 months
- 6
- 10