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