Beiträge von Retrofan im Thema „Welche Palette?“

    Für die Kalibrierung eines Monitors braucht man ein Stück Software und eine extra angeschaffte Hardware.
    Die Software wird daraufhin verschiedene Farben darstellen und die Hardware wird diese aufzeichnen und mit dem Wert deines Druckers vergleichen. Anschließend wird der Monitor kalibriert.


    Der Drucker hat mit der Kalibrierung (besser Profilierung) des Bildschirms nichts zu tun. Bei der Drucker-Kalibrierung werden Testmuster gedruckt und anschließend mit einem speziellen Auflicht-Kolorimeter ausgemessen. Bei der Profilerstellung für Bildschirme wird zuerst der Screen kalibriert (in einen Normzustand gebracht, was Farbtemperatur, Helligkeit etc. angeht) und anschließend mit einem Kolorimeter, welches auf den Bildschirm gesetzt wird, durchgemessen, während die (beim Kolorimeter mitgelieferte) Software unterschiedliche Farben darstellt. Das erstellte Profil wird als Standard-Monitorprofil abgelegt und beim Start des Computers/Users immer geladen. Ein kalibrierter/profilierter Monitor sollte neutrale Graustufen und möglichst originalgetreue Farben darstellen, u.a. werden vorhandene Farbstiche korrigiert. Vor allem aber weiß das System jetzt, wie der Bildschirm Farben darstellt, um z.B. Bilder daran anzupassen. Programme, die Farbmanagement verwenden, können das erstellte Profil vom CMS verwenden lassen, um Bilder für den Screen zu optimieren. Insbesondere Digitalkameras speichern in den Fotos das Quellprofil ab, sodass dann das Farbmanagement in Kombination mit dem Monitor-Profil berechnen kann, wie die Farben möglichst optimal dargestellt werden können. (Es gibt auch sehr teure, hardwarekalibrierbare Monitore für den PrePress-Bereich, sowas wird hier aber wohl kaum jemand einsetzen)

    Ich habe meine Bildschirme übrigens mit dem Spyder3 Pro kalibriert/profiliert, schalte aber manchmal auch auf die Werks-Profile um, um zu gucken, wie andere meine Ergebnisse evtl. sehen könnten.

    Zumindest wenn ihr am Ende Mittelwerte verwenden wollt (Mittel worueber? RGB? YUV?)
    muss man ja die Streuung mit angeben. Mal angenommen die Haelfte testet an S/W-Fernsehern und die andere in Farbe.


    Bisher kam niemand auf das schmale Brett, für unser Projekt den C64 an einen S/W-Fernseher zu hängen. ;) Die Durchschnittswerte der Farben berechnen wir in dem Farbraum, der dafür am Besten geeignet ist: LAB.

    Im Web ist das kein Problem: Zum einen unterstützen die gängigen Bildformate (JPEG und PNG) Farbprofile, zum anderen gilt da die Regel: "Was kein Profil spezifiziert ist als sRGB anzunehmen"


    Bei C64-Grafiken kommt ja auch noch öfters GIF zum Einsatz und das beherrscht keine Profileinbettung. Das ist aber gar nicht so schlimm, denn, wie du schon sagst, wird heutzutage sRGB angenommen, wenn sonst nichts vorhanden ist. Die CoCo Palette wird über die gängigen Verfahren aus dem LAB-Raum zu sRGB gewandelt und wenn man im Grafikprogramm als RGB-Arbeitsfarbraum sRGB einstellt, dann sollte es beim Export (egal in welches Format) keine Farbabweichungen geben (bzw. höchsten mal einen um 1 veränderten 8-Bit-Wert (z.B. 234 statt 235), das ist vernachlässigbar). Ich habe ein Testbild in 9 verschiedenen Formaten/Exporteinstellungen (GIF/JPEG/PNG, Speichern/Webexport mit und ohne Colormanagement) aus Photoshop abgespeichert und alle Bilder auf einer Webseite dargestellt und dann mit einem systemeigenen Tool (Digitalcolor Meter) durchgemessen.

    Meine kleine Testreihe hat übrigens ergeben, dass Photoshop bei GIF natürlich nie, bei PNG nur bei der normalen Speicher-Funktion (dort aber nicht deaktivierbar), nicht aber beim Web-Export – und bei JPG auf Wunsch (im normalen Speichern-Dialog) Profile einbettet, beim Webexport aber wiederum nicht. Die Bilder habe ich mit "GraphicsConverter" daraufhin getestet, ob Profile enthalten sind oder nicht.

    In den drei getesteten Browsern (Safari, Chrome, Firefox) werden alle Bilder auf der Seite zueinander nahezu identisch wiedergegeben. Firefox und Chrome passen offensichtlich die Darstellung zusätzlich an das Monitorprofil an – mess- und dezent sichtbar (letzteres bei mir eigentlich nur beim Dunkelblau), wenn ich die Webseite von einem Monitor auf einen anderen verschiebe, Safari tut das nicht. IE-Messungen muss ich auslassen, weil ich Windows nur in VMs laufen habe und ich nicht genau sagen kann, inwieweit sich das Wirtssystem bei der Darstellung einmischt.

    [edit:] Wir haben jetzt die Version 1.2 der Bitte melde dich an, um diesen Link zu sehen.

    Muss der C64 direkt am Röhrenmonitor angeschlossen sein oder darf ich auch den Umweg Framemeister->DVDO Edge->SDI-Konverter->Monitor nehmen? ;)


    Klingt gruselig – aber wenn es funktioniert und ein brauchbares Bild liefert – warum nicht.

    Danke übrigens für deine Mühe, ein Profil zu erzeugen. Weicht nicht so weit von der anderen ab, wie ich wegen des Wide-Gammut Screens befürchtet hatte – sieht gut aus.

    Dann finde ich den Namen 'Community Colors' aber ein wenig naja, irrefuehrend
    VON aber nicht fuer? Aber wenn das 'work in progress' ist, ok.


    Wie du schon richtig sagst, ist das WIP. Die Palette ist nicht geheim – wer sie haben will, bekommt sie (oder holt sie sich einfach aus einem meiner Mockup-Screens). Sobald ich mit der Profilanzahl zufrieden bin, wird die Palette in Version 1.2 offiziell veröffentlicht, versprochen.

    wie passt das zu: ...


    Es geht darum, die Farben, die man von seinem alten C64 so kennt, auf die aktuelle Hardware zu bringen. Deshalb halte ich es für sinnvoll, beim C64 eine möglichst originalgetreue Konfiguration zu verwenden. Und wenn die nicht mehr da ist, dann eben die Konfiguration, die man im Einsatz hat. Hier zählt vor allem: Die Mischung macht's. Wenn jetzt aber jeder Testteilnehmer seinen C64 an irgendwelche modernen 50"-LED-TVs anschließt, dann wird das Ergebnis evtl. verfälscht. Wie gesagt, "verboten" ist das aber nicht.

    Wieso denn nicht? Ich faende es bedauerlich wenn man im 'Namen der Community' zum Mitmachen anregt und dann alles rein intern verarbeiten wuerde...


    Wir wollen nur vermeiden, dass das Ganze am Ende zu kompliziert aussieht. Wenn gewünscht, werden wir auch gerne die Abweichungen veröffentlichen. Wir haben bei der Ermittlung der Mittelwerte in seltenen Fällen damit zu kämpfen, dass einzelne Farben innerhalb einer Palette klar (versehentlich) falsch gesetzt wurden – z.B. blau, wo rot "gefordert" ist. Obwohl diese Problem-Farbfelder insgesamt nicht in Gewicht fallen würden, blende ich sie bei der Durchschnittsberechnung manuell aus – da eindeutig fehlerhaft und voraussichtlich nicht vom Nutzer gewollt (wenn alle anderen Farben, wie erwartet gesetzt werden, können wir z.B. eine Farbenschwäche mit großer Wahrscheinlichkeit ausschließen). Möchtest du trotzdem diese einzelnen Extrem-Ausreißer in die Abweichung eingerechnet haben oder nur die, die wirklich zur Berechnung berücksichtigt werden?

    Damit meinte ich weniger die Startfarben als das sofort ins Auge fallende Problem, dass das Java-Applet "rohe" Farbwerte auf den Monitor gibt. [...] Zumindest unter Windows ist das nicht die Ausnahme, sondern die Regel.


    Oh, recht rückständig, oder? Unter OSX muss man sich quasi dagegen wehren, Farbmanagement zu bekommen, wenn ich das richtig gelesen habe. Allerdings weiß ich nicht, wie sich da Java verhält, da es ja wirklich nur sehr rudimentär Systemaufrufe verwendet. Und dann gibt es ja auch noch das Problem, dass Farbprofile in manche Bildformate eingebettet werden können, in andere nicht und dass bestimmte Programme diese dann auswerten oder eben nicht. All das ist in den letzten Jahren eher schwieriger geworden statt einfacher. Vielleicht ermöglicht einem aber auch die geschickte Wahl der Dateiformate ein gezieltes "Austricksen" des Farbmanagements. Ich werde evtl. mal versuchen, ein kleines Merkblatt zu veröffentlichen, dass diesen ganzen Problembereich etwas beleuchtet. Vielleicht magst du mir dabei helfen?


    Diskussionen zum Thema sind natürlich sehr willkommen aber wenn ich mir hier schon die Finger "wundschreibe", wäre ich froh, dafür dann auch ein paar neue Profile zu bekommen. Nehmen denn auch die hier postenden Kritiker (ungeachtet ihre Einwände) an unserem Projekt teil? Dafür wäre ich wirklich dankbar.

    Wo gibt es die Palette denn?


    In diversen Bildern, die ich hier im Forum gepostet habe. Und auf Anfrage habe ich sie schon einigen Leuten zugeschickt. Bevor ich eine offizielle Veröffentlichung wage, möchte ich gerne noch ein paar aktuelle Profile einsammeln, da die Mehrheit der Paletten vor rund 8 Jahren erstellt wurden und sich seitdem die PC-Hardware wieder weiterentwickelt hat. Der Anteil der Notebooks hat gravierend zugenommen, Apple hat die Gammakorrektur der von Windows angepasst etc. Wenn wir jetzt noch 4 oder 5 weitere Profile bekommen, generieren wir eine neue Palette und die veröffentliche ich dann auch hier.

    Mich wuerde sehr interessieren wie weit die Angaben streuen pro Farbe - das waere wirklich spannend :wink:


    Mal gucken, ob wir diese Werte auch veröffentlichen. Es ist aber teilweise erstaunlich, wie nah sich manche Paletten sind. Das hatte ich gar nicht erwartet. Es gibt aber teilweise bei manchen Farben kräftige Unterschiede, die sich dann aber über die Mittelung wirklich gut ins Gesamt-Bild einfügen. Außer der blassen Pepto-Palette gibt es keine, die optisch so gute Abstufungen innerhalb der Farben und Übergänge vorweisen kann. Das wird u.a. dadurch erzielt, dass in unserem Testbild viele Kombinationen vorkommen, also Farbflächen auf unterschiedlichen Hintergründen, Bilder mit Farbverläufen etc. Man darf halt die Farben nicht allein stehend betrachten, sondern muss das immer im Vergleich zu den anderen tun.

    Wieso sollen die Probanden eigentlich einen 'echten CRT' benutzen? Ist es nicht zweckmaessiger wenn sie das System angeben welches sie auch verwenden?


    Gut, darüber könnte man streiten. Ich persönlich möchte lieber die Farben ermitteln, die die "damaligen" C64-Konfigurationen dargestellt haben und für deren Darstellungen auch die Mehrheit der "alten" Spiele und Bilder erstellt wurden. Dafür braucht es dann "Original"-Hardware. Wenn nichts anderes zur Verfügung steht, kann man aber auch gerne mit einem TFT am C64 teilnehmen. Nur wenn ich sehe, was einige Forumsmitglieder sich so Bildschirmmäßig antun (ich denke da an die Darstellungsprobleme von Paralax' TV-Screen, der Vernunfti fast aus der Bahn geworfen hat), bin ich etwas skeptisch, was die Darstellungsqualität und "Originalität" von TFTs an alter Hardware angeht. Aber wie gesagt, wenn nichts anderes da ist ... (dann aber bitte besser ins Kommentarfeld schreiben, was für ein Screen-Exote da verwendet wurde).

    Ohje, wollt ihr das nicht mal auf Javascript+Canvas oder so umbauen?


    Sicherlich würden wir das heute anders machen, HTML5 lässt grüßen. Aber vor 8 Jahren schmissen die Betriebssysteme noch nicht so viele Warnungen etc. sodass man das Applet einfach (nach einer einzigen Bestätigung) starten konnte. Leider hat sich das geändert aber für 5 weitere Profile (oder so) wird ALeX das Programm leider nicht mehr umbauen wollen. Deshalb bitte ich alle Nutzer moderner Betriebssysteme, über diese Hürden hinwegzusehen und sich da gegebenenfalls durchzukämpfen. Es tut mir wirklich leid und ich bin damit auch unzufrieden – aber wie gesagt: Nur noch ein paar Profile und wir generieren eine neue Palette.

    Als das Ding dann endlich lief fragte ich mich sofort, ob das ganze so überhaupt so richtig sinnvoll sein kann, denn mich strahlte ein sehr kräftiges Grün an


    Wir haben absichtlich die Start-Farben im Applet verdreht, damit zu "faule" Nutzer nicht auf die Idee kommen, zu sagen: Passt schon, ich lasse das einfach mal so. Man muss quasi jede Farbe (außer evtl. den über die Helligkeit gekoppelten Grautönen) anfassen, um zu einem passenden Ergebnis zu kommen.

    Obwohl auf dem System hier Farbmanagement konfiguriert ist scheint Java das komplett zu ignorieren und liefert daher auf dem Wide-Gamut-Monitor hier sehr "poppige" Farben, die nichts damit zu tun haben wie normale Bilder im Browser angezeigt werden. Soll das wirklich so?


    Sollte Java tatsächlich, als Ausnahme zu allen anderen Programmen, das Farbmanagement des Systems nicht unterstützen, so soll das wirklich nicht sein. Allerdings sind Wide-Gammut-Screens "glücklicherweise" in der Unterzahl, sodass ein einzelnes Profil von so einem System uns nicht ins Kreuz schlägt. Daher bitte ich dich, trotz der Bedenken ein Profil mit unserem Testbild zu erstellen (gegebenenfalls mit einen Hinweis auf die vermutete Wide-Gammut/Color-Management-Problematik im Kommentarfeld). Wir sehen dann ja in unserer Übersicht, ob dein System einen überraschenden Ausreißer darstellt. Und wir werden mal überprüfen, ob sich Java-Applets wirklich anders als Browser bei der Farbdarstellung verhalten.

    Spektrometer auf den Röhrenmonitor halten und 16 Farben ausmessen scheint mir gerade einfacher zu sein


    Nein, denn erstens hast du dann nur EINE Röhre ausgemessen und zweitens hast du damit den PC-Faktor ausgeschlossen. Wenn ich mir hier so angucke, wie unterschiedlich RGB-Wert auf unterschiedlichen TFTs dargestellt werden und wie sich die Darstellung nach einer Kalibrierung ändert, sollte man auf auf diese Hälfte der Farb-Ermittlung nicht verzichten. Auf die Idee mit dem Ausmessen kamen, meine ich, auch schon Andere. Und deren Paletten waren kaum besser als das, was vorher über einzelne optische Vergleiche erzielt wurde. Wenn es so einfach wäre, hätten wir schon seit Jahren eine taugliche Farbpalette.

    Ich weiß, dass man unterschiedlicher Meinung sein kann, was unsere Methodik angeht und es war ja auch als Experiment mit offenem Ausgang gedacht. Aber ich war schon nach wenigen erstellten Profilen extrem überrascht von die Qualität der entstandenen RGB-Farbpalette. Ich konnte damit deutlich besser im Grafikprogramm die Wirkung des endgültigen Bildes auf dem C64 simulieren, als es je zuvor möglich war. Natürlich kann man mit einer einzigen Palette nicht die Farbdarstellungsfehler (bzw. Charakteristiken) der Zielsysteme ausgleichen, aber dank der Community Colors Palette ist man mit jedem Screen halt "gleich weit" weg von bzw. so nah dran wie (ohne spezielle Anpassung des Systems) möglich an der "Wahrheit".

    Ich habe aber leider feststellen müssen, dass unser Java-Applet nach einem Server-Umzug nicht mehr richtig funktioniert.


    Das stimmt gar nicht. Nach Rücksprache mit ALeX stellte sich heraus, dass Unser Applet zur empirischen Ermittlung von RGB-Äquivalenten zu den C64-Farben tatsächlich auch nach dem Server-Umzug immer funktioniert hat und die Fehlermeldung am Ende der Prozedur lediglich erscheint, weil der alte Mail-Server nicht gefunden wird. Man bekommt also z.Z. keine automatische Mail, falls man eine Mailadresse hinterlassen hat – ansonsten funktioniert das Programm und speichert auch die entstandene Farbpalette auf unserem Server ab.

    Also bitte ich hier alle, die sich für eine gute Farbpalette (zur Nutzung z.B. in Grafikprogrammen und für Screenshots/Mockups und vielleicht auch Emulatoren) interessieren, an dem Community Colors Projekt teilzunehmen.

    Wer sich für die Hintergründe etwas mehr interessiert, kann in diesem (leider unvollständigen) Bitte melde dich an, um diesen Link zu sehen. nachlesen, warum es dieses Projekt und Applet überhaupt gibt. Und Bitte melde dich an, um diesen Link zu sehen..

    Bitte melde dich an, um diesen Anhang zu sehen.

    Kurz: Man lädt ein selbst-startendes Koala-Bild (PRG-Datei) auf dem echten C64 und startet dann das verlinkte Java-Applet auf dem PC (das sollte unter Windows, Mac OS X und Linux funktionieren). Dort regelt man mit den dargestellten Reglern die Farben so nach, bis sie möglichst identisch zu den Farben aussehen, die man auf dem C64-Screen sieht. Keine Angst: Es wird an der grundsätzlichen Farbdarstellung eures Computers nichts geändert (der Bildschirm wird nicht kalibriert), sondern nur eine Palette ermittelt. Wenn man noch ein wenig Zeit hat, kann man die Fragen am rechten Rand des Screens beantworten (ist aber kein Muss) und schickt dann die Farbpalette mit dem "Absenden"-Button auf unseren Server.

    Wichtig: Bitte nur einen echten C64 (oder C128 oder SX64) verwenden, keinen Emulator – und möglichst einen richtigen Röhrenmonitor/TV (am C64) verwenden, wie sie früher zum Einsatz kamen, keinen Flat-TV, LCD-Monitor o.ä. Letztere können die Farben stark verfälschen. Am PC nutzt man am Besten den Screen, den man sonst auch vorwiegend verwendet, bei mir ist das z.B. der eingebaute Screen meines Notebooks.

    Die daraus bisher entstandene Palette (aktuell ist Version 1.1) verwenden wir in unserem Grafikkonverter Gracon, in dem Koala-Anzeige-Quicklook-Plugin (Mac OS X), in Photoshop (für meine ganzen Pixeleien an Monster Buster, Space Lords etc.) und auch in fast allen Screenshots (z.B. hier im Forum und auf der CSDB). Wir werden uns auch bemühen, die Palette so aufzubereiten, dass man sie in VICE verwenden kann. In VICE wird (bei eingeschalter CRT-Emulation) an der Farbpalette "herumgedreht", weswegen die "Eingangspalette" nicht unbedingt die "Ausgangspalette" sein muss. Dazu kommt, dass nicht alle VICE-Ports wirklich identisch bei der Ausgabe zu arbeiten scheinen, sodass wir auch da erst noch Tests durchführen müssen.

    Vielen Dank für den Fall, dass ihr teilnehmt. Je mehr das tun, desto besser wird die Farbpalette.

    Sowas ist auch immer schwer zu vergleichen, je nach CRT oder TFT sieht ein C64 Schirm anders aus und auch jeder TFT am PC hat leicht andere Farben.


    Das ist der Grund, weswegen wir unser Community Colors Projekt gestartet haben.

    Angeregt von der ewigen Farbdiskussion, mal eine rein subjektive Umfrage. Bitte vergleicht mal die Ausgabe eines echten VICII mit der von VICE.


    Statt jetzt wieder neue, inkompatible Farbtabellen zu erzeugen, wäre es sicherlich sinnvoller, deinen Eindruck bei uns ins System einzufügen. Ich habe aber leider feststellen müssen, dass unser Java-Applet nach einem Server-Umzug nicht mehr richtig funktioniert. Das habe ich ALeX aber eben mitgeteilt, sodass hier Hoffnung auf schnelle Besserung besteht. Ich teile hier sofort mit, wenn das CoCo-Applet wieder läuft – dann könnt ihr einen Abgleich zwischen der C64-Darstellung und eurem PC-Bildschirm durchführen.

    Ich halte Vice fuer das Optimum.


    "Optimum" fände ich übertrieben. Mein C64 Bild sieht in einigen Belangen anders aus als das, was VICE so treibt. Aber die Darstellung ist bei eingeschalteter CRT-Emu allmählig "recht brauchbar" (das war vor ein paar Jahren noch anders). Das Problem ist aber, das hier die Pepto-Farb-Palette kräftig getweakt wird. Und wenn ich z.B. in Photoshop arbeite (oder Mockup-Screens im Internet veröffentliche), habe ich da keine CRT-Emulation, die an den Farben herumdrehen kann. Da brauche ich eine Palette, die out-of-the-box brauchbare Farben enthält. Deshalb unser CoCo-Projekt.