Hallo Urs,

Antwort auf:

wo liegt der Vorteil eines verfahrensneutralen Workflows im Vergleich zum medienneutralen?

Vorweg: mir geht es nicht darum, für einen der beiden Workflows in den Glaubenskrieg zu ziehen. Sie haben beide ihre Daseinsberechtigung! Und man muss selbst entscheiden, mit welchem Werkzeug das beste Ergebnis für den Kunden erzeugt wird. Daher möchte Ich nur mal den medienneutralen Workflow grob skizzieren und die Stolperstellen aufzeigen die ich sehe. (Ausfühlicher gibts das in den bereits erwähnten White-Paper)

Agentur/Repro digitalisiert Daten und setzt diese in den Arbeitsfarbraum L*a*b* bzw. (LStar-)RGB-Arbeitsfarbraum um. Wer in solchen "großen" Farbräumen arbeitet handelt sich Quantisierungsfehler ein. Das lässt sich nur kompensieren, wenn man mit 16 oder 32 Bit arbeitet. Die erste hohe Anforderung: Es kann nur Software verwendet werden, welche diese Bittiefe verabeiten kann. Und dann eine Frage, die ich bisher nie beantworten konnte. Bei der Umsetzung 32bit-RGB-Bildes nach ISOcoated kommen 8bit-ICC-Profile zum Tragen. Das heißt ja, dass die Bittiefe des Bildes auf 8 Bit reduziert wird. Damit dürfte ja das Phänomen der Quantisierungsfehler wieder auftreten, oder nicht?

Die Agentur macht in diesem Farbraum die komplette Bildbearbeitung. Dabei weiß man aber nichts über das Ausgabesystem (Monitor, Offset, Flexo, Tiefdruck, ...). Die Farbinformationen bewegen sich also im gesamten Gamut des Arbeitsfarbraums. Diese Bilder werden nun im Dokument platziert und gegebenenfals getagged, so dass Profil und RI bekannt sind. Shwachstelle: das geschieht manuell. Man stelle sich den Aufwand beim Setzen des Dokuments vor. Und nun stelle man sich vor, dass man für ein Versandhaus ein Katalog zu setzen hat. Eine Automatisierung ist nur dann möglich, wenn man alle Bilddaten über einen Kamm schert. Das natürlich zu Qualitätsverlust führt. Das nächste Problem, dass ich sehe: Es wird eine medienneutrale PDF- oder PostScript-Datei erstellt (wir sind ja noch nicht am Ende der Kette). Kann das im Vorfeld gesetzte Tagging in die PDF überführt werden, und wird das dann wiederum bei der Separation herangezogen? IMO ist die gegenwärtige Technik nicht dazu in der Lage.

Dann erfolgt der Proof - im schlechtesten Fall mit einem "idealisierten Proof", der im Gamut des Proofers vorliegt. Besser natürlich man macht ein "generischen Poof", wo das Simulationsprofil ein "Standard-CMYK" ist. Problem, die Separation auf dem Proofer und in der DFH müssen nicht identisch sein.

Und nun wo der Proof vorliegt, stellen wir fest, dass Bild 5 auf Seite 345 doch mit einem falschen RI umgesetzt wurde. Oder schlimmer, einer selektiven Farbkorrekur unterzogen werden müsste.

Würde die Repro, nach der medienneutralen Bildbearbeitung ein verfahrensneutrales CMYK-Bild erzeugen, könnte bereits in diesem Stadium der Feinschliff des Bildes erfolgen. Der Rest des Workflows kann hochautomatisiert erfolgen.

Antwort auf:

Im verfahrensneutralen Workflow könnte aber eine isocoated-cmyk als Basis für alles andere herhalten

Die Wahl eines geeigneten Referenz-CMYK ist enorm wichtig für die Güte einer Verfahrensanpassung. Theoretisch ja, ISOcoated könnte für alles andere herhalten, praktisch muss man prüfen ob der Farbraum geeignet ist. Gegebenenfalls muss man einen synthetischen Farbraum erzeugen.

Antwort auf:

bis jetzt war ich der Meinung, dass cmyk-cmyk-Transformationen - auch über Devicelink-Profile - zu vermeiden seien?!

Wie kommt man auf so etwas. Proofsysteme machen seit Jahren nichts anderes. Da kommt eine ISOcoated-Datei in das Proofsystem und wird auf das Proof-CMYK abgebildet. Seit das Häckschen "reines Schwarz erhalten" existiert, gibt es DeviceLink-Profile. Diese Technik wurde nun weiterentwickelt und kann mittlerweile für die Verfahrensanpassung verwendet werden, und ist oftmals die einzige Chance für Farbanpassungen zwischen CMYK-Farbräumen.

Viele Grüße
Michael Sens

Guten Abend Herr Sens,

Auch ich brauche heute keinen Glaubenskrieg mehr! Nur ein paar Anmerkungen zu den bereits lange diskutierten early binding Strategien:

- Ich denke es wäre für die meisten weniger geschulten Anwender einfacher einen einigermaßen geeigneten RGB-Farbraum auszuwählen (ECI-, L-Star-, Adobe-RGB...) als den genau passenden CMYK-Farbraum. (Bogen?, Rolle?, Zeitung?, Zeitschrift?, gestrichen?, matt?, Naturpapier? usw. usw.)

- Auch ein falscher RGB-Farbraum (sRGB, WideGamut RGB o.ä.) ist im weiteren Workflow wahrscheinlich leichter zu verarbeiten, als ein komplett falscher CMYK-Farbraum (ISOCoated bei Tageszeitungen, SWOP im Bogenoffset usw.), da hier dann wieder so spezielle Werkzeuge wie DeviceLink-Profile zum Einsatz kommen sollten, deren Einsatz aus Kostenfragen wahrscheinlich auch nur für größere Druckerein interessant ist.

...Theoretisch...

Aus praktischer Sicht stösst hier meiner Meinung nach die ganze ICC, PostScript, PDF Systemwelt an ihre Grenzen. Für Bilder kann das ganze noch einigermaßen sauber funktionieren, sobald aber Texte, Grafiken, Rasterflächen und andere Elemente dazukommen wird es sehr sehr schwierig, vor allem dann wenn man sich die so entstandenen Farbnummern mit den Augen des CMYK-gewohnten Repro-Mannes anschaut!

Kurz zum Thema RI: Die Personen die ich kenne, die auch wie ich mit den ECI-Profilen arbeiten haben die Erfahrung gemacht, dass der relativ Farbmetrische RI mit aktivierter Tiefenkompensationen bei (vorsichtig...) 90% der Bilder sehr gute Ergebnisse bringt. Vielleicht könnten wir uns bei dieser Profilkomination auf diesen RI einigen, auch wenn die Tiefenkomensation nicht nicht ganz standardisiert ist...

Aus heutiger Sicht schließe ich mich Ihrer Meinung an, dass verfahrensneutrale Daten (also für Bogenoffset, für Tageszeitungen, für Rollendruck...) wahrscheinlich der bessere Weg für die Repro sind. Aber nicht für die Archivierung in einer Datenbank!
Hier ist es evtl. doch geschickter einen "universellen, generischen" CMYK-Farbraum zu entwickeln, der ähnlich ECI-RGB die Farbräume der wichtigsten Druckverfahren und Charakterisierungsdaten umschließt. ISOCoated ist davor m.E. nicht geeignet, da andere Druckverfahren und Papierkombinationen in best. Farbbereichen doch stärkere Differenzierungen zulassen.

Bei der Seperation von diesem "Master-CMYK" zu den einzelnen "Medien-CMYKs" sind wir dann aber wieder bei der Device-Link-Problematik...!

Vielleicht liegt der Kern des Problemes aber auch in der Seperation selbst begraben:
Informationen zum Schwarzaufbau, Tonwerktzunahmen, Flächendeckungssummen, UCR, GCR, max. Schwarz o.ä. druckspezifische Parameter werden heute von der Profilierung-Erstellungsoftware direkt mit den gemessenen Farbinformationen verrechnet (und bilden einen Teil der BtoA Tabellen des Farbprofils...)

Meine (etwas ketzerische) Frage ist: Gehören diese Informationen wirklich in ein Farbprofil, dass doch eigentlich nur die Farbcharakteristik eines Gerätes beschrieben soll?

Wäre es nicht geschickter wenn im Profil nur Informationen über die Farbe selbst sind, und alles zu Schwarzaufbau, UCR, Tonwertzuwächse usw. in einem eigenen Seperations-Dialog zu packen, der "on the fly" bei der Farbumwandlung bearbeitet werden KANN. Die von ECI o.ä empfohlenen Seperations-Einstellungen könnten dann (z.B. als XML-Schema) zusammen mit dem Farbprofil verbreitet werden.
Z.B. die Reduzierung des Gesamtfarbauftrags könnte so auch im nachhinein noch vorgenommen werden, ohne das ein zweites Farbprofil von nöten wäre. Eigentlich auch logisch: die Farben ändern sich in dem Sinn ja nicht, sondern die Parameter in denen sie sich bewegen. Wichtig ist aus meiner Sicht, das die Seperations-Einstellungen quasi als METADATEN in die Datei eingebunden wären. Dadurch wäre auch in Bezug auf die nachvollziehbarkeit der Datenqualität einiges gewonnen.

...
Das ganze nur mal so als kleiner Lufbalon. Wahrscheinlich ist vieles von dem was ich unstrukturiert geschrieben habe nicht 100% logisch und in sich schlüßig. Aber vielleicht entsteht der ein oder andere Denkanstoss daraus...

Viele Grüße,
Georg Obermayr
...der übrigens trotzdem ICC für sehr gut hält und auch täglich damit sehr erfolgreich arbeitet.

Hallo Michael,

> ... Das heißt ja, dass die Bittiefe des Bildes auf 8 Bit reduziert wird.
> Damit dürfte ja das Phänomen der Quantisierungsfehler wieder auftreten, oder nicht?

Nein, intern wird mit höherer Genauigkeit gerechnet. Bei der Verknüpfung von Eingabe und Ausgabeprofil werden die Korrespondierenden Lab Paare mit AFAIR 16bittiger Genauigkeit gerechnet. Wenn ich ich recht entsinne müsste sich da auch hier im Fundus was finden lassen.

Hallo zusammen
herzlichen Dank für alle Infos, finde die Diskussion sehr interessant! Ich gehe aber immer noch richtig in der Meinung, dass ich als Datenlieferant u.a. der Verpackungsbranche meine Bilddaten als RGB mitliefere? Dazu ein Isocoated mit entsprechendem Proof als Zielvorstellung, da ich in der Regel nicht weiss, wie und wo gedruckt wird – irgendwo zwischen Dänemark und Marokko, vielleicht auch in Thailand.
Ich verstehe aber jetzt den Prepress-Dienstleister besser, welcher mir das verfahrensneutrale cmyk schmackhaft machen wollte. Trotzdem bin ich der Meinung, dass ein cmyk eine Information über seine Entstehung, sprich ein Profil, enthalten sollte - selbst wenn es Verfahrensneutral ist.

Hallo Urs,

Antwort auf:

herzlichen Dank für alle Infos, finde die Diskussion sehr interessant! Ich gehe aber immer noch richtig in der Meinung, dass ich als Datenlieferant u.a. der Verpackungsbranche meine Bilddaten als RGB mitliefere? Dazu ein Isocoated mit entsprechendem Proof als Zielvorstellung, da ich in der Regel nicht weiss, wie und wo gedruckt wird – irgendwo zwischen Dänemark und Marokko, vielleicht auch in Thailand.

Ich unterstelle jetzt mal, dass Ihr Auftraggeber und die beauchtragten Druckereien sich für einen verfahrensneutralen Workflow entschieden haben und sie nun mitziehen müssen. Das sollte man daran merken, dass von einem ein bestimmtes CMYK abverlangt wird.

Der RGB-Datenbestand gehört in Ihr firmeneigenes Archiv. Ausgehend von diesen Datenbestand werden die Daten in ein Referenz-CMYK (das vom Auftraggeber bestimmt wurde) überführt. Anschließend die obligatorische Farbkorrektur. Diese Daten gehen mit einem ICC-Proof an den Auftraggeber. Dieser erstellt dann die Form und die Druckdaten. Diese werden entweder beim Auftraggeber oder in der ausführenden Druckerei in ein druckverfahrensspezifisches CMYK umgesetzt. Die wichtigste Information, in der Prozesskette ist das Referenz-CMYK. Der Datenerzeuger optimiert seine Daten daraufhin. Die Druckerei macht ausgehend von diesem Farbraum die Verfahrensanpassung. Der RGB-Datenbestand wird außerhalb Ihres Unternehmens nicht mehr benötigt.

Antwort auf:

Ich verstehe aber jetzt den Prepress-Dienstleister besser, welcher mir das verfahrensneutrale cmyk schmackhaft machen wollte. Trotzdem bin ich der Meinung, dass ein cmyk eine Information über seine Entstehung, sprich ein Profil, enthalten sollte - selbst wenn es Verfahrensneutral ist.

Theoretisch braucht man das nicht. Da es in dieser Kette nur ein CMYK (das Referenz-CMYK) gibt, das von interesse ist und das jedem beteiligten bekannt sein muss. Praktisch ist es immer zu begrüßen, wenn da ein ICC-Profil dranhängt.

Viele Grüße
Michael Sens

Hallo Herr Obermayr,

Antwort auf:

- Ich denke es wäre für die meisten weniger geschulten Anwender einfacher einen einigermaßen geeigneten RGB-Farbraum auszuwählen

Zum Glück machen die weniger geschulten Anwender was man ihnen sagt.

Antwort auf:

Kurz zum Thema RI: Die Personen die ich kenne, die auch wie ich mit den ECI-Profilen arbeiten haben die Erfahrung gemacht, dass der relativ Farbmetrische RI mit aktivierter Tiefenkompensationen bei (vorsichtig...) 90% der Bilder sehr gute Ergebnisse bringt. Vielleicht könnten wir uns bei dieser Profilkomination auf diesen RI einigen, auch wenn die Tiefenkomensation nicht nicht ganz standardisiert ist...

Ich kenne die Zahlen und die fehlenden 10% sind der Punkt der mich beim Aufbau eines automatisierten Workflows stören. Dann lieber die Farbkorrektur obligatorisch nach der Bildbearbeitung setzen, dort ist man eh noch beim manuellen bearbeiten der Daten.

Antwort auf:

Hier ist es evtl. doch geschickter einen "universellen, generischen" CMYK-Farbraum zu entwickeln, der ähnlich ECI-RGB die Farbräume der wichtigsten Druckverfahren und Charakterisierungsdaten umschließt.

Theoretisch gefällt mir der Gedanke. Praktisch dürfte das nicht realisierbar sein. Da die Druckverfahren (Druckfarben, Papiere, ...) viel zu unterschiedlich sind. Man kann nicht einem L*a*b*-Wert einem CMYK-Wert zuweisen, der für alle Druckverfahren Gültigkeit besitzt.

Antwort auf:

Bei der Seperation von diesem "Master-CMYK" zu den einzelnen "Medien-CMYKs" sind wir dann aber wieder bei der Device-Link-Problematik...!

DeviceLinks sind keine Problematik, sondern eine Lösung.

Antwort auf:

Meine (etwas ketzerische) Frage ist: Gehören diese Informationen wirklich in ein Farbprofil, dass doch eigentlich nur die Farbcharakteristik eines Gerätes beschrieben soll?

Beim Erstellen der DeviceLinks wird genau dieser Punkt aufgegriffen. Die L*a*b*-Werte und die einzelnen Tabellen dienen (bei guten Programmen) nur als Vergleichswerte. Wie letzten Endes der Schwarzaufbau, max. Flächendeckung, etc. umgesetzt wird liegt in der Hand der profilschreibenden Software bzw. beim Anwender des Programms.

Antwort auf:

Seperations-Einstellungen könnten dann (z.B. als XML-Schema)

Ja, der Gedanke wird ja im Moment heftig auf der ColorSync-Liste diskutiert. Das ist ja das Konzept von Windows Vista. Ich hatte noch gar keine richtige Zeit mich da einzulesen. Aber mir wird ganz schwindlig, wenn ich mich daran erinnere, wie groß der Dump eines ISOcoated-Profils ist. Wenn dann nur solche Dateien auf der Festplatte liegen, brauche ich eine Festplatte nur für Profile. Ich sehe gegewärtig auch nicht die Lösung für das eigentliche Problem, der Prozessfarbenkontrolle. Sobald über L*a*b* umgesetzt wird, ist die Prozessfarbeninformation weg. Ob nun mit konventionellen ICC-Profilen oder über XML.

Viele Grüße
Michael Sens

Hallo Herr Sens,

Antwort auf:

Ich kenne die Zahlen und die fehlenden 10% sind der Punkt der mich beim Aufbau eines automatisierten Workflows stören. Dann lieber die Farbkorrektur obligatorisch nach der Bildbearbeitung setzen, dort ist man eh noch beim manuellen bearbeiten der Daten.

Sie haben recht! 90% sind einfach 10% zu wenig. Wenn Gammut Mapping automtisch ablaufen sollte, dann müsste
- entweder das CM-Modul die RI-Entscheidung treffen,
- oder man müsste sich darauf einigen ob Farmetrik oder Perzeption entscheidend sind (wohl eher Farbmetrik, oder?),
- oder man müsste sich überlegen ob es vielleicht doch einen golden Mittelweg dazwischen gibt?

Antwort auf:

DeviceLinks sind keine Problematik, sondern eine Lösung.

Richtig! Sie stellen eine Lösung für CMYK-CMYK Transformationen dar. Für mich sind sie deshalb ein Problem, weil sie Stand heute nur die wenigsten Anwender nutzen können und für die wenigsten erschwinglich sind (weil man in der Vorstufe von Agenturen o.ä. einfach nicht so viele Anwendungen dafür hat). Deshalb auch mein Vorschlag der NAHTLOSEN Integration in das ICC-Framework.

Antwort auf:

Ja, der Gedanke wird ja im Moment heftig auf der ColorSync-Liste diskutiert. Das ist ja das Konzept von Windows Vista. Ich hatte noch gar keine richtige Zeit mich da einzulesen. Aber mir wird ganz schwindlig, wenn ich mich daran erinnere, wie groß der Dump eines ISOcoated-Profils ist. Wenn dann nur solche Dateien auf der Festplatte liegen, brauche ich eine Festplatte nur für Profile. Ich sehe gegewärtig auch nicht die Lösung für das eigentliche Problem, der Prozessfarbenkontrolle. Sobald über L*a*b* umgesetzt wird, ist die Prozessfarbeninformation weg. Ob nun mit konventionellen ICC-Profilen oder über XML.

Das Vista-Konzept wird ja von den Mitglieder des ICC (z.B. Adobe) ziemlich stark kritisiert. Bei Ihrem Punkt bin ich mir nicht ganz sicher, ob ich es richtig verstehe. Ich versuche es mal: Mein Ausgangspunkt war dass mehr Informationen an den verschiedenen Stellen über Ursprung und Ziel der Farbtransformation zur Verfügung stehen. Das Einsteuern der Seperations-Parameter KANN über XML erfolgen (wäre sinnvoll, da verständlich für Anwender), muss aber nicht!
Entscheidend für mich ist, dass die Informationen über die Seperation als METADATEN mit der Datei verbunden sind (kennen Sie XMP?). Es wäre doch schon ein Fortschritt, wenn ich ein CMYK-Bild aufmache, und weiss welcher Schwarzaufbau oder welcher Gesamtfarbauftrag darin stecken.
Ich hoffe, dass war jetzt nicht komplett vorbei an Ihrem Punkt.

Grüße,

Georg Obermayr

HAllo,

Antwort auf:

Sie haben recht! 90% sind einfach 10% zu wenig. Wenn Gammut Mapping automtisch ablaufen sollte, dann müsste
- entweder das CM-Modul die RI-Entscheidung treffen,
- oder man müsste sich darauf einigen ob Farmetrik oder Perzeption entscheidend sind (wohl eher Farbmetrik, oder?),
- oder man müsste sich überlegen ob es vielleicht doch einen golden Mittelweg dazwischen gibt?

Vorweg muss aber erst mal die Wirkungsweise des Gammutmappings festgelegt werden. Z.Z. bestimmt noch jeder Hersteller selber wie oder was perzeptiv ist und was Farbmetrisch.
Bis das nicht ordentlich abgesichert ist, hat jeder weitere Schritt wenig Sinn. (@ Jens: siehst du? 'hat…Sinn' ;-) )

Hallo Herr Obermayr,

Zitat

Sie haben recht! 90% sind einfach 10% zu wenig. Wenn Gammut Mapping automtisch ablaufen sollte, dann müsste

Wer will denn das automatisieren? Da ein Korrekturschritt (zumindest eine Kontrolle) immer notwendig ist, kann man das auch manuell machen. Ansonsten schließe ich mich der Aussage von Thomas an.

Zitat

Richtig! Sie stellen eine Lösung für CMYK-CMYK Transformationen dar. Für mich sind sie deshalb ein Problem, weil sie Stand heute nur die wenigsten Anwender nutzen können und für die wenigsten erschwinglich sind (weil man in der Vorstufe von Agenturen o.ä. einfach nicht so viele Anwendungen dafür hat). Deshalb auch mein Vorschlag der NAHTLOSEN Integration in das ICC-Framework.

Ich sehe den Einsatz eher bei Verlagen und Druckerein, welche die Verfahrensanpassung machen, nicht in den Repros. Die erstellen verfahrensneutrales CMYK und fertig.

Zitat

Entscheidend für mich ist, dass die Informationen über die Seperation als METADATEN mit der Datei verbunden sind (kennen Sie XMP?). Es wäre doch schon ein Fortschritt, wenn ich ein CMYK-Bild aufmache, und weiss welcher Schwarzaufbau oder welcher Gesamtfarbauftrag darin stecken.

Ich kenne XMP und ich verstehe (so glaube ich zumindest) ihren Grundgedanken. Aber was soll Ihrer Meinung nach in den Metadaten eines RGB-Bildes bzw. CMYK-Bildes stehen? Woher es kommt oder wohin es soll?

Viele Grüße
Michael Sens

Hallo Herr Sens,

Zitat

Wer will denn das automatisieren? Da ein Korrekturschritt (zumindest eine Kontrolle) immer notwendig ist, kann man das auch manuell machen. Ansonsten schließe ich mich der Aussage von Thomas an.

Stimmt, diesen Aspekt hatte ich übersehen. Solange die Profilierungssoftware dafür verantwotlich ist, wie die einzelnen RIs implementiert sind und nicht das CM-Modul wird eine Lösung hier noch auf sich warten lassen.

Zitat

Ich kenne XMP und ich verstehe (so glaube ich zumindest) ihren Grundgedanken. Aber was soll Ihrer Meinung nach in den Metadaten eines RGB-Bildes bzw. CMYK-Bildes stehen? Woher es kommt oder wohin es soll?

Woher es kommt, und was es ist! Ich denke da an eine Art "Color-History" in den Metadaten. Wohin es soll ist bei RGB-Daten entweder noch gar nicht klar, oder aber bspw. über den Output Intent einer PDF/X-3 Datei definiert.
Aus meiner Sicht ist es aber wichtig, dass nicht nur drinn steht "komme von ECI-RGB bin jetzt ISOCoated" sondern auch mit welchen Parametern separiert und gewandelt wurde, und diese Parameter müssen dann natürlich auch zur Lauftzeit anpassbar sein.
Das war eher mein Grundgedanke. Ich bin kein Programmierer, über die Umsetzung im Detail kann ich mir nur grundsätzlich Gedanken machen.

Viele Grüße,
Georg Obermayr