Dann weiß ich fürs nächste Mal Bescheid, danke dir 🐸
der Artikel kann von mir aus verschoben werden, werd nix mehr ändern.
Monitor profilieren mit ArgyllCMS
Anmeldungsdatum: Beiträge: 167 Wohnort: München |
|
Ehemaliger
Anmeldungsdatum: Beiträge: 29449 Wohnort: WW |
|
Anmeldungsdatum: Beiträge: 3 |
Hallo, danke erst mal für die tolle Anleitung. Es geht um den letzten Satz im Artikel: "Trotzdem nicht vergessen, bei Programmen mit Farbverwaltung, wie Gimp, Inkscape oder Scribus unter den Farbverwaltungs-Optionen, als Bildschirm Profil die neue *.icc Datei anzugeben." Ich frage mich ob es so wirklich richtig ist. Denn durch Dispwin wird doch die Korrekturtabelle auf die Grafikkarte geschrieben. Wenn jetzt im entsprechenden Programm erneut die Korrekturtabelle eingetragen und genutzt wird, werden doch die korrigierten Daten vom Grafikprogramm erneut in der Grafikkarte korrigiert und es somit zu einer falschen Farbdarstellung kommen. Bye Robert |
Anmeldungsdatum: Beiträge: 266 |
RobbyBer schrieb:
Da wage ich jetzt mal zu widersprechen.. Nach meinen Informationen muss man unterscheiden zwischen der "Korrekturtabelle" für die Grafikkarte und der Umrechnung in den Zielfarbraum des jeweiligen Grafikprogramms. Ich habe mich damit mal eine Woche relativ intensiv auseinandergesetzt, da ich auch verwirrt war, warum nun (auch unter Windows z.B.) einmal das Betriebssystem die *.icc Datei laden soll für die Korrektur UND dann auch noch das Grafikprogramm (..in der Regel irgendwo unter Einstellungen ... → Monitorprofil). Ich hab dann mal in verschiedenen Foren rumgefragt, bis auch auf Leute gestoßen bin die das mit dem Farbmanagement häufiger machen... und nach deren Meinung muss man sich das folgendermaßen vorstellen: Sowohl OS (.. oder halt ein Dienstprogramm, hier "dispwin") ALS AUCH das Grafikprogramm nutzen zwar dasselbe Profil, aber sie machen UNTERSCHIEDLICHE Sachen damit ! "dispwin" lädt die Tabelle.. das macht sich in der Regel bemerkbar, dass es einen regelrechten "Sprung" in der Farbdarstellung des Monitors gibt, wenn das Profil geladen wird. Bei den weit verbreiteten, eher günstigen am sRGB-Farbraum orientierten TFTs für Home- und Office-Gebrauch wird die Darstellung oft deutlich "wärmer" (hängt aber von den Details der Kalibrierung ab), da die TFTs ab Werk eher auf eine hochkontrastige, kalte Wiedergabe eingestellt sind. Aktiviert man in z.B. GIMP mal das gleiche Profil in Monitorprofil, OHNE vorher mittels dispwin jemals das Profil geladen zu haben, so sollte man schnell bemerken dass der Sprung da bei weitem nicht so stark ausfällt wie bei dispwin! Die Farben und Helligkeiten im Anzeigefenster des Bildes ändern sich meistens eher subtil, zumindest wenn das geladene Bild im sRGB Farbraum vorliegt und der Monitor sich auch eher in diesem Farbraum befindet.. man kann sich das eher wie ein "Feintuning" vorstellen. Erst eine Aktivierung des Profils SOWOHL via dispwin ALS AUCH im Grafikprogramm bewirkt eine möglichst korrekte Darstellung. Das heisst aber auch im Umkehrschluss, dass natürlich viele einfache Viewer da ein Problem haben... sprich, viele sind nicht farbmanagementfähig, die Ausgabe erfolgt auf einem KALIBRIERTEN Monitor (das hat ja dann dispwin systemweit erledigt) aber die Ausgabe erfolgt UNPROFILIERT. Für eine korrekte Darstellung muss das anzeigende Programm zum einen den Farbraum des anzuzeigenden Bildes auswerten und berücksichtigen, ALS AUCH wissen, welches Monitorprofil aktiv ist um vom Quell- in den Zielfarbraum umzurechnen. Browser machen das z.B. in der Regel immer noch falsch.. Firefox berücksichtigt seit neuestem wenigstens den Farbraum des Bildes (mittlerweile glaube ich per Default, in 3.0 musste man das Feature noch aktivieren), aber soweit ich weiß kann man keinen Zielfarbraum (Monitorfarbprofil) setzen. Dumm eigentlich, wo doch die meisten Präsentationen von Bildern heutzutage via Browser laufen. Internet Explorer ist noch viel schlimmer, aber das betrifft uns hier nicht.. 😉 Anders ausgedrückt: "dispwin" ist die "grobe Keule", hier werden Farbtemperatur und Gamma usw. angepasst, das Monitorprofil im Grafikprogramm bewirkt dagegen, dass nun für jedes Farb-Tupel genau umgerechnet wird, wie es auf dem Monitor optimal dargestellt wird, damit das Rot vom Bild auch genau in dem Rot auf dem Monitor erscheint.. das ist nicht selbstverständlich, da das Bild z.B. im sRGB Farbraum vorliegt, aber der Farbraum des Monitors immer etwas variiert.. (nicht mal zwei Monitore derselben Serie sind da wirklich identisch). Dieser Zusammenhang ist zwar verwirrend, aber ich bin mir ziemlich sicher, dass es so ist. Und so verhält es sich auch bei MacOSX und Windows nach meinen Beobachtungen und Recherchen. Man kann natürlich fragen, warum denn nicht JEDE Grafik automatisch von der Farbverwaltung des OS umgerechnet wird.. dann hätte man diese "Zweiteilung" nicht.. nun, ich vermute zumindest EIN Grund wird sein, dass dazu wirklich alle Grafiken vor der Anzeige laufend umgerechnet werden müssten (Konversion Quell-/Zielfarbraum), den Aufwand wollte sich man wohl sparen... Eventuell wäre das technisch wohl mittlerweile locker möglich, aber das Farbmanagement auf PCs ist ja meines Wissens nicht so alt und wurde im Laufe der Geschichte erst später ergänzt... bei Linux ist das offenkundig, da ja da wirklich auch das Laden der Kalibrationsdaten mittels "dispwin", also einem separaten Programm geschieht. Nicht einfacher wird es einem dadurch gemacht, dass manche Programme das dann noch eigenwillig lösen... z.B. ausgerechnet die neueren Versionen von Photoshop (Photoshop Elements glaube ich auch) und Lightroom, wenn ich mich recht entsinne.. Hier wird KEIN Monitorprofil mehr angegeben, was manche zu der Aussage verleitet, dass das Monitorprofil im Anwendungsprogramm gänzlich überflüssig wäre... Aber diese Programme nehmen AUTOMATISCH das Profil welches im Farbmanagement des Betriebssystems hinterlegt ist. Begründung ist meines wissens, dass es eh keinen Sinn machen würde, unterschiedliche Profile in der Farbverwaltung vom OS und vom Grafikprogramm zu nehmen, also hat man die entsprechende Einstellmöglichkeit abgeschafft und das automatisiert.. aber das Verständnis für das Thema ein Stück weit sabotiert. Man sollte also mal diskutieren, ob man den Beitrag nicht wieder anpasst. Ach übrigens.. "argyll" gibt es mittlerweile auch als Paket, weiß jemand seit wann? Dann würde ich das eintragen. Selbst wenn es das nicht geben würde gibt es das von Fremdquellen, z.B. dem unter Linux-Fotografen recht bekannten PPA von Pascal de Bruijn https://launchpad.net/~pmjdebruijn/+archive/ppa , der auch aktuelle Versionen von UFRaw mit LensFun-Plugin bereitstellt. (Fremdquellen gefährden natürlich das System.. klar!) |
Anmeldungsdatum: Beiträge: 589 |
Guten Morgen! Konnte mir Gestern aus der Uni eine Kolorimeter ausleihen und mußte das natürlich gleich testen! Nach dem Wiki-Eintrag war das alles gar kein Problem. In dem Artikel sind ja zwei Wege beschrieben, wie man an das benötigte Toolsuite Argyllcms kommt. Einmal die fertigen binaries von der Herstellerseite laden oder den Quellcode von ebendort ziehen und selber kompilieren. Hatte nachher dann entdeckt, dass das Paket argyll (ver 1.03) mit den benötigten binaries in den Quellen enthalten ist (Ubuntu 9.10). Spricht gegen die in den Quellen enthaltene Version etwas? Oder kann man die auch nehmen? Die Installation über sudo apt-get ist halt doch etwas fixer... |
Anmeldungsdatum: Beiträge: 1 |
Hallo, für Besitzer einer NVidia-Karte, die den nvidia Treiber nutzen, hier noch ein Hinweis: Das Programm nvidia-settings speichert verschiedene Einstellungen in der Konfigurationsdatei $HOME/.nvidia-settings-rc, unter anderem auch zur Farbkorrektur. Bei meinem System (Kubuntu, 10.10) trat nun folgender Effekt auf: dispwin wird mittels KDE Autostart-Funktionalität gestartet. Sobald der Desktop geladen ist, wird der Monitor kurz etwas dunkler, da dispwin dann das Profil geladen hat (soweit, so gut). Dann scheint aber die .nvidia-settings-rc ausgewertet zu werden, und die Korrekturwerte werden wieder auf den Default-Wert gesetzt, der Monitor wird wieder heller (schlecht). "dispwin -V" zeigt dann auch an, dass das Profil nicht geladen ist. Meine Lösung, da ich keine Features aus nvidia-settings brauche: einfach die $HOME/.nvidia-settings-rc löschen. Dann funktioniert es auch mit dem Autostart von dispwin. Oder gibt es vielleicht eine bessere Lösung? Gruß |
Anmeldungsdatum: Beiträge: 28 Wohnort: Pforzheim |
Hallo Zusammen, ich versuche die RGB-Farbwerte mit Selbst-Erstellte-RGB-Testpattern am Plasmadisplay auszumessen. Dazu verwende ich ArgyllCMS in verbindung mit dem ColorMunki. Nun zu meinen Frage: Besteht die Möglichkeit über Argyll einfach nur die RGB-Messwerte anzuzeigen ? 😢 Gruß Djordje |
Anmeldungsdatum: Beiträge: 291 Wohnort: Hamburg |
Ich verwende einen AOC 2236 mit einer NVIDIA GeForce 8200 und dem NVIDIA-Treiber auf Ubuntu 10.04 (64bit). Nun habe ich einen neuen Scanner, den ich gemeinsam mit dem Bildschirm kalibrieren möchte; und fange natürlich mit dem Bildschirm an. Dazu habe ich einen Eye-One Display 2-Kalibrator, der angeblich auch von der verfügbaren Argyll-Version 1.1.0-5 unterstützt wird, die ich über Synaptic installiert habe. Leider tut sich überhaupt nichts auf /usr/share/color/icc$ sudo targen -v -d3 -f836 DisplayA außer der unbefriedigenden Antwort sudo: targen: command not found Dabei gibt es unter /usr/share/color noch ein Verzeichnis /argyll/ref und ein ls ergibt 3dap5k.sp D50_0.1.sp ECI2002R.ti2 LaserSoftDCPro.cht CIE_C.sp D50_0.3.sp example121.sp Office.sp ClayRGB1998.icm D50_0.5.sp example.sp QPcard_201.cht CMP_Digital_Target-3.cht D50_0.7.sp FograStrip.ti1 QPcard_201.cie CMP_DT_003.cht D50_1.0.sp FograStrip.ti2 SOtele.sp ColorChecker.cht D50_1.2.sp GTIPlus.sp sRGB.icm ColorChecker.cie D50_1.5.sp Hutchcolor.cht strange.cal ColorCheckerDC.cht D50_1.7.sp i1_RGB_Scan_1.4.cht TruluxPlus.sp ColorCheckerSG.cht D50_2.0.sp i1_RGB_Scan_1.4.ti2 Trulux.sp ColorChecker.ti2 D50_2.5.sp it8.cht D50_0.0.sp D50_3.0.sp lab2lab.icm Scheint also alles da zu sein. Kann mir bitte jemand auf's Pferd helfen? |
Anmeldungsdatum: Beiträge: 9245 |
|
Anmeldungsdatum: Beiträge: 291 Wohnort: Hamburg |
Stimmt. Den Kasten hatte ich übersehen. 😳 Nun läuft alles. Womit ich allerdings Schwierigkeiten habe, sind einzelne Einstellungen in den verschiedenen Programmschritten. So gut ich konnte, hab ich die Einstellungen des Bildschirms angepaßt (das OSD ist richtig sch&$@#...), das Ergebnis ist allerdings eine eher milchige Darstellung, die sicherlich noch nicht paßt. Argyll hat aber alles korrekt gemacht, einschließlich ICC-Datei. Ich bin der Doofe. Da ist zum Beispiel die Option 4, wo die "R,G & B offsets" zu einem "target x,y" angeglichen werden sollen. Das sieht bei mir so aus: Adjust R,G & B offsets to get target x,y. Press space when done. Target Br 1.32, x 0.3130, y 0.3365 \ Current Br 1.76, x 0.2835, y 0.2875 DE 17.6 R+ G++ B- Nun habe ich wenig Ahnung von Grafik, und kann weder über die Helligkeit noch über die einzelnen Farben halbwegs das Ziel erreichen. "R+ G++ B-" bezieht sich sicherlich auf die Farben, bloß: Sind sie jetzt zu hoch/zu niedrig oder sollen sie höher/niedriger sein? Eine direkte Veränderung der Farben bringt praktisch nichts und "G++" verändert sich an einer bestimmten Stelle z.B. ohne Übergang zu G--. Tante Edit: Vielleicht hat jemand einen Hinweis auf die Ergebnisse für "Check all": Doing check measurements Black = XYZ 0.05 0.05 0.10 Grey = XYZ 7.32 7.52 13.40 White = XYZ 32.26 35.00 47.31 1% = XYZ 0.37 0.35 0.74 Current Brightness = 35.00 Target 50% Level = 6.63, Current = 7.52, error = 2.5% Target Near Black = 0.35, Current = 0.55, error = 0.6% Current white = x 0.2816, y 0.3055, VDT 8457K DE 2K 6.7 Target black = x 0.2816, y 0.3055, Current = x 0.2540, y 0.2410, error = 21.95 DE |
Anmeldungsdatum: Beiträge: 9245 |
Musst Du Dich wohl durch die Doku 🇬🇧 quälen 😉 Gruß |
Anmeldungsdatum: Beiträge: 291 Wohnort: Hamburg |
Das allein wird nicht tun. Die Doku habe ich hier und der englischen Zunge bin ich wohl auch mächtig. Bloß verstehe ich manche Begriffe einfach nicht, weil ich von Grafik zuwenig Ahnung habe. Das betrifft eben auch die Ausgabe von "Check all": Ich sehe, was da steht, und bei manchen Sachen weiß ich eben nicht, was sie bedeuten. Muß ich mich wohl noch weiter reinfummeln. |
Anmeldungsdatum: Beiträge: 1 |
Hallo alle
Bin auf der Suche nach einer Lösung für mein Problem auf diesen alten thread gestossen. Bisher dachte ich eigentlich auch, dass das so ist, aber ich habe diesbezueglich folgende Probleme: Wenn ich einmal das icc Profil im BS als Standardprofil für die Graphikkarte hinterlege und es zusätzlich bei Systemstart mit dispwin lade, dann hat das zur Folge, dass PS statt Schwarz (RGB 000) ein dunkles Lila anzeigt. Wenn ich es aus dem BS als Standardprofil entferne und nur mit dispwin lade ist alles gut. Schwarz ist auch wirklich schwarz. Funktioniert das nun doch nicht wie im Artikel beschrieben, dass man das Profil nicht "doppelt" laden kann, oder hab ich irgendwas anderes falsch gemacht? Gruss Ralf |
Anmeldungsdatum: Beiträge: Zähle... |
Hallo zusammen, ich habe gestern den Versuch unternommen, den Artikel in Bezug auf Probleme mit Spyder 2/3 zu ergänzen, ich selbst hatte Probleme mit Spyder3, glaube aber aufgrund meiner Recherchen, dass sie auch mit Spyder2 auftreten können. Meine Änderung wird (bisher) nicht angezeigt, vielleicht habe ich auch irgendwelche Regeln verletzt, daher meine Anfrage, die ich vielleicht besser zuerst eingestellt hätte. Mein Textvorschlag wäre: Damit sollte die Firmware automatisch von der CD ausgelesen werden. Eine ausführlichere Beschreibung bietet die Argyllcms Webseite unter Spyd2en 🇬🇧 . Besitzt man keinen Spyder 2, kann man diese Schritt überspringen und fährt mit der eigentlichen Kalibrierung fort: Probleme mit Spyder2 und Spyder3¶Bei Spyder2 und Spyder3 kann es vorkommen, dass sie zunächst nicht ansprechbar sind, obwohl sie mit dem Befehl lsusb als angeschlossene Geräte aufgelistet werden. Es erfolgt dann beim Versuch zu kalibrieren / profilieren eine Fehlermeldung. Auf der Seite von Steffen Engelmann-Gähler http://www.gaehler.gmxhome.de/GrafikLinux/GrafikunterLinux.html#Hardwarebesonderheiten%20mit%20Spyder%20Colorimeter wird eine Lösung dieses Problems angeführt, die bis unter „Oneiric Ocelot“ getestet wurde: Um den Spyder benutzen zu können gibt man im Terminal folgenden Befehl ein: sudo mv /lib/udev/mtp-probe /lib/udev/mtp-probe_save Nach Abschluss der Kalibrierung / Profilierung kann das mit dem Befehl: sudo mv /lib/udev/mtp-probe_save /lib/udev/mtp-probe rückgängig gemacht werden. Nun zur eigentlichen Kalibrierung:¶
Ich weiß nicht, ob es korrekt ist, eine Quelle in der Weise anzugeben, wie ich es getan habe, in jedem Fall habe ich bei Steffen Engelmann-Gähler, von dem der Tipp stammt, per Mail angefragt, ob er mit Veröffentlichung und Link einverstanden ist, was er bestätigt hat. Außerdem würde ich noch auf die Möglichkeit, dispcalGUI als grafische Oberfläche zu verwenden hinweisen wollen, auch wenn es dazu bisher noch keinen eigenen Beitrag gibt. Grüße |
Anmeldungsdatum: Beiträge: 14259 |
Scheinen verloren gegangen zu sein... die letzte Aenderung ist von Ende Mai.
Welche?
Immer eine gute Idee ☺
Dann sollte es ok sein.
Du koenntest einen Link am Ende des Artikels hinzufuegen. |