[GastForen PrePress allgemein CMS (Color-Management) GaMapICC: OS X GUI für Argyll DeviceLink Tools

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

GaMapICC: OS X GUI für Argyll DeviceLink Tools

Thomas Richard
  
Beiträge gesamt: 19338

11. Okt 2008, 23:51
Beitrag # 1 von 10
Bewertung:
(9734 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,

Klaus Karcher hat den Commandline Tools von Graeme Gill eine Bedienoberfläche verpasst:

http://digitalproof.info/gamapicc/

Das Droplet nimmt ein oder mehrere TIFFs (RGB und CMYK mit icc-Profil V2, keine ZIP Komprimierung) entgegen, erzeugt ein optimiertes Gamutmapping für den gewählten Ausgabefarbraum, und wendet dieses auf die Bilder an.

3 Strategien des Gamutmappings stehen zur Verfügung:
Quellprofilspezifisch (entspricht dem klassischen perzeptiven RI)
Bildspezifisch
Bildserienspezifisch

Die heute veröffentlichte Version ist noch nicht final, es gibt unter bestimmten Systemen noch Performance Einbrüche oder Abstürze.

[Soweit meine Übersetzung von Klaus Karchers Ankündigung in der Apple ColorSync Liste.]



Jetzt noch ein bisschen was von mir...

Das Tool adressiert das leidige Problem des Gamutmappings in gewohnter Art, wobei völlig unabhängig vom tatsächlichen Bildinhalt vom großen in den kleinen Farbraum hineingerechnet wird.
Bei abs. oder rel. Farbmetrischem RI, ist das solange z.B. kein Problem, wo die Quellfarben trotz größerem Farbraums den Zielfarbraum nicht überragen, da dort in dem Fall kein Kappen zum Tragen kommt, aber bei perzeptiver Wandlung ist es ärgerlich, hoch gesättigte Farben quasi präventiv in den Zielfarbraum hineinzuzwängen um Platz für noch höher gesättigte Farben zu schaffen, die aber gar nicht vorkommen.
So sind wahrscheinlich weit über 99% aller fotografierten Portraits mit sRGB abzuhandeln.Da dann mit gewohnter Technik mit Adobe RGB oder gar noch größeren Gamuts zu arbeiten, und dann noch Farben einzubüssen, dürfte gegenüber der direkten Verwendung des 'kleinen' sRGBs die weitaus größeren Verluste nach sich ziehen.

(Dieser Beitrag wurde von Thomas Richard am 12. Okt 2008, 22:13 geändert)
X

GaMapICC: OS X GUI für Argyll DeviceLink Tools

KlausK
Beiträge gesamt: 6

12. Okt 2008, 08:11
Beitrag # 2 von 10
Beitrag ID: #369931
Bewertung:
(9679 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Moin allerseits,

... jetzt muss ich dann doch mal ein paar Dinge klarstellen:

Antwort auf [ Thomas Richard ] Klaus Karcher hat den Commandline Tools von Graeme Gill eine Bedienoberfläche verpasst:

http://digitalproof.info/gamapicc/

Das Droplet nimmt ein oder mehrere TIFFs (RGB und CMYK mit icc-Profil V2, keine ZIP Komprimierung) entgegen, erzeugt ein optimiertes Gamutmapping für den gewählten Ausgabefarbraum, und wendet dieses auf die Bilder an.

3 Strategien des Gamutmappings stehen zur Verfügung:
Quellprofilspezifisch (entspricht dem klassischen perzeptiven RI)
Bildspezifisch
Bildserienspezifisch

Die heute veröffentlichte Version ist noch nicht final, es gibt unter bestimmten Systemen noch Performance Einbrüche oder Abstürze.

[Soweit meine Übersetzung von Klaus Karchers Ankündigung in der Apple ColorSync Liste.]


.. 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.

Antwort auf [ Thomas Richard ] Jetzt noch ein bisschen was von mir...

Das Tool adressiert das leidige Problem des Gamutmappings in gewohnter Art, wobei völlig unabhängig vom tatsächlichen Bildinhalt vom großen in den kleinen Farbraum hineingerechnet wird.
Bei abs. oder rel. Farbmetrischem RI, ist das solange z.B. kein Problem, wo die Quellfarben trotz größerem Farbraums den Zielfarbraum nicht überragen, da dort in dem Fall kein Kappen zum Tragen kommt, aber bei perzeptiver Wandlung ist es ärgerlich, hoch gesättigte Farben quasi präventiv in den Zielfarbraum hineinzuzwängen um Platz für noch höher gesättigte Farben zu schaffen, die aber gar nicht vorkommen.


ok.

Antwort auf [ Thomas Richard ] So sind wahrscheinlich weit über 99% aller fotografierten Portraits mit sRGB abzuhandeln. Da dann mit gewohnter Technik mit Adobe RGB oder gar noch größeren Gamuts zu arbeiten, und dann noch Farben einzubüssen, dürfte gegenüber der direkten Verwendung des 'kleinen' sRGBs die weitaus größeren Verluste nach sich ziehen.


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.

Klaus


als Antwort auf: [#369928]

GaMapICC: OS X GUI für Argyll DeviceLink Tools

KlausK
Beiträge gesamt: 6

12. Okt 2008, 08:54
Beitrag # 3 von 10
Beitrag ID: #369933
Bewertung:
(9668 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo.

Noch eine kleine Korrektur:
Zitat [..] 3 Strategien des Gamutmappings stehen zur Verfügung:
Quellprofilspezifisch (entspricht dem klassischen perzeptiven RI) [..]



Zitat ... soweit auch alles richtig.


... fast jedenfalls: Quellprofilspezifisch entspricht nicht dem klassischen perzeptiven RI -- der berücksichtigt beim Gamutmapping das Quellprofil nämlich nicht -- aber das hatte ich, glaube ich, bereits hinreichend erklärt.

Klaus


als Antwort auf: [#369931]

GaMapICC: OS X GUI für Argyll DeviceLink Tools

loethelm
  
Beiträge gesamt: 6029

12. Okt 2008, 10:59
Beitrag # 4 von 10
Beitrag ID: #369939
Bewertung:
(9650 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,


Antwort auf: Das Standard-Verhalten ist aber noch dumpfer, da es den Quellfarbraum nicht berücksichtigt (das Zielprofil berechnet sein Gamutmapping ohne das Quellprofil zu kennen)


das ist so auch nicht ganz korrekt. Das ICC hat mit dem PRMG einen Referenzgamut beschrieben, der als universeller Quellgamut für das Gamutmapping genutzt werden soll. Das Problem ist nun aber, dass dieser ausschließlich in ICC v4-Profilen wirklich genutzt werden kann, diese aber noch kaum jemand anwendet.
Ich bin sehr gespannt, ob der Ansatz Quellbildspezifisch sich endlich mal durchsetzt.


Antwort auf: 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.


Diesen Verlust habe ich auch festgestellt. Sehr schön (oder eben auch nicht schön) erkennbar zum Beispiel in den Bechern, die vor der dunkelblauen roman16-Tante stehen.


als Antwort auf: [#369931]

GaMapICC: OS X GUI für Argyll DeviceLink Tools

KlausK
Beiträge gesamt: 6

12. Okt 2008, 11:29
Beitrag # 5 von 10
Beitrag ID: #369945
Bewertung:
(9644 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Antwort auf [ loethelm ] Hallo,


Antwort auf: Das Standard-Verhalten ist aber noch dumpfer, da es den Quellfarbraum nicht berücksichtigt (das Zielprofil berechnet sein Gamutmapping ohne das Quellprofil zu kennen)


das ist so auch nicht ganz korrekt. Das ICC hat mit dem PRMG einen Referenzgamut beschrieben, der als universeller Quellgamut für das Gamutmapping genutzt werden soll. Das Problem ist nun aber, dass dieser ausschließlich in ICC v4-Profilen wirklich genutzt werden kann, diese aber noch kaum jemand anwendet.


Der PRMG ändert leider nichts an der Tatsache, dass Quell und Ziel-Gamut sich "nicht sehen" können, wenn das Gamutmapping berechnet wird. Er entschärft zwar die Problematik etwas, löst sie aber nicht (im Gegenteil: er ersetzt letzen endes perzeptives durch eine Art sättigungserhaltendes Gamutmapping).

Warum auch die ICCv4-PRMG-Lösung kein echtes, perzeptives Gamutmapping zulässt, kann sehr schön auf Graemes Seite http://www.argyllcms.com/...iccgamutmapping.html nachgelesen werden.

Antwort auf:
Antwort auf: 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.


Diesen Verlust habe ich auch festgestellt. Sehr schön (oder eben auch nicht schön) erkennbar zum Beispiel in den Bechern, die vor der dunkelblauen roman16-Tante stehen.


Das finde ich gerade ein besonders gutes Beispiel für die Vorzüge von ArgyllCMS/GaMapICC. Bist du sicher, dass das, was du im Blaus siehst, nicht durch Monitor-Clipping beeinträchtigt ist? Wir können uns meinetwegen darüber unterhalten, ob der Helmholz-Kohlrausch-Effekt von ArgyllCMS überbewertet wird, aber das Ergebnis ist -- im Gegensatz zu einer perzeptiven Konvertierung mit dem ECI ISOcoated-Profil weder abgerissen noch nach violett verschoben.

Ich bereite aber gerade ein Beispiel vor, an dem man gut sehen kann, was ich meine. Sobald es online ist melde ich mich wieder.

Klaus


als Antwort auf: [#369939]

GaMapICC: OS X GUI für Argyll DeviceLink Tools

loethelm
  
Beiträge gesamt: 6029

12. Okt 2008, 11:53
Beitrag # 6 von 10
Beitrag ID: #369947
Bewertung:
(9632 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Antwort auf: Bist du sicher, dass das, was du im Blaus siehst, nicht durch Monitor-Clipping beeinträchtigt ist?


Nein, bin ich nicht. Ich bin noch nicht dazu gekommen, Proofs zu machen.


als Antwort auf: [#369945]

GaMapICC: OS X GUI für Argyll DeviceLink Tools

KlausK
Beiträge gesamt: 6

12. Okt 2008, 15:52
Beitrag # 7 von 10
Beitrag ID: #369968
Bewertung:
(9587 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Zitat Ich bereite aber gerade ein Beispiel vor, an dem man gut sehen kann, was ich meine. Sobald es online ist melde ich mich wieder.

Das Beispiel ist online und unter http://www.freelists.org/...0-2008/msg00065.html zur Diskussion gestellt.

Klaus


als Antwort auf: [#369945]

GaMapICC: OS X GUI für Argyll DeviceLink Tools

Thomas Richard
  
Beiträge gesamt: 19338

12. Okt 2008, 22:12
Beitrag # 8 von 10
Beitrag ID: #369986
Bewertung:
(9550 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Klaus,

schön dass du dich persönlich eingefunden hast, da brauch ich nicht zu dolmetschen ;-)

Antwort auf [ KlausK ] Moin allerseits,

... jetzt muss ich dann doch mal ein paar Dinge klarstellen:

Aber gerne.


Antwort auf [ KlausK ]
Antwort auf [ Thomas Richard ] So sind wahrscheinlich weit über 99% aller fotografierten Portraits mit sRGB abzuhandeln. Da dann mit gewohnter Technik mit Adobe RGB oder gar noch größeren Gamuts zu arbeiten, und dann noch Farben einzubüssen, dürfte gegenüber der direkten Verwendung des 'kleinen' sRGBs die weitaus größeren Verluste nach sich ziehen.


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.

Aha, ok, wir haben es also mit 5 Instanzen des perzeptiven Renderingintents zu tun, von schlecht nach gut:

1. globales Mapping laut Voreinstellung im Zielprofil, u.U. mit der Prämisse, das alles was kommt, komplett Lab abdeckt, also richtig viel Platz für aussen drumherum veranschlagt wird.
2. Der neue Ansatz in ICC V4 Profilen über ein PRMG im Zielprofil, wo ein 'wahrscheinlich zu erwartender Quellgamut', sinnvollerweise < CIE Lab, veranschlagt wird, auch der kann viel zu groß sein, wenn eben als Quellfarbraum schon was recht kleines wie sRGB daherkommt.
3. Die erste Option von GaMapICC, Quellprofil orientiert zu mappen, sprich als Maximum der zu erwartenden Buntheiten den Gamut des Quellprofils anzunehmen.
4. Die Bildserienspezifische Dimensionierung in GaMapICC, bei der die Extrema aus einer Serie von Bildern, so wird der kleinstmögliche aber auch größtnötige gemeinsame Gamut aus einer Bildserie als Bezugsgröße herangezogen, was im Sinne einer harmonischen Tramsformation einer Bildserie sehr zu begrüßen wäre, weil sonst bei einer Serien von Stillleben wo sukzessive ein immer bunter werdendes Objekt einer Farbe hinzugelegt wird, immer dieses als neues, buntestes als Endpunkt herangezogen wird, was dazu führen würde, das die vormals buntesten Objekte sukzessive immer unbunter werden, weil ja neuer Platz für was noch bunteres geschaffen werden muss, sprich die Endresultate würden wahrscheinlich den Eindruck erwecken, als wäre das neueste Objekt immer maxmial gesättigt, die früheren würden zunehmend 'verwelken'.
5. Die bildspezifische Dimensionierung, die der gerade erwähhnten Problematik nicht gewachsen ist, es aber auch nicht müsste, weil eben nur das eine, konkrete, gerade zum Mapping anstehende Bild das Ende der Fahnenstange vorgibt.

Hab ich das jetzt soweit richtig erfasst?


als Antwort auf: [#369931]
(Dieser Beitrag wurde von Thomas Richard am 12. Okt 2008, 22:20 geändert)

GaMapICC: OS X GUI für Argyll DeviceLink Tools

Thomas Richard
  
Beiträge gesamt: 19338

12. Okt 2008, 22:19
Beitrag # 9 von 10
Beitrag ID: #369988
Bewertung:
(9547 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Antwort auf [ KlausK ] Das Beispiel ist online und unter http://www.freelists.org/...0-2008/msg00065.html zur Diskussion gestellt.

Nur mal so auf die schnelle nach Ansicht der Kanäle an einem Macbook Pro: Das AdobeRGB hat aber auch schon reichlich Probleme (alle Kanäle schlagen an beiden Enden des Histograms deftig ein), da kann man sicherlich nicht erwarten das noch irgendwas zu retten ist, egal wie vorsichtig man da mapt.


als Antwort auf: [#369968]

GaMapICC: OS X GUI für Argyll DeviceLink Tools

KlausK
Beiträge gesamt: 6

12. Okt 2008, 22:58
Beitrag # 10 von 10
Beitrag ID: #369992
Bewertung:
(9536 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Zitat Aha, ok, wir haben es also mit 5 Instanzen des perzeptiven Renderingintents zu tun, von schlecht nach gut: [..] Hab ich das jetzt soweit richtig erfasst?


Ja, weitgehend -- mit einer kleinen Ausnahme, und zwar (1): kein Hersteller geht davon aus, das "Lab" komplett Clipping-frei abgedeckt werden muss (weder der zulässige Datenraum noch der Optimalfarbkörper) -- zum Glück, den an so einem Profil hätte wohl keiner wirklich Freude. In der Praxis hat, was den angenommenen Quellfarbraum angeht, bisher jeder Hersteller sein eigenes, mehr oder weniger geheimes Süppchen gekocht. Linotype/Heidelberg verwendet angeblich den "Pointer-Farbraum", der sich meines Wissens auf eine Arbeit von Michael R. Pointer bezieht und alle (damals) verfügbaren, d.h. natürlich vorkommenden oder technisch herstellbaren Körperfarben abdecken soll. Der PRMG ist ein herstellerübergreifender, standartisierter Gamutmapping-Farbraum und übrigens nur eine optionale Ergänzung zu ICCv4 (v4-Profile müssen ihn nicht verwenden)

Klaus


als Antwort auf: [#369986]
X