Hallo Jan-Peter, Hallo Alle Zusammen,
an JP: Ich weiß Deinen Aktivismus zu schätzen, aber bitte eins nach dem
anderen. Wir bekommen sonst keine klare Linie in unsere Arbeit und
verzetteln uns. Um ein Verzetteln weitgehend einzugrenzen, sollen als
allgemein gültige Konstante sämtliche Lösungen und Vorschläge in Bezug
zu PDF/X gesetzt werden können.
--------------------------------------------------------
Ich würde gerne die Grundlage für unser erstes Kapitel weitgehend
fertigstellen, auch um dann zügig zu dem Rendering Intents-Thema zu
kommen. Das Einverständnis aller vorausgesetzt würden wir das dann den
anderen Sachen vorziehen.
Vielleicht noch als Anmerkung: Der Abschluss eines Kapitels bedeutet
natürlich keine Endgültigkeit. Aus gegebenen Gründen sind die gemachten
Aussagen immer in Bezug zu der jeweiligen Situation zu sehen, also
gemessen an dem zu diesem Zeitpunkt aktuellen Stand der Technik.
Solange es unseren AK geben wird, werden wir eine regelmäßige
Aktualisierung vornehmen.
Ich gehe zunächst davon aus, dass alle mit dem jetzigen Inhalt unserer
Dokumentation und dem ersten Themenkomplex einverstanden sind, da keine
explizite Ablehnung aufgekommen ist. :-)
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