Es fehlt aber immer noch die Angabe des Bildprofils. Der Arbeitsfarbraum kommt nur zum tragen, wenn dem Bild selbst keinerlei ICC-Profil zugeteilt wurde. Das ist quasi der Fall-back für unprofiliertes Bildmaterial. Aber bei deinem Screenshot erkenne ich an der deutlich intensiveren Farbe im Farbwähler rechts oben, dass das Bild wohl Adobe-RGB getagt ist ...?
Nein, falsche Vermutung. Bildschirmfarbe bedeutet ungecolormanaged.
Die Werte 0/157/227 werden im Bildschirmfarbraum ausgegeben.
Faktisch bedeutet das, dass du da das Bunteste siehst, was für diesen Wertetrippel auf deinen Widegamut-Display möglich ist – alles gecolormanagte, was 'was wäre wenn' spielt, kann immer nur von dort aus runtergeregelt werden – weil mehr als physisch möglich, geht halt nicht.
Ich verwende ECI-RGB als RGB-Farbraum, der gerade groß genug ist, alle im CMYK-Offsetdruck auf optimalem Papier darstellbaren Farben zu enthalten, ohne unnötig groß zu sein, quasi die perfekte Symbiose aus 'groß genug für alles druckbare', und 'nicht unnötig viel Overhead, den man eh nicht drucken kann'.
Außerdem hat er nicht so ein krankes Gamma wie Adobe-RGB, sondern das dem menschlichen Helligkeitsempfinden nachempfundene CIE-L*.
Was ja meine Vermutung bestätigt, dass du da gerade mit einem Adobe-RGB Bild herumprobierst, und somit den eigentlichen Verursacher in deiner Schilderung komplett unterschlagen hast ;-)
Womit du beim Arbeiten für Web an einem Wide Gamut Monitor leben musst:
Fast alle die auch einen Wide Gamut Monitor besitzen und ihn nicht auf sRGB heruntergedrosselt haben, und/oder einen Browser verwenden, der CM beherrscht, sehen die krätzigen Farben, genauso wie das jahrelang auch alle Plasma-TV oder jetzt OLED-TV Besitzer scheinbar toll finden ... Kein wunder das Colormanagement auf BS Ebene dem Tod geweiht zu sein scheint – da muss sich ja jeder Entwickler an den Kopf fassen und fragen, was er da eigentlich tut.
Farbpalettenleiste?
= Farbfelder Bedienfeld?
Arbeitsfläche?
= dein aktuell im Vordergrund befindliches Bild?
Ich komm hier nicht ganz mit.
Vermutlich ist dein Problem aber folgendes: In den Bedienelementen werden Farben in der Regel passend zum gerade im Vordergrund befindlichen Bild und dessen Farbprofil gezeigt.
Schwierig wird es aber im Prinzip schon, wenn man einen RGB Wert anlegt und ein CMYK Bild geöffnet ist. Hier greift jetzt schon die in den Farbeinstellungen als Default angewählte Renderingpriorität um das hinzubiegen – es gibt eben je Bild nur EIN Farbmodell, und zur Not gerade mal 2 Profile (Dokument- und Proofprofil) die für EIN Bild gelten.
Wenn die Farben in der Werkzeugleiste und den Bedienfeldern nicht so aussehen wie das gerade im Vordergrund aktive Bild, dann stimmt etwas nicht, denn die Darstellung ist eben immer an das angelegt, was man gerade bearbeitet, alles andere wäre doch völliger Humbug: Farben die man im Bild garnicht erzielen kann, bzw. ein deutlich wahrnehmbarer Sprung beim Aufnehmen einer Farbe aus dem gerade aktiven Bild per Pipette.
Hier greift also nur dann der Arbeitsfarbraum (Das ist der so benannte aus den Farbeinstellungen von PS, nicht der mit dem man idR. gerade abreitet), wenn man mit unprofiliertem Material arbeitet.
Sonst ist immer das Bildprofil das Maß der Dinge!
Wohingegen es beim Aufnehmen aus einem im Hintergrund sichtbaren Bild schon wieder problematisch werden kann: Wenn das z.B. ein Graustufen-Bild ist, wie soll der Wert dann für das gerade aktuelle RGB-Vordergrundbild gelten, ohne per CM transformiert zu werden, ein K-Wert kommt im RGB halt nicht vor.
als Antwort auf: [#572567]
(Dieser Beitrag wurde von Thomas Richard am 29. Okt 2019, 12:47 geändert)
