Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03440.jsonl.gz/1301

Es geht, so habe ich es verstanden, darum dass eine wandlung von RGB nach CMYK zu unbefriediegenden ERgebnissen geführt hat. Die konkrete NAchfrage ging darum, ob alles korrekt parametreiert war, um einen Anwenderfehler ausschliessen zu können. Das wurde hinlänglich abgeklärt, und Fazit war, dass die RGB Farben ausserhalb des CMYK Farbraums lagen, und es somit zu Farbverscheibungen und Sättigungs- und Kontrastverlusten kommen muss.
Das ganze bis hierher ist völlig unabhängig vom Ort der Wandlung, also egal ob early-, intermediate- oder late binding. Erst Recht wenn innerhalb der Creative Suite auf einheitliche Ressourcen zurückgegriffen wird.
Von daher hat Adelbergers Einwand hier einfach nichts verloren.
Die weitere Behauptung, dass es nicht besser ginge, ist einfach falsch.
Erklärung: Befinden sich modulierende Bildpartien, die komplett Out of Gamut sind, insbesondere solche, die nicht auch noch am Rand des Gamuts der Quellfarbraums liegen, im Bild, kommt es zu den beiden hinlänglich bekannten Szenarien:
Perzeptivische bzw. Photografische Wandlung: Diese ist was den Bildinhalt betrifft, die vorzuziehende Variante, da sie Grundsätzlich die Zeichnung erhält, unter Strich ist sie aber in der Praxis die schlechtere Wahl, weil man sich diesen Vorteil mit zum Teil erheblichen Nachteilen erkauft. Als da wären: Das perzeptive RI geht global ans ganze Bild, sprich es werden auch Partien des Quelfarbraums proportional in den Zielfarbraum hineintransferiert, die eigentlich nicht zu transferieren wären. Das liegt daran, dass keinerlei individuelle Abklärung der tatsächlich notwendigen Entfärbungen statt findet. Es wird der Quellfarbraum (oder ein noch größerer, stellvertretender Übergamut) angesetzt, dessen äusserste Hülle in den Zielfarbraum hineingestaucht wird. Dessen Volumen wird generell veranschlagt, unabhängig davon, ob im Motiv evtl. nur 2 nebeneinanderliegende Pixel, deren Relation zueinander erhalten werden soll, nur ganz knapp ausserhalb des Zielgamuts liegen, oder wir es mit einem synthetischen Überbunt-Motiv zu tun haben, dessen Bildpixel zu 100% weit ausserhalb des Zielfarbraums liegen.
Beim perzeptiven RI haben wir also globale, starke Einbussen in Sachen Buntheit, obwohl evtl. nur marginale Einbussen nötig wären.
Der relativ farbmetrische RI ist schnell abgehandelt. Er hat den Vorteil nur wirklich da einzugreifen, wo Not am Mann ist, sprich Farben des Quellfarbraums nicht im Zielfarbraum 1:1 umzusetzen sind – allerdings geht er hier mit der Holzhammermethode zu Werke, da alles was OOG ist, auf den Rand des Zielgamuts skaliert wird. Aber es werden eben keinerlei Farben angetastet die schon im Quelfarbraum innerhalb des Gamuts des Zielfarbraumes liegen (m.E. der Hauptgrund dafür, dass 95% der Leute, die sich beide Ergebnisse anschauen oder ein Gefühl für die auftretenden Verluste entwickelt haben, sich für rel. FM als default in der täglichen Praxis entscheiden), somit ist die globale Buntheit des Ergebnisses höher, aber es verliert eben in hochgesättigten, aber doch noch modulierenden Bildpartien komplett an Zeichnung - diese Stellen wirken dann eben Stumpf (das ist unabänderbar), und wie mit dem Farbeimer eingefärbt (hier ist der Ansatz, das Bild händisch für ein besseres Endergebnis bei der Separation zu optimieren – und das geht eben meines Wissens nach nur in Photoshop.
(Bevor jetzt jemand aufsteht und sagt, ja dann mach ich die doch in PS, aber Wandeln tue ich dann eben doch erst viel später, dem muss ich entgegnen, dass hier das selbe gilt, wie für DeviceLink Profile: Es handelt sich um eine individuelle Anpassung die genau auf die beteiligten Profile abgestimmt wird. Manipuliert man das Bild also zuvor, wandelt dann später aber mit anderen als den dafür vorgesehenen Parametern und Profilen, ist der Vorteil wieder komplett dahin, respektive der Schuss kann komplett nach hinten losgehen (So ein optimiertes ECI oder AdobeRGB Bild ist sicherlich nicht mehr erste Wahl für eine Onlineverwendung per sRGB!).)
Also, nun zur denkbar sinnvollsten (ausser der Option mit Variablen, individuellen Gamuts für jede Wandlung zu arbeiten (wie es Graeme Gill mit Argyll ermöglicht)), Vorgehensweise: Es werden die OoG Partien (und darunterliegende, benachbarte ingamut Partien) des Bildes partiell und individuell so weit perzeptiv entsättigt, bis sie in den Zielgamut passen. Andere Bildpartien die evtl. OoG sind, bei denen aber keine Beeinträchtigungen der Bildaussage zu erwarten ist, können OoG bleiben. Anschliessend kann relativ Farbmetrisch gewandelt werden, ohne dass das Bild global in dem Maße entsättigt würde, wie es bei der rein automatischen, perzeptiven Wandlung der Fall wäre.
Ich habe vor geraumer Zeit etliche Bilder von Sicherheitsbekleidung mit Neonfarben und Autoreflexionsfolien auf diese Weise separiert, die mit keiner der beiden 'out of The Box' Methoden auch nur ansatzweise so schonend auf CMYK einzudampfen gewesen wären.
Ich weiss, dass ich damit hier nichts neues erzähle, und ich weiss auch, dass das Adelberger in keinster Weise von seinem Glauben abbringen wird, aber bevor mir hier vorgeworfen wird, ich wäre unsachlich, mach ich mir die Mühe, und versuche es zu erklären – fragt sich eben bloss, für wen.
In der Hoffnung, dass es für jemand weniger beratungsresistenten noch eine Erweiterung des Horizonts darstellt, verbleibe ich mit frustrierten Grüßen
... jetzt muss ich dann doch mal ein paar Dinge klarstellen:
.. soweit auch alles richtig. Vor allem bei CMYK-Ausgabeprofilen scheint es mit dem Hintergrundprozess "collink" noch einige Speicherverwaltungsprobleme zu geben. Sie führen dazu, dass der Prozess unglaublich langsam wird und eine menge Daten vom RAM auf die Festplatte auslagert. Manchmal stoppt der Prozess auch, da er vom System keinen weiteren Speicher bekommt. Graeme ist das Problem bekannt, wir haben bereits eine Reihe debugging-Versionen getestet, das Problem ist aber noch nicht gelöst. Mit RGB-Ausgabeprofilen sollte es keine Probleme geben: die ganze Prozedur nimmt dann ca. ein bis zwei Minuten pro Bild in Anspruch (inklusive bildspezifischen Gamutmapping). Weitere Performance-Verbesserungen sind in Planung.
Auch beim eigentlichen Gamutmapping gibt es noch einige Ungereimtheiten, die geklärt werden sollten. So ist mir z.B. bei hochgesättigten, dunklen Rot- und hellen Cyan-Tönen ein Zeichnungsverlust aufgefallen, der so nicht stattfinden dürfte.
Diese Bugs verhindern im Moment noch einen produktiven Einsatz, ich bin aber sehr zuversichtlich, dass sie bald gelöst sein werden -- die Richtung stimmt jedenfalls: Graemes Tools liefern genau das, was "konventionellem" ICC-Farbmanagement fehlt und ich denke/hoffe, das s derartige Funktionen in ein paar Jahren zum Standardrepertoire eines ordentlichen Colormanagement-Systems gehören werden.
ok.
Das würde stimmen, wenn sRGB und AdobeRGB LUT-Profile wären. Da sie aber Matrix-Profile sind, findet das Gamut-Mapping ausschließlich im Ausgabeprofil statt. Und zwar mit "vorgebackenen" Gamut-Mappings: bereits der Hersteller der Profilierungssoftware hat entschieden, wie das aussieht, also welche Farben wie stark komprimiert werden sollen und ab wo geclippt wird (ja, ich spreche von clipping im perzeptiven Intent!) -- und zwar ohne das Bild oder den Quellfarbraum zu kennen. Das das nicht in allen Fällen zu optimalen Ergebnissen führen kann, dürfte jedem klar sein.
Hier setzt GaMapICC/ArgyllCMS ein: zuerst wird der Quellfarbraum analysiert, dann ein optimiertes Gamutmapping errechnet und in ein DeviceLink-Profil geschrieben und schließlich werden die Bilder damit konvertiert.
Dieses Gamutmapping kann entweder
- Quellprofilspezifisch sein (das heißt: der komplette Quellfarbraum wird in den Zielfarbraum "gequetscht". Diese Situation hat Thomas fälschicherweise als Standard-ICC-CM-Verhalten bezeichnet. Das Standard-Verhalten ist aber noch dumpfer, da es den Quellfarbraum nicht berücksichtigt (das Zielprofil berechnet sein Gamutmapping ohne das Quellprofil zu kennen)
- oder Quellbildspezifisch sein (optimal für Einzelbilder)
- oder Quellsequenzspezifisch sein (optimal für Serien von Bildern, die gleich behandelt werden sollen). In diesem Fall wird die Vereinigungsmenge aller Bild-Gamuts als Quelle für das Gamutmapping verwendet.