HDR Profilierung & Helligkeit anpassen

[klampf]

@Tomislav2007
Er meinte, dass er sich noch nicht entschieden hat, ob er in HDR ode SDR dauerhaft sein.

Mit "er kann an HDR nichs ändern" meinte er man kann da derzeit nichts kalibrieren unter Windows mit einem Colorimeter soweit wir wissen.

Die ACM Probleme sind in SDR und SDR in HDR ist ihm wohl zu unbunt.

btw. Hatte hier Messungen drin zu meinem Asus und auch SDR in HDR:
https://www.computerbase.de/forum/t...n-3-kommt-auf-den-markt.2184310/post-29341600

 

[Darkman.X]

Was für ein Chaos hier. 🤭Aber grundsätzlich sehe ich es so wie "Tomislav2007".

Wenn Native + ACM übersättigte Farben hat, dann gehe ich davon aus, dass der Monitor keine Werkskalibrierung und/oder fehlerhafte EDID-Informationen hat.

 

[Boerny]

Also noch einmal, es wäre schön wenn du dich nicht weiter vor der Frage drückst und anwortest:
Betreibst du deinen Monitor jetzt bei SDR Kontent im HDR Modus oder nicht ? Ja oder Nein, mit Annahmen kommen wir nicht weiter

Nein, der Monitor wird NIEMALS im HDR Modus betrieben.

Ergänzung (26. Oktober 2025)

Er meinte, dass er sich noch nicht entschieden hat, ob er in HDR ode SDR dauerhaft sein.

Einmal das, und die Tatsache das es komplett egal ist, ob ich manchmal HDR anhabe oder nicht. Das Problem tritt ja trotzdem auf, immer wenn HDR deaktiviert ist. Aber egal ich tun jetzt einfach so als würde HDR immer aus sein damit es nicht weiter zu "Missverständnissen" kommt.

Ergänzung (26. Oktober 2025)

Wenn Native + ACM übersättigte Farben hat, dann gehe ich davon aus, dass der Monitor keine Werkskalibrierung und/oder fehlerhafte EDID-Informationen hat.

Werkskalibrierung hat er, fehlerhafte EDID-Info kann gut sein. Wenn ich weiß, wonach ich suchen soll, guck ich gerne rein, mit CRU oder was Ähnlichem

Ergänzung (26. Oktober 2025)

HDR bleibt also bis auf weiteres deaktiviert, wenn nicht explizit anders von ihm erwähnt

Danke! Ich habe wirklich angefangen zu zweifeln, ob ich mich komplett unverständlich ausdrücke.

Ergänzung (27. Oktober 2025)

Mein Zweitmonitor hat auch einen minimal größeren sRGB Farbraum, und hier verhält es sich richtig, AMC reduziert die Sättigung.

Das würde ja für falsche EDID-Informationen bei dem AOC sprechen.

 

[Suspektan]

Werkskalibrierung hat er, fehlerhafte EDID-Info kann gut sein. Wenn ich weiß, wonach ich suchen soll, guck ich gerne rein, mit CRU oder was Ähnlichem

...

Dürfte sich um die display x,y chromaticity Parameter handeln, k.A., ob die überschreibbar sind bzw. Änderungen übernommen werden.

https://github.com/ledoge/novideo_srgb/issues/10

 

[klampf]

Ich habe jetzt mal bei mir mit dem ACM getestet.
Habe einen Monitor mit erweitertem Farbraum und ACM aktiviert, macht alles unbunter.
Also wie erwartet, man kann an genau der Ecke auch SDR und HDR Proflle getrennt eingeben.
Es scheint aber tatsächlich nicht so als würde ACM auf das eingestellt Profil achten, egal was ich da setze, es ändert sich nichts in der Darstellung.

 

[Suspektan]

Es scheint aber tatsächlich nicht so als würde ACM auf das eingestellt Profil achten, egal was ich da setze, es ändert sich nichts in der Darstellung

Ja, das ist auch die Kritik an ACM, das erstellte Profil wird nicht berücksichtigt, nur die im EDID des Monitors hinterlegten RGB primaries.
Man kann also nicht in Kombination mit ACM eine windowsseitige Farbkalibrierung inkl. LUT -Erstellung durchführen, displaycal ist damit außen vor.

 

[Boerny]

Und wenn die EDID des Monitors schlecht sind, macht es richtig viel Spaß ¯\(ツ)/¯
Zumindest ist das bisher die plausibelste Erklärung

 

[Suspektan]

Erstmal müsstest du die RGB primaries bzw. x y chromaticity Werte auslesen und dann jemanden finden, der dir Auskunft dazu geben kann.

Was für eine GPU wird denn genutzt?

 

[klampf]

Ich wollt es ausprobieren mi9t ACM weil es schien mir nicht so, als wenn das völlig klar wäre.
Traue Microsoft auch zu, das eben mal schnell zu ändern. Das ganze ACM tauchte ja auch eher unerwartet auf

btw. Es gibt das .icc Profil des Herstellers des hier diskutierten Monitors zum Download.
Der Farbraum, den das skizziert sieht etwas seltsam aus und ist kaum größer als sRGB.

Und noch was. DisplayCal kann ein .icc aus dem EDID erzeugen.
Damit könnte @Boerny das mal relativ einfach checken.

Der Profil-info von DisplayCal kann auch visualisieren.
Das gestrichelte ist sRGB.
Mein gemessener Farbraum:

Das liefert Asus mit und das aus dem EDID erzeugte, sieht in diesem Plot identisch aus

Und so sieht das von der AOC Webseite runtergeladene aus:

Das hat ne seltsame rot Ecke, ist aber fast sRGB.

 

[Suspektan]

Und so sieht das vom AOC aus:

eine Übersättigung ggü. ACM aus dürfte sich daraus aber dennoch nicht ergeben

Das novideo_sRGB Tool soll ebenfalls die EDID Infos zur Farbraumkonvertierung berücksichtigen, ich würde ggfls. mal damit gegenprüfen.
Wenn novideo_sRGB die gleiche Übersättigung zeigt, dürfte die fehlerhafte EDID als Grund gesichert sein.
Mit einer amd GPU benötigt man kein zusätzliches Tool, sondern braucht lediglich die "Farbtemperaturregelung" zu deaktivieren für den Gamut Clamp.

 

[klampf]

@Suspektan

eine Übersättigung ggü. ACM aus dürfte sich daraus aber dennoch nicht ergeben

Das stimmt.

Das sind die Daten aus dem erzeugten Prpril für meinen Asus.
Sind da die Farbewrte fürs EDID mit drin?
Mal so als Test???
QD-OLEDs sind ja beide.

Wie jubelt man Windows das EDID unter?

 Größe    2552 Bytes (2.49 KiB)
 Bevorzugtes CMM    0x6172676C 'argl' ArgyllCMS
 ICC-Version    2.2
 Profilklasse    Anzeigegeräteprofil
 Farbmodell    RGB
 Bezugsfarbraum (PCS)    XYZ
 Erstellt    2025-10-27 21:23:10
 Plattform    Microsoft
 Ist eingebettet    Nein
 Kann unabhängig verwendet werden    Ja
 Gerät  
     Hersteller    0x0000B306 ASUSTek COMPUTER INC
     Modell    0x000032F2
     Medien-Attribute    Reflective, Glossy, Positive, Color
 Standard-Farbübertragung    Wahrnehmung
 PCS-Leuchtmittel XYZ    96.42 100.00  82.49 (xy 0.3457 0.3585, CCT 5000K)
 Ersteller    0x4443414C 'DCAL' DisplayCAL
 Prüfsumme    0x2D91E1FB5F20BF889F2BA68D8AC57B2B
     Prüfsumme OK    Ja
 Beschreibung (ASCII)    PG32UCDM
 Urheberrecht    Created from EDID
 Gerätehersteller (ASCII)    ASUSTek COMPUTER INC
 Gerätemodell (ASCII)    PG32UCDM
 Gerätehersteller und Modell  
     Hersteller    0x06B3 ASUSTek COMPUTER INC
     Modell    0x32F2
 Medien-Weißpunkt  
     Ist Leuchtmittel    Ja
     Leuchtmittel-Bezug XYZ    95.25 100.00 108.61 (xy 0.3135 0.3291)
     Leuchtmittel-Bezug CCT    6460K
         ΔE 2000 zu Tageslicht-Farbort    0.64
         ΔE 2000 zu Schwarzkörper-Farbort    4.13
 Absolute to media relative transform    Bradford (ICC-Empfehlung)
     Matrix    0.8951 0.2664 -0.1614
             -0.7502 1.7135 0.0367
             0.0389 -0.0685 1.0296
 Chromatizität (Leuchtmittel-Bezug)  
     Kanal 1 (R) xy    0.6836 0.3047
     Kanal 2 (G) xy    0.2441 0.7090
     Kanal 3 (B) xy    0.1436 0.0557
 Roter Matrix-Farbwert  
     Leuchtmittel-Bezug XYZ    52.92  23.59   0.91 (xy 0.6836 0.3047)
     PCS-Bezug XYZ    55.81  24.85   0.55 (xy 0.6872 0.3060)
 Rote Farbtonwiedergabekurve    Gamma 2.2
 Grüner Matrix-Farbwert  
     Leuchtmittel-Bezug XYZ    23.84  69.24   4.58 (xy 0.2441 0.7090)
     PCS-Bezug XYZ    26.22  69.25   4.27 (xy 0.2629 0.6943)
 Grüne Farbtonwiedergabekurve    Gamma 2.2
 Blauer Matrix-Farbwert  
     Leuchtmittel-Bezug XYZ    18.49   7.17 103.12 (xy 0.1436 0.0557)
     PCS-Bezug XYZ    14.39   5.90  77.66 (xy 0.1469 0.0602)
 Blaue Farbtonwiedergabekurve    Gamma 2.2
 Metadaten  
     prefix    EDID_
     DATA_
     OPENICC_
     GAMUT_
     MAPPING_
     EDID_mnft    AUS
     EDID_mnft_id    1715
     EDID_model_id    13042
     EDID_date    2024-T9
     EDID_red_x    0.68359375
     EDID_red_y    0.3046875
     EDID_green_x    0.244140625
     EDID_green_y    0.708984375
     EDID_blue_x    0.1435546875
     EDID_blue_y    0.0556640625
     EDID_white_x    0.3134765625
     EDID_white_y    0.3291015625
     EDID_manufacturer    ASUSTek COMPUTER INC
     EDID_gamma    2.2
     EDID_model    PG32UCDM
     EDID_serial    S2LMQS099123
     EDID_md5    6b6b35430af915330b5532440297a6fc
     OPENICC_automatic_generated    1
     DATA_source    edid
     GAMUT_volume    1.61731198833
     GAMUT_coverage(dci-p3)    0.977
     GAMUT_coverage(srgb)    1.0001
     GAMUT_coverage(adobe-rgb)    0.9432
     Lizenz    Public Domain
     MAPPING_device_id    xrandr-ASUSTek COMPUTER INC-PG32UCDM-S2LMQS099123

Ergänzung (27. Oktober 2025)

Das vermutlich??
EDID_red_x 0.68359375
EDID_red_y 0.3046875
EDID_green_x 0.244140625
EDID_green_y 0.708984375
EDID_blue_x 0.1435546875
EDID_blue_y 0.0556640625
EDID_white_x 0.3134765625
EDID_white_y 0.3291015625

 

[Suspektan]

würde ich annehmen
ansonsten mal im displaycal Forum nachfragen, man ist dort m:E.n. sehr hifsbereit

Ob sich die EDID Daten aber mit CRU überschreiben lassen, bleibt die Frage
https://github.com/ledoge/novideo_srgb/issues/10

 

[Boerny]

Sorry, ich hatte gestern etwas viel zu tun.

@klampf im Anhang meine Profile, links im Nativen, rechts im sRGB Modus. Die EDID-Info vom Hersteller passt somit nicht. Wenn ich mich richtig erinnere, hatte Prad in Ihrem Test auch eine höhere sRGB-Abdeckung als vom Hersteller angegeben gemessen. Was aber nicht meine Probleme erklärt, wie Ihr ja bereits angemerkt habt.

Ob sich die EDID Daten aber mit CRU überschreiben lassen, bleibt die Frage

Ich habe es noch nicht versucht, aber meine gelesen zu haben, dass es nicht funktioniert, da Windows die Daten direkt vom Monitor abgreift und CRU in diesen Prozess nicht eingreifen kann. Leider finde ich den Beitrag nicht mehr, kann also auch sein, dass ich mich irre.

Ergänzung (29. Oktober 2025)

Angeblich kann ACM auch Profile verwenden, jedoch darf es dafür kein .ICC sein, sondern muss im MHC2 Format sein.

Advanced Color normally relies on EDID information for things like output primaries, HDR tonemapping, etc. The MHC2 profiles just override the EDID information.


The main thing you’d fix with a custom MHC2 profile is being able to correct for primaries, white point, or EOTF in the display not quite matching the target the display claims to have in its EDID. Much the same way you would with ICC calibration data in the old system

Ich lese mich gerade noch ein, aber es scheint Wege zu geben, um so ein Profil zu erstellen. https://github.com/dantmnf/MHC2

 

[Suspektan]

@klampf im Anhang meine Profile, links im Nativen, rechts im sRGB Modus. Die EDID-Info vom Hersteller passt somit nicht.

Welche GPU nutzt du?
Falls es die AMD GPU ist, teste doch einfach mal den Tipp aus Beitrag 70 (natürlich mit ACM: aus)
https://www.computerbase.de/forum/threads/hdr-profilierung-helligkeit-anpassen.2255845/post-31028837

Das soll sich quasi identisch zu ACM verhalten, da ebenso auf die EDID zurückgegriffen wird.
Wenn hier die gleiche Problematik auftritt, dürfte man die EDID Information als gesichert falsch annehmen können.

 

[klampf]

MHC2 kannte ich auch noch nicht ...

 

[Suspektan]

War vor Einführung von ACM auch eigentlich nicht notwendig?
Ist ja noch recht frisch

Ich kann jetzt aus Boerny'S Screenshot nicht die entscheidenden red/ green/blue x,y EDID Informationen herauslesen, evtl. könnte man diese direkt mit den von klampf geposteten Werten vergleichen.

 

[Boerny]

alls es die AMD GPU ist, teste doch einfach mal den Tipp aus Beitrag 70 (natürlich mit ACM: aus)

Ja, ist eine AMD GPU, somit dürfte no_srgb nicht funktionieren, oder? Über den Treiber auf sRGB clampen kann ich, jedoch verrät uns das nichts über die EDID. Oder hast du einen anderen Gedanken gehabt?

 

[klampf]

Benimmt sich das genauso wie ACM, wenn Du es im Treiber machst?
Also führt dqs auch zur Übersättigung
Das war, was wir uns fragten.

 

[Boerny]

Ah okay. Wenn ich den Monitor im Native-Modus habe und dann über den Treiber auf sRGB clampe werden die Farben etwas entsättigt, jedoch bei weitem nicht so stark wie im sRGB Modus.
Auf einer Skala von 1 (farblos) über 5 (normal) bis 10 (übersättigt) würde ich sagen:
Native 10
Native + Treiber clamp 8
sRGB 5

Der sRGB Modus sollte an sich recht nah am Richtigen dran sein, zumindest dem Profil von oben (Screenshot) nach zu urteilen.