Color Management in Resolve

[Frank Glencairn]

Jede farbmanagmentfähige Software greift auf die ICC-Profile zurück, die im Betriebssystem hinterlegt sind. Nicht farmmangmentfähige Software machen das nicht.
Resolve macht das eben nicht.

und was ist das hier?

Bildschirmfoto 2021-01-25 um 00.13.47.png

"Das hier" ist eine weitere Krücke (die speziellen Apple Render Einstellung ist die andere), die nötig ist um den geneigten Mac User davon abzuhalten schon wieder einen Post mit dem Titel "Mein gerenderter Clip sieht völlig anders aus als in meiner Vorschau" zu erstellen ;-)

Wie meistens funktioniert da alles, solange man innerhalb des Apple Universums (FCP) bleibt - außerhalb wirds schwieriger.
Tatsächlich ist das CM auf PC/Linux da etwas unproblematischer.

Auf der anderen Seite - seht euch doch mal nen normalen CC Arbeitsplatz an.
Da schaut man hauptsächlich auf den Vorschaumonitor, das UI auf den beiden Monitoren links und rechts davon könnte auch Grau sein - is ja nur ein UI. Nur weil Resolve mittlerweile erträglich auf Laptops läuft und gratis bis saubillig ist, heißt das noch lange nicht daß BM deshalb verpflichtet ist dafür zu sorgen, daß eure Bildschirme jetzt plötzlich auf dem selben Niveau laufen müssen, wie in einer professionellen Suite (die meisten können das schon rein hardware mäßig gar nicht) - und für die YT Zielgruppe ist es auch völlig wurscht, alle anderen haben auch kein Problem sich ne entsprechende I/O hardware Lösung und Monitor zu kaufen, wenn sie bessere Kontrolle brauchen.

Das Anspruchsdenken wie "BM soll gefälligst...." und "die wollen doch nur ihre Hardware verkaufen" (no shit? Seltsamerweise sagt das von FCP keiner) an eine gratis/billig Software die noch vor nicht allzulanger Zeit Zigtausende gekostet hat, und für die meisten hier ein völlig unerreichbarer Traum war, gehen so langsam in Richtung unverschämt.
Ich möchte nicht wissen was hier los wäre, wenn BM für die nächste Version mal nen 1000er aufrufen würde (was immer noch billig und gerechtfertigt wäre).

Apropos Monitor - Hand auf's Herz - wer von euch hat denn überhaupt einen echten 10 Bit Monitor, auf den man die LUT laden kann, und nicht nur einen mit 8Bit + FRC auf dessen Karton trotzdem großkotzig 10 Bit stand, und der auf ein Profil im OS angewiesen ist?

[roki100]

"Das hier" ist eine weitere Krücke (die speziellen Apple Render Einstellung ist die andere), die nötig ist um den geneigten Mac User davon abzuhalten schon wieder einen Post mit dem Titel "Mein gerenderter Clip sieht völlig anders aus als in meiner Vorschau" zu erstellen ;-)

nicht ohne Grund ist bei mir da kein Häkchen gesetzt :) Ich dachte es liegt daran weil ich kein Profi Bildschirm habe und die Funktion sei sowieso nur für die Profis mit Profi Bildschirme relevant.

[klusterdegenerierung]

der Grund warum man immer noch sRGB (im Fotobereich) oder REC709/BT1886 (bei Video) verwendet, ist die Idee des kleinsten gemeinsamen Nenners bei relativ unspezifischen Anwendungen. Bei einem kleinen Farbraum ist sichergestellt, dass er quasi auf jedem System richtig dargestellt werden könnte.

Dieses Wissen ist meiner Frage vorraus gegangen und basiert darauf, das es eben so gut wie keine Gerätre mehr gibt, bzw gebaut werden,
die diese nicht, bzw auch etwas größeren, nicht darstellen können.

Deswegen bin zumindest ich der Meinung, das es an der Zeit ist einen größeren zu etablieren und wenn dann doch noch kleinere in Anwendung sind, dann haben da eben ein paar % mal Pech gehabt, aber Momentan ist es ja genau umgekehrt und die meißten müßen ihre "Bandbreite" auf was kleineres beschränken oder beschneiden.

Das ist in meinen Augen nicht Zeitgemäß, ein Rückschritt zu einem Vortschritt auf der anderen Seite und ganz einfach anachronistisch.

[dienstag_01]

und was ist das hier?

Bildschirmfoto 2021-01-25 um 00.13.47.png

"Das hier" ist eine weitere Krücke (die speziellen Apple Render Einstellung ist die andere), die nötig ist um den geneigten Mac User davon abzuhalten schon wieder einen Post mit dem Titel "Mein gerenderter Clip sieht völlig anders aus als in meiner Vorschau" zu erstellen ;-)

Wie meistens funktioniert da alles, solange man innerhalb des Apple Universums (FCP) bleibt - außerhalb wirds schwieriger.
Tatsächlich ist das CM auf PC/Linux da etwas unproblematischer.

Auf der anderen Seite - seht euch doch mal nen normalen CC Arbeitsplatz an.
Da schaut man hauptsächlich auf den Vorschaumonitor, das UI auf den beiden Monitoren links und rechts davon könnte auch Grau sein - is ja nur ein UI. Nur weil Resolve mittlerweile erträglich auf Laptops läuft und gratis bis saubillig ist, heißt das noch lange nicht daß BM deshalb verpflichtet ist dafür zu sorgen, daß eure Bildschirme jetzt plötzlich auf dem selben Niveau laufen müssen, wie in einer professionellen Suite (die meisten können das schon rein hardware mäßig gar nicht) - und für die YT Zielgruppe ist es auch völlig wurscht, alle anderen haben auch kein Problem sich ne entsprechende I/O hardware Lösung und Monitor zu kaufen, wenn sie bessere Kontrolle brauchen.

Das Anspruchsdenken wie "BM soll gefälligst...." und "die wollen doch nur ihre Hardware verkaufen" (no shit? Seltsamerweise sagt das von FCP keiner) an eine gratis/billig Software die noch vor nicht allzulanger Zeit Zigtausende gekostet hat, und für die meisten hier ein völlig unerreichbarer Traum war, gehen so langsam in Richtung unverschämt.
Ich möchte nicht wissen was hier los wäre, wenn BM für die nächste Version mal nen 1000er aufrufen würde (was immer noch billig und gerechtfertigt wäre).

Apropos Monitor - Hand auf's Herz - wer von euch hat denn überhaupt einen echten 10 Bit Monitor, auf den man die LUT laden kann, und nicht nur einen mit 8Bit + FRC auf dessen Karton trotzdem großkotzig 10 Bit stand, und der auf ein Profil im OS angewiesen ist?

Mit welchem Test unterscheidest du denn 10bit von 8bit+FRC?

[pillepalle]

@ Frank

Klar, die wenigsten hier werden einen Monitor zum Preis eines Mittelklasse Wagens haben :)

Kann ja auch jeder machen wie er will. Sich einen guten Workflow anzueignen und zu versuchen Dinge zu verstehen ist aber trotzdem wichtig. Wenn man irgendwann wirklich mal einen Job mit professionellerem Equipment hat, kann man dann auch wenigstens etwas damit anfangen.

@kluster

Ich sehe schon, Du willst in iasis Fußstapfen treten *g*

@ dienstag

Das steht in den Specs

VG

[dienstag_01]

@ dienstag

Das steht in den Specs

Bei meinen Eizos nicht.
Ausserdem war das nicht meine Frage. Frank macht hier schon wieder einen Unterschied auf, den hätte ich gern irgendwie gesehen.
Wird er ja wohl hinbekommen ;)

[Darth Schneider]

Was ist eigentlich mit den neuen BMD Video Assist Modellen ?
Irgendwo habe ich gelesen die sollen irgend wie nach einer Hollywood Norm, kalibriert sein ?

https://www.blackmagicdesign.com/produc ... ideoassist

Was heisst das, sind das dann auch kleine, echte, bezahlbare Referenz Monitore, oder ist das mehr ein Marketing Gag ?
Gruss Boris

[klusterdegenerierung]

Ich sehe schon, Du willst in iasis Fußstapfen treten *g*

?
Sicher, man kann auch noch ein Wählscheiben Telefon der Post, sowie ein altes Sateliten Telefon mit 24V Akku und Stabantenne benutzen.

[klusterdegenerierung]

@ dienstag

Das steht in den Specs

Bei meinen Eizos nicht.
Ausserdem war das nicht meine Frage. Frank macht hier schon wieder einen Unterschied auf, den hätte ich gern irgendwie gesehen.
Wird er ja wohl hinbekommen ;)

https://www.isolapse.com/true-10-bit-vs ... ifference/

[pillepalle]

Die Eizos (ausser der Prominence) sind auch 8bit+frc. Der Atomos Ninja ist es auch und der BM Viedo Assist vermutlich auch. Aber das ist ja nicht nur ein Marketing Gag, so wie Frank es darstellt. Das macht schon einen Unterschied und manches 8bit Display ist 6bit+frc :)

VG

[klusterdegenerierung]

"If you’re a professional video editor, color editor, photo editor, or any type of content creator that deals with color-critical tasks, you definitely need a true 10-bit monitor instead of an 8-bit + FRC monitor. A monitor with a true 10-bit color depth will display more accurate colors than an 8-bit +FRC monitor. If you’re on a tight budget but want to get a monitor that checks all of your needs as a creator."

[dienstag_01]

Bei meinen Eizos nicht.
Ausserdem war das nicht meine Frage. Frank macht hier schon wieder einen Unterschied auf, den hätte ich gern irgendwie gesehen.
Wird er ja wohl hinbekommen ;)

https://www.isolapse.com/true-10-bit-vs ... ifference/

Ich weiß was FRC ist.
Ich weiß, an welcher Stelle man Informationen bekommt, welche Art Display im Monitor verbaut ist.
Was ich nicht weiß: wie man den Unterschied sichtbar machen kann, wenn es denn geht.

[pillepalle]

Ich weiss auch nicht wie das geht. Sehen wird man das kaum.

VG

[Darth Schneider]

Also wenn ich den Text in der Beschreibung richtig interpretiere kann der BMD Monitor/Recorder zumindest über sdi 10Bit darstellen...Oder gilt das nur für die Aufzeichnung ? Geht das auch über HDMI ?
https://www.digitec.ch/de/s1/product/bl ... r-12097544
Gruss Boris

[pillepalle]

Darstellen können die das alle, der Unterschied ist nur wie sie es erreichen.

VG

[roki100]

@Boris
die BMD Bildschirme sind 10Bit.

[Darth Schneider]

Ab 115 €, (Ultra Studio Monitor 3G plus halt im Fall von einem grösseren Video Assist ein Tausender für den Monitor.;) ?
Wahrscheinlich keine dumme Investition...
https://www.blackmagicdesign.com/products/ultrastudio
Gruss Boris

[mash_gh4]

Die Entwicklung von displaycal und ArgyllCMS ist aber schon seit ca. 2 Jahren tot (und displaycal wird wegen seiner Python 2-Dependency zur Software-Altlast), weswegen sich da nichts neues mehr getan haben dürfte.

ich glaube du überschätzt dieses problem.

die umstellung von python 2 auf 3 betrifft ohnehin fast nur das unicode string handling und ein details im zusammenhang mit der rechengenauigkeit bei divisionen mit verschiedener ausgangsdgfenauigkeit. das meiste von lässt sich sogar automatisch mit mitgelieferten "2to3" erledigen. da muss sich wirklich nur jemand einmal ein paar stunden hinsetzten, obwohl es natürlich alles andere als schöner und einladender code ist, noch immer SVN für die versionsverwaltung verwendet wird etc., oder eben gleich von grund auf etwas besserer und benutzerfreundlicheres schreiben.

dass sich bei ArgyllCMS auch schon länger nur mehr recht wenig tut (letzte version 2.1.2 -- January 2020), ist zwar ein bisserl traurig, aber das war ohnehin schon sehr lange so und stört auch weiter nicht, weil die software ja trotzdem ganz gut funktioniert.

beides halte ich jedenfalls für relativ unproblematisch.

in dem zuammenhang ist es bspw. deutlich komplizierter auf einem debian system decklinkkarten mit freier software nutzen zu könnnen. dass ist nämlich zwar grundsätzlich mit sehr vielen tools durchaus möglich, aber da es die lizenzbedingungen der treiber nicht anders erlauben, ist die entsprechende unterstützung von haus aus in den freien distributionen normalerweise nicht enthalten. man muss also jedes der in frage kommenden programme bzw. die betreffenden libraries selbst anpassen und neu kompilieren, damit diese art der ausgabe genutzt werden kann. ein aufwand, der vermutlich nicht wirklich kleiner ist, als die oben angesprochene adaptionsnöte im zusammenhang mit displaycal, nur dass eh hier wirklich jeder ständig aufs neue auskosten darf. das ist einer der gründe, warum ich in dieser frage derart unnachgiebig gegen jede unnötige zwangsbeglückung wettere.

[mash_gh4]

Ich weiß was FRC ist.
Ich weiß, an welcher Stelle man Informationen bekommt, welche Art Display im Monitor verbaut ist.
Was ich nicht weiß: wie man den Unterschied sichtbar machen kann, wenn es denn geht.

dort wo es tatsächlich sauber umgesetzt ist, macht es ohnehin überhaupt keinen unterschied und erfüllt vielmehr einfach den vorgesehen zweck.

in wahrheit sind die auch oft durchaus erschwinglichen IPS-monitore heute für ein gewissenhaftes arbeiten durchaus akzeptabel. am ehesten würde ich noch probleme mit der anpassbarkeit der bildwiederholrate bemängeln, die leider manchmal im zusammenhang mit unserem einsatzgebiet darstellungsfehler verursachen kann, aber ansonsten gibt's wenig zu klagen.

das entscheidenste ist wirklich die konsequente nutzung eines kolorimeters und guter software, die uns die uns diese prinzipiell vorhandenen technischen möglichkeiten auch tatsächlich vernünftig ausschöpfen lässt.

so kann man durchaus auch mit ganz normalen grafikarten und displayport-ausgabe eine ausreichend korrekte farbwiedergabe realisieren -- zur not auch in 10bit, obwohl es damit leider unter windows und linux bis dato ziemliche probleme bei der integration ins umgebende grafiksystem gibt, so dass man es in der praxis dann oft doch lieber sein lässt...

[klusterdegenerierung]

https://www.isolapse.com/true-10-bit-vs ... ifference/

Ich weiß was FRC ist.
Ich weiß, an welcher Stelle man Informationen bekommt, welche Art Display im Monitor verbaut ist.
Was ich nicht weiß: wie man den Unterschied sichtbar machen kann, wenn es denn geht.

Oh entschuldige, wie konnte ich das übersehen!
Aber wenn Du schon so schlau bist, dann zähle doch eins und eins zusammen, dann wird bestimmt auch Dir klar, das es nur über die framerate zu sehen ist.

Du kannst es also nur sehen, wenn Du die framerate so weit runter bekommst das 8vs10 zwischen den Frames sichtbar wird.
Ich nehme mal an das dies nicht wirklich um zusetzen ist und so könnte es vielleicht für den Konsumer am Ende keinen Unterschied machen,
aber vielleicht für Hardware wie ein Kalibrierer, denn der sieht an ein und der gleichen Stelle ständig unterschiedliche Farbwärte, was das Messergebniss beeinflussen könnte.

[klusterdegenerierung]

so kann man durchaus auch mit ganz normalen grafikarten und displayport-ausgabe eine ausreichend korrekte farbwiedergabe realisieren -- zur not auch in 10bit, obwohl es damit leider unter windows und linux bis dato ziemliche probleme bei der integration ins umgebende grafiksystem gibt, so dass man es in der praxis dann oft doch lieber sein lässt...

Wenn 99% aller Endgeräte eh eine unterschiedliche Darstellung haben, ist es faktisch sowie unmöglich bis nicht erstrebenswert.
Das mit der Integration von 10Bit in Windows verstehe ich nicht ganz, worauf beziehst Du das und welches Win ist gemeint?

[mash_gh4]

der Grund warum man immer noch sRGB (im Fotobereich) oder REC709/BT1886 (bei Video) verwendet, ist die Idee des kleinsten gemeinsamen Nenners bei relativ unspezifischen Anwendungen. Bei einem kleinen Farbraum ist sichergestellt, dass er quasi auf jedem System richtig dargestellt werden könnte.

Dieses Wissen ist meiner Frage vorraus gegangen und basiert darauf, das es eben so gut wie keine Gerätre mehr gibt, bzw gebaut werden,
die diese nicht, bzw auch etwas größeren, nicht darstellen können.

Deswegen bin zumindest ich der Meinung, das es an der Zeit ist einen größeren zu etablieren und wenn dann doch noch kleinere in Anwendung sind, dann haben da eben ein paar % mal Pech gehabt, aber Momentan ist es ja genau umgekehrt und die meisten müssen ihre "Bandbreite" auf was kleineres beschränken oder beschneiden.

Das ist in meinen Augen nicht Zeitgemäß, ein Rückschritt zu einem Fortschritt auf der anderen Seite und ganz einfach anachronistisch.

auf den handys, wo OLED displays mittlerweile ziemlich gebräuchlich sind, hat man auf diese entwicklung bereits zu reagieren begonnen. dort wurde spätestens mit android8 die unterstützung dieser wide gamut funktionalität notwendig, damit die dinger einigermaßen das selbe darstellen, wie die älteren displaytechniken. in der praxis wird's damit aber doch gleich ziemlich kompliziert. man arbeitet plötzlich mit 16bit farbkanälen, extended RGB (das mit fließkomma-werten im bereich 0-1.0 weiterhin kompatibel zum alten sRGB ist, aber eben auch negative werte oder angaben bis gegen 10.0 hinauf zulässt...), und muss neben den konkreten farbwerten auch immer die bezugsräume mit abspeichern bzw. übergeben.

natürlich kann man, so wie es manche hier vorschlagen od. vor augen haben, einfach einen wide gamut schirm an den normalen video-ausgang klemmen, dort ein entsprechendes farbprofil aktivieren und dann noch den anwendungen auf der computerseite einzeln beibringen, dass dort jetzt P3 statt sRGB erwartet wird. ja. im prinzip geht das, aber in der praxis ist es natürlich eine katastrophe, die nicht wirklich vernünftig genutzt werden kann. ohne sauberes farbmanagement kommt man da einfach nicht vom fleck.

[mash_gh4]

Wenn 99% aller Endgeräte eh eine unterschiedliche Darstellung haben, ist es faktisch sowie unmöglich bis nicht erstrebenswert.

ja -- ohne empirische kontrolle, wenigstens mit einen i1Display Pro, wenn man schon seine geräte nicht im regelmäßigen abstand zum falnders scientific service zwcks nachjustierung schickt, geht's einfach nicht! da braucht man sich nichts vormachen. auch die ganzen herstellerseitig angebotenen farbprofile in den gebräuchlicheren luxusmarken sind in dieser hinsicht sehr mit vorsicht zu genießen.

Das mit der Integration von 10Bit in Windows verstehe ich nicht ganz, worauf beziehst Du das und welches Win ist gemeint?

ich kann dir da aus der praxis fast nur über meine erfahrungen unter linux berichten, wo aber sehr vieles ähnlich wie auf windows gehandhabt wird. bisher ist es mir dort noch nicht gelungen, tatsächlich einen 10bit-reinen desktop-arbeitsplatz so zu konfiguren, dass man damit auch im alltag ohne nervenzusammenbrüche arbeiten könnte. es gibt einfach zu viele programe und alte softwarekomponeneten, die damit einfach nicht klar kommen, weil das in diesem umfeld noch immer eine derart exotische vorgabe betrifft. in der praxis bedeutet das, dass manche dinge plötzlich nicht mehr darsgestellt werden oder in bunten
regenbogenfarben schillern. das betrifft ganz besonders die richtig komplexen und auf maximale performance optimierten programme wie bspw. chrom[ium], das ja mitterlweile auch im hintergrund bspw. im vscode u.ä. anwendungen für die tatsächliche ausgabe sorgt. chrome nutzt nämlich für die grafikausgabe ein eigenen mechanismus, der am großteil der gewohnten betriebsystem-grafikinfrastruktur vorbei mehr od. weniger direkt mit den grafikkarten kommuniziert -- ähnlich wie das auch spiele oder eben manche video-player tun. das kann man dem zweug auch nicht abgewöhnen, und die praktischen inkompatibilitäten mit einem 10bit desktop sind kaum zu ertragen.

das ist wirklich einer der punkte, wo man im apple-lager bereits spürbar befriedigendere lösungen vorfindet. dass es natürlich auch dort jede menge ignoranten gibt, die das nicht einmal im ansatz zu vestehen versuchen und bspw. im resolve die entsprechende untersützung mutwillig völlig falsch konfigurieren, ist allerdings leider auch wieder recht charakteristisch für die dortige parallelwelt...

[dienstag_01]

ohne sauberes farbmanagement kommt man da einfach nicht vom fleck.

Aha. Gestern hieß es noch, dass eine Decklink nicht nötig ist.
Nennen wir es mal Erkenntnisgewinn.

[mash_gh4]

ohne sauberes farbmanagement kommt man da einfach nicht vom fleck.

Aha. Gestern hieß es noch, dass eine Decklink nicht nötig ist.
Nennen wir es mal Erkenntnisgewinn.

ich fürchte, du missverstehst mich:

decklink-ausgabe -- bzw. dieser umweg, der nur fürs resolve einigermaßen funktioniert -- repräsentiert vielmehr das gegenteil von befriedigendem systemweitem farbmanagement!

[andieymi]

man muss also z.B. unter Windows mit DisplayCAL&Co. sein Bildschirm Kalibrieren, davon eine LUT generieren und diese immer wieder in Davinci verwendet? https://forum.blackmagicdesign.com/view ... 60#p575225

Keine Ahnung, aber ich habe ein Handbuch ;)
Alternately, you can apply a dedicated Color Viewer LUT for calibration, using
the 1D/3D Color Viewer Lookup Table drop-down menu that’s found in the
Color Management panel of the Project Settings. This lets you analyze your
computer display for calibration in the same way you would calibrate an external
display, using a probe and color management software, and apply the resulting
calibration LUT in DaVinci Resolve. Keep in mind that monitor calibration can only
make a high quality display standards compliant; it cannot make up for a display
gamut that’s too small. For more information, see the “Lookup Tables” section of
Chapter 3, “System and User Preferences.”

Edit: Wie man die Lut generiert, habe ich noch nicht verstanden.

Wenn ich das noch einmal aufwärmen darf bzw. meine Erfahrungen dazu beisteuern? Unter Single-Monitor-Betrieb, Windows 10 (Laptop), Resolve 16+ und installiertem Display Cal Profile Loader ist das im im Display Cal Profile Loader hinterlegte Profil auf Grafikkartenebene(?) quasi über allem aktiv (Ausnahmen sind definierbar). Kalibriert über i1Pro. Nein, Resolve holt sich das ICC Profil nicht von Windows. Resolve steuert aber eben auch keine Decklink "direkter" an (die dann seperates color managment bräuchte), sondern geht über das OS den Weg über die einzige Grafikkarte im PC. Und da wird wohl Displaycal einsetzen. Soweit meiner Vermutung. Ich kann nicht die Hintergründe betrachten, ich kann nur meinen Augen vertrauen. Reproduzierbar ist das in quasi jeder software. Egal ob PC-Spiel, Resolve, oder am Windows Desktop.

Ja, das ist jetzt eben nicht das, was BMD garantieren kann. Und ich habe streng genommen keine abgestimmte Pipeline von Input-Farbraum, Scopes bis Ausgabe. Würde für mich heißen, z.B. Weißpunkt im Import Farbraum, Weißpunkt in den Scopes, Weißpunkt am Viewer (und Windows Ausgabe-Monitor) oder Decklink-Ausgabe. Ich kann das System dann zum Straucheln bringen, indem ich DisplayLoader über die Systemeigenen Windows-Einstellungen reinpfusche, was zu einem reproduzierbar springenden Farbshift über der gesamten Resolve-Objerfläche führt (auf Monitor-Default bzw. Pre-Kalibrierung. Also Kalibrierung über Systemstandard minus Kalibrierung gleich vor-Profilierung). Das betrifft GUI & Viewer.

Das würde für mich auf folgendes hindeuten:
Möglicherweise schafft es Resolve beim Hinterlegen des LUTs diese Kalibrierung in die Viewer-Darstellung sowie Scopes einzubeziehen. Das müsste aber eine Dopplung mit z.B. Display Cal Systemstandard bringen - und würde dazu führen, dass z.B. das graue GUI farbstichig bleibt. Umgekehrt schafft es vmtl. eine WYSIWYG-Darstellung auf Resolve innerhalb der Systemebene, allerdings ohne Verlässlichkeit bei Transformierung, Scopes oder einem 2. Monitor. Das sind lediglich meine Erfahrunen, was ich mit Fehlersuche (nach den Grenzen der Methode) und Reproduktion ermitteln kann, aber das zeigen meine Erfahrungen: Der Resolve Viewer ist unter Windows tatsächlich in bestimmten Fällen einer Gesamt-System-Profilierung unterworfen. BMD garantiert das allerdings nicht und es bezieht sich tatsächlich nicht auf Farbraummanagement in Resolve, aber das Ergebnis könnte für gewisse Anwendungen ausreichend sein.

Umgekehrt - falls das geschriebene Blödsinn sein sollte - kann ich mir nicht erklären, wieso eine Änderung (bzw. gegeneinander Arbeiten lassen) von Windows-System-Farbmanagement und DisplayCal Profile Loader zu sichtbaren (dementsprechend auch messbaren), reproduzierbaren Änderungen führt, die (neben GUI) auch den Viewer betreffen. Nein, das ist kein Farbmanagement per se, wo ich einen Punkt im Eingabefarbraum über eine Transformierung korrekt auf die Darstellung des Monitors mappen kann. Trotzdem fließt (meine Interpretation) nach einer Resolve-softwareseitig "dummen" Input - Output Farbraumkonvertierung das Ergebnis der Kalibrierung (Kalibrierung = Output-Farbraum, Rec709. / BT1886 / 100nit) in die Anzeige auf dem Monitor ein.

[dienstag_01]

Aha. Gestern hieß es noch, dass eine Decklink nicht nötig ist.
Nennen wir es mal Erkenntnisgewinn.

ich fürchte, du missverstehst mich:

decklink-ausgabe -- bzw. dieser umweg, der nur fürs resolve einigermaßen funktioniert -- repräsentiert vielmehr das gegenteil von befriedigendem systemweitem farbmanagement!

Gestern ging es aber nicht um systemweites Farbmanagment, sondern um das aus Resolve. Und wenn es systemweit nicht funktioniert, dann ist der proprietäre Weg über spezielle Hardware besser als nichts.

[dienstag_01]

Keine Ahnung, aber ich habe ein Handbuch ;)
Alternately, you can apply a dedicated Color Viewer LUT for calibration, using
the 1D/3D Color Viewer Lookup Table drop-down menu that’s found in the
Color Management panel of the Project Settings. This lets you analyze your
computer display for calibration in the same way you would calibrate an external
display, using a probe and color management software, and apply the resulting
calibration LUT in DaVinci Resolve. Keep in mind that monitor calibration can only
make a high quality display standards compliant; it cannot make up for a display
gamut that’s too small. For more information, see the “Lookup Tables” section of
Chapter 3, “System and User Preferences.”

Edit: Wie man die Lut generiert, habe ich noch nicht verstanden.

Wenn ich das noch einmal aufwärmen darf bzw. meine Erfahrungen dazu beisteuern? Unter Single-Monitor-Betrieb, Windows 10 (Laptop), Resolve 16+ und installiertem Display Cal Profile Loader ist das im im Display Cal Profile Loader hinterlegte Profil auf Grafikkartenebene(?) quasi über allem aktiv (Ausnahmen sind definierbar). Kalibriert über i1Pro. Nein, Resolve holt sich das ICC Profil nicht von Windows. Resolve steuert aber eben auch keine Decklink "direkter" an (die dann seperates color managment bräuchte), sondern geht über das OS den Weg über die einzige Grafikkarte im PC. Und da wird wohl Displaycal einsetzen. Soweit meiner Vermutung. Ich kann nicht die Hintergründe betrachten, ich kann nur meinen Augen vertrauen. Reproduzierbar ist das in quasi jeder software. Egal ob PC-Spiel, Resolve, oder am Windows Desktop.

Ja, das ist jetzt eben nicht das, was BMD garantieren kann. Und ich habe streng genommen keine abgestimmte Pipeline von Input-Farbraum, Scopes bis Ausgabe. Würde für mich heißen, z.B. Weißpunkt im Import Farbraum, Weißpunkt in den Scopes, Weißpunkt am Viewer (und Windows Ausgabe-Monitor) oder Decklink-Ausgabe. Ich kann das System dann zum Straucheln bringen, indem ich DisplayLoader über die Systemeigenen Windows-Einstellungen reinpfusche, was zu einem reproduzierbar springenden Farbshift über der gesamten Resolve-Objerfläche führt (auf Monitor-Default bzw. Pre-Kalibrierung. Also Kalibrierung über Systemstandard minus Kalibrierung gleich vor-Profilierung). Das betrifft GUI & Viewer.

Das würde für mich auf folgendes hindeuten:
Möglicherweise schafft es Resolve beim Hinterlegen des LUTs diese Kalibrierung in die Viewer-Darstellung sowie Scopes einzubeziehen. Das müsste aber eine Dopplung mit z.B. Display Cal Systemstandard bringen - und würde dazu führen, dass z.B. das graue GUI farbstichig bleibt. Umgekehrt schafft es vmtl. eine WYSIWYG-Darstellung auf Resolve innerhalb der Systemebene, allerdings ohne Verlässlichkeit bei Transformierung, Scopes oder einem 2. Monitor. Das sind lediglich meine Erfahrunen, was ich mit Fehlersuche (nach den Grenzen der Methode) und Reproduktion ermitteln kann, aber das zeigen meine Erfahrungen: Der Resolve Viewer ist unter Windows tatsächlich in bestimmten Fällen einer Gesamt-System-Profilierung unterworfen. BMD garantiert das allerdings nicht und es bezieht sich tatsächlich nicht auf Farbraummanagement in Resolve, aber das Ergebnis könnte für gewisse Anwendungen ausreichend sein.

Umgekehrt - falls das geschriebene Blödsinn sein sollte - kann ich mir nicht erklären, wieso eine Änderung (bzw. gegeneinander Arbeiten lassen) von Windows-System-Farbmanagement und DisplayCal Profile Loader zu sichtbaren (dementsprechend auch messbaren), reproduzierbaren Änderungen führt, die (neben GUI) auch den Viewer betreffen. Nein, das ist kein Farbmanagement per se, wo ich einen Punkt im Eingabefarbraum über eine Transformierung korrekt auf die Darstellung des Monitors mappen kann. Trotzdem fließt (meine Interpretation) nach einer Resolve-softwareseitig "dummen" Input - Output Farbraumkonvertierung das Ergebnis der Kalibrierung (Kalibrierung = Output-Farbraum, Rec709. / BT1886 / 100nit) in die Anzeige auf dem Monitor ein.

Spontan fällt mir ein: Wenn man in Windows ein Farbprofil einbindet, wirkt sich das auch auf das Hintergrundbild des Desktops aus. Trotzdem ist das kein Farbmanagment.
Für Farbmanagment muss die Anwendung mit diesem Profil kommunizieren, z.B. um bestimmte Un-Konformitäten in der Kennlinie des Monitors ausbügeln - so nenne ich das jetzt mal - zu können. Wie stark oder schwach die Abweichung im einzelnen ist, sei jetzt mal dahin gestellt.

[pillepalle]

Gestern ging es aber nicht um systemweites Farbmanagment, sondern um das aus Resolve. Und wenn es systemweit nicht funktioniert, dann ist der proprietäre Weg über spezielle Hardware besser als nichts.

Das gilt ja nicht systemweit, sondern nur für Resolve und andere NLEs. In Photoshop gibt es schon einen gut funktionierendes Color Management. Ist also eher ein software-spezifisches Problem. Vorher ging die Diskussion ja darum, dass weil Windows nur sRGB darstellen kann, jede GUI innerhalb des Betriebssystems das auch nur können sollte. (ja ja, schlechtes Deutsch *g*)

VG

[klusterdegenerierung]

Gestern ging es aber nicht um systemweites Farbmanagment, sondern um das aus Resolve. Und wenn es systemweit nicht funktioniert, dann ist der proprietäre Weg über spezielle Hardware besser als nichts.

Ich weiß es nicht, aber ich gehe mal davon aus, das wenn Windows ein Farbprofil lädt, sehe ich alles in diesem Profil, ob das ein Foto im Photoshop oder das Explorerfenster ist, man sieht ja auch sofort den Unterschied wenn das Profil wechselt.

Wie Win sich mit den 10Bit verhält kann ich nicht genaus sagen, denn auf der einen Seite wird zumindest angezeigt das es präsent ist, aber auf der anderen vielleicht einfach der Umstand, das die Fenster etc. unter Win so wenige Farben benötigen, das man 10Bit garnicht mit bekommt und erst in der NLE am footage sieht.