Hallo Herr Mertmann,
Ja das stimmt. Ich sehe es genauso wie Sie.
Gruss Axel Faber
Druck Am Dienstag, 16.12.03, um 13:10 Uhr (Europe/Berlin) schrieb
Markus_Mertmann(a)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
_______________________________________________
AK-Workflow mailing list
AK-Workflow(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/ak-workflow