Infoseite // 10 bit Clean Video Feed unter Windows

Frage von SamSuffy:


Hallo zusammen,

mit der 18er Beta gibt es ja nun auch für Windows Nutzer die Möglichkeit, den Vorschaumonitor (Clean Video Feed) mit 10bit anzusprechen.
Warum das nicht mehr Wellen schlägt frag ich mich schon, aber gut...

Nun habe ich solch einen besagten Monitor und glaube auch, dass dieser mit 10bit angesprochen wird, denn wenn ich einen Grau-/oder Farbverlauf generiere, dieser keine so groben Abstufungen anzeigt wie meine 8bit Monitore. Auf der anderen Seite sind aber die 8bit Monitore soo mieß, dass dies gar nichts heißen muss.

Wenn ich ACES auf P3 Ausgabe stelle, sieht das schon sehr Ordentlich aus!

Wie kann ich mir denn nun sicher sein, dass ich die 10bit dort bekomme?
Ich weiß, nur mit einem Decklink kann ich mir der Anzeige sicher sein, aber wenn das schon im Clean Video Feed einigermaßen passen würde wäre ich schon froh.



Antwort von cantsin:

SamSuffy hat geschrieben:
Wenn ich ACES auf P3 Ausgabe stelle, sieht das schon sehr Ordentlich aus!

Wie kann ich mir denn nun sicher sein, dass ich die 10bit dort bekomme?
Ich weiß, nur mit einem Decklink kann ich mir der Anzeige sicher sein, aber wenn das schon im Clean Video Feed einigermaßen passen würde wäre ich schon froh. Der Clean Feed ist zwar jetzt 10bit, aber AFAIK weiterhin nicht als Farbreferenz tauglich, siehe die Sektion "Limitations When Grading with the Viewer on a Computer Display" im Resolve-Handbuch. Bisher ging darüber auch nur sRGB-Ausgabe.

Zu diesem Thema gibt's viele Missverständnisse und hatten wir von einiger Zeit mal eine lange Diskussion: viewtopic.php?f=93&t=151703

Fazit dieser und aller anderen Diskussionen war bisher immer: sRGB-Ausgabe mit Resolve (und anderen Schnitt-/Gradingprogrammen) geht immer und mittlerweile auch gut genug, um Videofarben am Computermonitor beurteilen zu können, zumal wenn das Zielmedium Online-Video ist. Für alle anderen Farbräume braucht man entweder einen Mac mit P3-Ausgabe und allerlei Hacks, um echtes P3 auf Apples standard-inkompatiblem "Display P3" auszugeben, oder eine Decklink-Karte.

Ob sich das mit Resolve 18 geändert haben sollte, würde mich auch interessieren. 10bit-Ausgabe heisst aber erstmal nur 10bit sRGB, wie bei anderen Programmen auch. Alles andere wäre eher eine Überraschung.



Antwort von SamSuffy:

Und ich hatte mich schon gefreut doch noch um ein Decklink und Endgerätereferenz zu kommen.



Antwort von SamSuffy:

Aber müsste ein sRGB Ausgabe nicht völlig übersättigt sein, auf meinem Monitor, so wie alles was Windows darauf ausspuckt, was kein Farbmanagement hat?
Das ist bei Resolve zumindest nicht der Fall, auch schon vor der 10bit Ausgabe des Viewers.



Antwort von cantsin:

SamSuffy hat geschrieben:
Aber müsste ein sRGB Ausgabe nicht völlig übersättigt sein, auf meinem Monitor, so wie alles was Windows darauf ausspuckt, was kein Farbmanagement hat? Jetzt wird's komplex, potentiell fehlerbehaftet, und wir kommen wieder in die Untiefen des von mir oben verlinkten Diskussionsthreads mit seinen 421 Beiträgen...

Wenn Du Windows nicht im HDR-Modus laufen hast, gibt es immer sRGB aus, weil es neben HDR10/Rec2100 nur dieses eine Gamma und diesen einen Farbraum beherrscht. Jetzt ist die Frage, welches Gamma und welcher Farbraum an Deinem Monitor eingestellt ist. Eigentlich müsste das auch sRGB sein, wenn Du eine Windows-kompatible Farbwiedergabe willst.

Hast Du den Monitor in einem Wide Gamut stehen (z.B. in P3), dann werden natürlich die vom Betriebssystem gelieferten sRGB-Farben falsch angezeigt. Wenn Du dem abgeholfen hast, indem Du Windows auf Deinen auf P3 eingestellten Monitor per Software kalibrierst hast, gibt Windows zwar immer noch sRGB aus - oder glaubt das zumindest -, aber die Farben stimmen dann auf Deinem P3-Monitor bei aller Software, die farbgemanagt ist. Trotzdem geht alle Deine Software intern davon aus, eigentlich sRGB auszugeben. Ggfs. handelst Du Dir tollsten Effekte ein, wenn z.B. ein Projekt in einer Grafik- oder Videoanwendung intern auf P3 steht, die Software aber ihre Monitorausgabe intern (und Windows-konform) für sRGB umrechnet und dann Deine Kalibrierung wiederum sRGB als P3 interpretiert.

Du hast dann also einen sRGB-/P3-Mischbetrieb mit z.T. unvorhersagbaren Ergebnissen, bzw. betreibst Windows und alle drauf laufende Anwendersoftware ausserhalb der Spezifikation in einem darin nicht vorgesehenen Farbmodus.

Ob Resolve mit so einer Mischkonfiguration zurechtkommt und korrekte Farben ausgibt - keine Ahnung. Zumindest war es bisher, laut Handbuch, nicht darauf ausgelegt. Die Frage ist noch, ob sich mit Version 18 in dieser Hinsicht etwas geändert hat.

Bisher war die einzige saubere und verlässliche Lösung für Dein Szenario, einen auf P3 kalibrierten Monitor an eine Decklink-Karte (am besten per SDI) anzuschließen und die Ausgaben in Resolve entsprechend zu konfigurieren, da hier garantiert am Betriebssystem und dessen eigenem (bei Windows: auf sRGB und HDR/Rec2100 beschränkten) Color Management vorbei das richtige P3-Signal am Monitor ankommt.

(Wobei man gleich warnen muss, dass die Decklinks im Gegensatz zu Computergrafikkarten nicht die feste Monitor-Bildwiederholrate ausgeben, sondern immer die genaue Bildrate des Schnittprojekts bzw. der Timeline, wie z.B. 23,98p, 24p, 25p, 29,97p und 30p. Wenn Dein Monitor, wie die meisten Computermonitore, diese Bildwiederholraten nicht oder nur teilweise unterstützt, bleibt der Bildschirm an der Decklink ggfs. schwarz.)



Antwort von SamSuffy:

Vielen Dank, cantsin.

Es ist nun schon deutlich mehr Licht im Keller dieses Themas ;)



Antwort von cantsin:

Es wäre aber trotzdem mal interessant herauszufinden, ob man Resolve 18 auf 10bit und P3-Bildschirmausgabe einstellen kann und dann auf einem auf P3 stehenden Computermonitor richtige (oder zumindest weitgehend richtige) Farben erscheinen.

Denn zumindest könnte man dann den Monitor für längere Resolve-Arbeitssitzungen von sRGB auf P3 umschalten, und für andere Anwendungen wieder zurück auf sRGB. Wäre zwar ein bisschen umständlich (und bei Unaufmerksamkeit auch fehlerträchtig), aber zumindest ein interessanter Low Budget-Hack/Workaround.



Antwort von MK:

Es könnte auch mal ein Hersteller auf die Idee kommen den Farbraum im HDMI-Signal zu übertragen damit der Monitor automatisch umschalten kann... aber für solche Hochtechnologie ist die Zeit wohl noch nicht reif.



Antwort von pillepalle:

cantsin hat geschrieben:

Du hast dann also einen sRGB-/P3-Mischbetrieb mit z.T. unvorhersagbaren Ergebnissen, bzw. betreibst Windows und alle drauf laufende Anwendersoftware ausserhalb der Spezifikation in einem darin nicht vorgesehenen Farbmodus.

Ob Resolve mit so einer Mischkonfiguration zurechtkommt und korrekte Farben ausgibt - keine Ahnung. Zumindest war es bisher, laut Handbuch, nicht darauf ausgelegt. Die Frage ist noch, ob sich mit Version 18 in dieser Hinsicht etwas geändert hat. Das eine ist das Betriebssystem Windows (und dessen Fenster) die nur sRGB darstellen können, das Andere ist der Arbeitsfarbraum Deiner Software die Farbmanagement unterstützt. Da kann man natürlich entsprechende Farbräume einstellen und nutzen. Vorausgesetzt man hat einen kalibrierbaren Monitor der auch auf den entsprechenden Farbraum kalibriert ist und ihn unterstützt.

Visuell und bezüglich des Bildeindrucks macht es keinen Unterschied, ob ich z.B. in Resolve meinen Monitor direkt über die Grafikkarte anspreche, oder über die Decklink Karte. Nur passt sich die Decklink Karte (wie ja bereits von cantsin geschrieben) automatisch an den Arbeitsfarbraum von Resolve an und somit z.B. auch an die Framerate der Timeline, während man über die Grafikkarte immer mit der gleichen (und meist falschen) Bildwiederholfrequenz schaut (bei mir z.B. 60Hz). Das ist natürlich nicht konform mit der Norm, aber bezüglich der Farben und Kontraste ändert es nichts. Ich kann über die Grafikkarte genausogut graden wie über die Decklink Karte. Wenn ich aber Motionblur und die Bewegung bei der entsprechenden Framerate beurteilen möchte, bzw. ich norm-konform arbeiten möchte, dann macht die Decklink-Karte schon Sinn.

VG






Antwort von cantsin:

pillepalle hat geschrieben:
Visuell und bezüglich des Bildeindrucks macht es keinen Unterschied, ob ich z.B. in Resolve meinen Monitor direkt über die Grafikkarte anspreche, oder über die Decklink Karte. Also, wenn ich in Resolve Studio (17.4.6) in den Projekteinstellungen unter "Color Management" den "Output Color Space" auf einen anderen Wert setze - selbst auf eine extreme Einstellung wie z.B. Cineon Log - ändert sich am Ausgabebild bzw. den Video-Wiedergabefarben im Resolve-GUI überhaupt nichts. Was ich da auch einstelle, Resolve gibt immer nur sRGB übers GUI aus. Die Einstellung des "Output Color Space" wirkt sich nur auf Decklink-Karten u.ä. aus.

Oder habe ich da noch eine andere Einstellung übersehen? Oder hat sich dieses Verhalten mit Resolve 18.x verändert?

Mir ist bisher auch keine andere Videosoftware bekannt, die in Windows über Bordmittel bzw. normale Grafikkartenausgabe andere Farbräume als sRGB ausgeben kann.



Antwort von cantsin:

MK hat geschrieben:
Es könnte auch mal ein Hersteller auf die Idee kommen den Farbraum im HDMI-Signal zu übertragen damit der Monitor automatisch umschalten kann... aber für solche Hochtechnologie ist die Zeit wohl noch nicht reif. HDMI kann das ja bereits, z.B. im Umschalten von Rec709 (SDR) nach Rec2020 (HDR).

Das Problem ist nicht HDMI, sondern sind die Computer-Betriebssysteme (Windows, MacOS, Linux), deren Grafikausgabe auf nur wenige Farbräume und Gammas begrenzt ist, und die keine Bordmittel haben, um die meisten gängigen Farbräume/Gammas betriebssystemweit ein- und zwischen ihnen umzuschalten.



Antwort von pillepalle:

@ cantsin

In der Resolve GUI siehst Du den Unterschied in der Color Page natürlich nur, wenn Du auch Deinen Monitor auf den entsprechenden Farbraum kalibriert hast. Und dann siehst Du ihn über die Decklink genauso. Wenn Du also in REC709 arbeiten möchtest, muss Dein Monitor natürlich auch auf REC709 kalibriert sein. Und wenn er auf REC709 kalibriert ist, kannst Du zu P3-DCI nur wechseln, wenn Du ihn vorher auf die anderen Parameter neu kalibrierst.

Ich habe ja nicht nur mehrere Hardware-Profile die ich im Monitor speichern kann, sondern auch beides gleichzeitig angeschlossen. Die Decklink über HDMI und die Grafikkarte über den Displayport Eingang. So kann ich zwischen den Eingängen wechseln, mir die Unterschiede im Monitorbild (je nach Signalquelle) ansehen und die jeweiligen Parameter anzeigen lassen. Ich habe da keine Tests zu gemacht, aber offen gestanden bemerke ich die Unterschiede in der Bildwiederholfrequenz kaum. Wenn ich mir nicht vom Monitor anzeigen lasse in welcher Bildwiederholrate er gerade spielt, könnte ich es auch nicht sagen. Vielleicht gibt es Leute die einen Unterschied bei z.B. 50 und 60Hz sehen können. Mir fällt das nie auf.

Wer anfängt, wenig Geld hat, oder das nur als Hobby macht, kann sich in meinen Augen die Decklink erstmal sparen und steckt das Geld lieber in einen besseren Monitor. Als Profi sollte man sich auch eine Decklink gönnen.

Jede Software mit Farbmanagement kann das. Auch mit Assimilate z.B. geht das wunderbar.

VG



Antwort von MK:

cantsin hat geschrieben:
HDMI kann das ja bereits, z.B. im Umschalten von Rec709 (SDR) nach Rec2020 (HDR). Das passiert aber über die damit verbundenen HDR-Metadaten... eine generelle Info ob der Farbraum 601, 709, sRGB oder DCI-P3 etc. ist wird nicht übertragen. Es scheitert ja schon bei der Übertragung ob das Signal 0-255 oder 16-235 ist... das muss auch am Endgerät manuell eingestellt werden wenn man z.B. einen TV an die Grafikkarte anschließt.

Erinnert ein bisschen an früher mit der 16:9 Umschaltung am TV per analogem SCART-Kabel... hat auch selten richtig funktioniert.



Antwort von cantsin:

pillepalle hat geschrieben:
@ cantsin

In der Resolve GUI siehst Du den Unterschied in der Color Page natürlich nur, wenn Du auch Deinen Monitor auf den entsprechenden Farbraum kalibriert hast. Leider nein. Und wie gesagt, es ändert sich einfach nichts an der GUI-Videoplayer-Ausgabe, selbst wenn ich die Ausgabe auf ein Log-Gamma wie Cineon stelle. Aber ich spreche vom normalen Computermonitor, nicht von einem externen Referenzmonitor. (Erklärung siehe weiter unten.)
Ich habe ja nicht nur mehrere Hardware-Profile die ich im Monitor speichern kann, sondern auch beides gleichzeitig angeschlossen. Die Decklink über HDMI und die Grafikkarte über den Displayport Eingang. Schon klar, aber wir reden - scheint mir - aneinander und am TO vorbei.

Dass am an einer Decklink einen anderen bzw. beliebig eingestellten Farbraum ausgeben kann: natürlich.

Was natürlich auch funktioniert und, wenn ich Dich richtig verstehe, Dein Anwendungsszenario ist: Standard-Computermonitor steht auf sRGB, zweiter Video-Referenzmonitor auf P3 (oder einem anderen erweiterten Farbraum), über die Resolve-GUI wird sRGB ausgegeben, über die Decklink P3 an den P3-Monitor, und dank des Farbmanagements von Resolve stimmen die Farben der GUI-sRGB-Anzeige mit den Farben der externen P3-Anzeige überein (soweit das in den Grenzen der jeweiligen Farbräume geht). Keine Frage.

Aber, was der TO gerne machen will, ist das folgende: seinen Computermonitor auf P3 stellen, Resolves GUI-Videoanzeige auch auf 10bit + P3 stellen, und dann ein P3-Monitoring ohne Decklink-Karte direkt über die normale Grafikkarte und den normalen Computermonitor machen (weil Resolve 18 jetzt 10bit-GUI-Ausgabe unterstützt).

Zumindest mit Resolve 17 funktioniert das nicht.



Antwort von pillepalle:

cantsin hat geschrieben:
Leider nein. Und wie gesagt, es ändert sich einfach nichts an der GUI-Videoplayer-Ausgabe, selbst wenn ich die Ausgabe auf ein Log-Gamma wie Cineon stelle. Das was sich ändern muss sind Deine Monitoreinstellungen. Deshalb nennt man die Monitore ja hardwarekalibrierbar, weil die Parameter nicht im Computer/GraKa sondern im Monitor gespeichert werden. Man kann in dem entsprechenden Farbraum nur arbeiten, wenn der Monitor auch entsprechend kalibriert ist. Das gilt für jeden Monitor. Auch Dein Referenzmonitor ist nur für den jeweils kalibrierten Farbraum eine Referenz. Wenn Dein Mac z.B. auf P3 und Gamma 2.2 werkskalibriert ist, kannst Du damit genau genommen auch kein REC709 graden, solange Du ihn nicht vorher auch auf REC709 kalibriert hast. Da kannst Du in Resolve einstellen was Du möchtest. Für die meisten reicht's auch so.
cantsin hat geschrieben:
Aber, was der TO gerne machen will, ist das folgende: seinen Computermonitor auf P3 stellen, Resolves GUI-Videoanzeige auch auf 10bit + P3 stellen, und dann ein P3-Monitoring ohne Decklink-Karte direkt über die normale Grafikkarte und den normalen Computermonitor machen (weil Resolve 18 jetzt 10bit-GUI-Ausgabe unterstützt). Dafür muss der Monitor P3 und 10 bit auch erstmal unterstützen. Wenn er das tut dann geht das schon.

Das was die Decklink Karte macht ist ein normkonformes Signal senden. So kann sie z.B die richtige Wiederholfrequenz wiedergeben, 10 Bit Signale senden, unterschiedliche Auflösungen mit einem Singlefield Video-Output. Alles Dinge die im Videobereich wichtig sein können und die die meisten Grafikkarten nicht beherrschen. Aber sie geben keine anderen Farbwerte aus. Das ist zumindest das, was ich festgestellt habe. Und graden tut man ohnehin meist an Stills und nicht am laufenden Videobild. Da ist dann selbst die Bildwiederholfrequenz nicht so wichtig.

Ich habe mir ja extra für Video eine Decklink geholt. Kosten ja auch nicht die Welt. Aber wirklich besser arbeite ich damit nicht. Genaugenommen muss ich selber nachschauen, was ich gerade eingestellt habe, um zu kapieren ob es über die Decklink oder über die Grafikkarte läuft.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
Das was sich ändern muss sind Deine Monitoreinstellungen. Deshalb nennt man die Monitore ja hardwarekalibrierbar, weil die Parameter nicht im Computer/GraKa sondern im Monitor gespeichert werden. Man kann in dem entsprechenden Farbraum nur arbeiten, wenn der Monitor auch entsprechend kalibriert ist. Das gilt für jeden Monitor. Auch Dein Referenzmonitor ist nur für den jeweils kalibrierten Farbraum eine Referenz. Wenn Dein Mac z.B. auf P3 und Gamma 2.2 werkskalibriert ist, kannst Du damit genau genommen auch kein REC709 graden, solange Du ihn nicht vorher auch auf REC709 kalibriert hast. Da kannst Du in Resolve einstellen was Du möchtest. Für die meisten reicht's auch so. Das ist schon klar.

Das Problem ist aber folgendes: Resolve rechnet intern seine GUI-Videoausgabe unter Windows für sRGB um. Du kannst jetzt zwar Dein Projekt auf P3 eingestellt haben und auch Deinen Computermonitor auf P3, trotzdem macht Resolve diese interne Umrechnung und gibt Dir kein P3 über die GUI (= nicht die Decklink) aus. Was auch immer Du als Projektfarbraum in Resolve einstellst, die GUI-Ausgabe geht immer auf sRGB 'runter.

Man könnte jetzt natürlich einen Hack machen, den Monitor auf P3 lassen, das Projekt intern auf sRGB/Rec709 setzen, so dass keine Umrechnung mehr stattfindet, und dann nach Augenschein des P3-Monitors ein P3-Projekt graden.

Wenn Du dann aber 'rausrenderst, stimmen alle Metadaten nicht mehr und Dein Video wird wahrscheinlich mit Falschfarben wiedergegeben.



Antwort von pillepalle:

cantsin hat geschrieben:
Das Problem ist aber folgendes: Resolve rechnet intern seine GUI-Videoausgabe unter Windows für sRGB um. Du kannst jetzt zwar Dein Projekt auf P3 eingestellt haben und auch Deinen Computermonitor auf P3, trotzdem macht Resolve diese interne Umrechnung und gibt Dir kein P3 über die GUI (= nicht die Decklink) aus. Was auch immer Du als Projektfarbraum in Resolve einstellst, die GUI-Ausgabe geht immer auf sRGB 'runter. Nein. So funktioniert das garantiert nicht. Vergiss mal Dein sRGB, das hat mit der GUI eines Programms das Farbmanagement beherrscht nichts zu tun. Niemand könnte sonst mit Baselight, Avid, Photoshop, oder sonst was arbeiten, wenn da in der GUI nur sRGB rauskäme.

Das eine Videokarte bestimmte Eigenschaften hat die nützlich sind steht außer Frage, aber die tollen Farben sind es nicht. Zumindest nicht gegenüber modernen Grafikkarten die 10bit beherrschen.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
cantsin hat geschrieben:
Das Problem ist aber folgendes: Resolve rechnet intern seine GUI-Videoausgabe unter Windows für sRGB um. Du kannst jetzt zwar Dein Projekt auf P3 eingestellt haben und auch Deinen Computermonitor auf P3, trotzdem macht Resolve diese interne Umrechnung und gibt Dir kein P3 über die GUI (= nicht die Decklink) aus. Was auch immer Du als Projektfarbraum in Resolve einstellst, die GUI-Ausgabe geht immer auf sRGB 'runter. Nein. So funktioniert das garantiert nicht. Vergiss mal Dein sRGB, das hat mit der GUI eines Programms das Farbmanagement beherrscht nichts zu tun. Da liegt Dein Denkfehler. Resolve beherrscht kein (GUI-) Farbmanagement.

Das Programm ist darauf ausgelegt, dass man für ernsthaftes Colorgrading Blackmagics Karten kauft.

Lies Dir Blackmagics Resolve-Handbuch durch, sieh Dir alle Beiträge von Blackmagic-Mitarbeitern auf Blackmagics Support-Forum an, es gibt da immer nur diese eine Antwort.

pillepalle hat geschrieben:
Niemand könnte sonst mit Baselight, Avid, Photoshop, oder sonst was arbeiten, wenn da in der GUI nur sRGB rauskäme. Du bist da auf dem Holzweg. Bei Fotobearbeitung mag das anders sein, aber bei professionellen Videoanwendungen wird prinzipiell nicht über die GUI farbkritisch gearbeitet und sind alle diese Programme für externes Monitoring ausgelegt.






Antwort von pillepalle:

Ich weiß aber was ich sehe und da macht die Decklink in Punkto Farben nichts besser als die Grafikkarte. Egal in welchem Farbraum.

Ich weiß auch nicht warum Du dich so mit Windows festgebissen hast. Deine Vorstellung das die dargestellten Farben einer GUI mit dem Farbraum den das Betriebssystem nutzt übereinstimmen müssten, halte ich einfach für falsch.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
Ich weiß aber was ich sehe und da macht die Decklink in Punkto Farben nichts besser als die Grafikkarte. Egal in welchem Farbraum. Tu mir doch bitte mal den kleinen Gefallen und setze mal experimentellerweise sowohl den "Timeline Colorspace", als auch den "Output Color Space" in Resolve auf ein Log-Profil (z.B. Cineon oder S-Log). Das bedeutet, da sind wir uns sicher einig, eine drastische Veränderung der Farben. Warum ändern sich dann, nach dieser Einstellung, die Farben im GUI-Video-Viewer nicht?



Antwort von dienstag_01:

pillepalle hat geschrieben:
Ich weiß aber was ich sehe und da macht die Decklink in Punkto Farben nichts besser als die Grafikkarte. Egal in welchem Farbraum.

Ich weiß auch nicht warum Du dich so mit Windows festgebissen hast. Deine Vorstellung das die dargestellten Farben einer GUI mit dem Farbraum den das Betriebssystem nutzt übereinstimmen müssten, halte ich einfach für falsch.

VG Ich erinnere mich nur noch dunkel an den alten Thread. Aber wenn ich mir nochmal das Benutzerhandbuch anschaue, dann lese ich in der Box: "Limitations when grading with the viewer on Computer display" das komplette Gegenteil der Aussage von cantsin. Da kann man z.B. mit Hilfe von LUTs den Viewer auf andere Farbräume kalibrieren. Ob das für den Video Clean Feed auch funktioniert, müsste man ausprobieren. Da hätte ich aber auch meine Zweifel.



Antwort von cantsin:

dienstag_01 hat geschrieben:
pillepalle hat geschrieben:
Ich weiß aber was ich sehe und da macht die Decklink in Punkto Farben nichts besser als die Grafikkarte. Egal in welchem Farbraum.

Ich weiß auch nicht warum Du dich so mit Windows festgebissen hast. Deine Vorstellung das die dargestellten Farben einer GUI mit dem Farbraum den das Betriebssystem nutzt übereinstimmen müssten, halte ich einfach für falsch.

VG Ich erinnere mich nur noch dunkel an den alten Thread. Aber wenn ich mir nochmal das Benutzerhandbuch anschaue, dann lese ich in der Box: "Limitations when grading with the viewer on Computer display" das komplette Gegenteil der Aussage von cantsin. Da kann man z.B. mit Hilfe von LUTs den Viewer auf andere Farbräume kalibrieren. Ja, das geht tatsächlich - als Hack oder Workaround -, und dafür gibt's sogar eine Lösung bzw. programminterne Unterstützung (beim leider nicht mehr gepflegten) Open Source-Kalibrierungsprogramm DisplayCal (das Display-LUTs für Resolve erzeugen kann). Nur geht dieser Workaround eben komplett am Color Management des Betriebssystems vorbei.

Wobei noch zur Deutlichkeit gesagt werden muss, dass Resolve unter MacOS dessen ColorSync unterstützt. Das steht auch so im Handbuch in der von Dir o.g. Passage. Nur unter Linux und Windows wird kein betriebssystemseitiges Color Management unterstützt, gibt das Programm ans GUI immer sRGB aus und kann man daher nur mit LUTs den Farbraum der GUI-Anzeigen umbiegen. Wie ich hier schon einmal geschrieben habe, habe ich diese Aussage sogar persönlich von den beiden sehr gentlemanhaften, aus Indien stammenden Resolve-Hauptentwicklern bei der IBC 2019 erhalten.

Wobei das der Stand von Resolve 17 ist. Die Frage ist, ob sich da etwas mit Resolve 18 verändert hat. (Ich kann's nicht nachprüfen, weil ich die neue Version erst installieren und meine Projektdatenbank erst dann migrierern werde, wenn es ein stabiles Major Release gibt.)



Antwort von dienstag_01:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:

Ich erinnere mich nur noch dunkel an den alten Thread. Aber wenn ich mir nochmal das Benutzerhandbuch anschaue, dann lese ich in der Box: "Limitations when grading with the viewer on Computer display" das komplette Gegenteil der Aussage von cantsin. Da kann man z.B. mit Hilfe von LUTs den Viewer auf andere Farbräume kalibrieren. Ja, das geht tatsächlich - als Hack oder Workaround -, und dafür gibt's sogar eine Lösung bzw. programminterne Unterstützung (beim leider nicht mehr gepflegten) Open Source-Kalibrierungsprogramm DisplayCal (das Display-LUTs für Resolve erzeugen kann). Nur geht dieser Workaround eben komplett am Color Management des Betriebssystems vorbei.

Wobei noch zur Deutlichkeit gesagt werden muss, dass Resolve unter MacOS dessen ColorSync unterstützt. Das steht auch so im Handbuch in der von Dir o.g. Passage. Nur unter Linux und Windows wird kein betriebssystemseitiges Color Management unterstützt, gibt das Programm immer sRGB aus und kann man daher nur mit LUTs den Farbraum der GUI-Anzeigen umbiegen. Wie ich hier schon einmal geschrieben habe, habe ich diese Aussage sogar persönlich von den beiden sehr gentlemanhaften, aus Indien stammenden Resolve-Hauptentwickelern bei der IBC 2019 erhalten. Von Umbiegen steht da nichts.



Antwort von pillepalle:

cantsin hat geschrieben:
Tu mir doch bitte mal den kleinen Gefallen und setze mal experimentellerweise den "Output Color Space" in Resolve auf ein Log-Profil (z.B. Cineon oder S-Log). Das bedeutet, da sind wir uns sicher einig, eine drastische Veränderung der Farben. Warum ändern sich dann, nach dieser Einstellung, die Farben im GUI-Video-Viewer nicht? Weil das den Output ColorSpace betrifft, in den der Clip gerendert wird. Du stellst normalerweise einen Input-ColorSpace ein (der Farbraum in dem sich das Quellmaterial befindet) einen Timeline Color Space (das ist Dein Arbeitsfarbraum auf den auch Dein Monitor kalibriert sein sollte), und einen Output Color Space. Wenn Dein Arbeitsfarbraum ein anderer sein soll, musst Du auch Deinen Monitor anders kalibrieren.

Das ganze Resolve Color Management würde doch überhaupt keinen Sinn machen, wenn Dein Arbeitsfarbraum immer nur sRGB wäre. Außerdem nutzt auch Apples Color Sync icc-Profile die sich nicht großartig von denen von Windows unterscheiden.

VG



Antwort von cantsin:

dienstag_01 hat geschrieben:
Von Umbiegen steht da nichts. Aber von Resolve-interner Display-Kalibrierung ausserhalb der Betriebssystem-Mechanismen.

Hier nochmal das Zitat aus dem Handbuch: "An additional issue, however, is that depending on your combination of workstation and computer display, the Viewer does not necessarily display each clip’s image data as it is displayed by the calibration that your operating system applies to your computer display, depending on which OS you’re running DaVinci Resolve on".



Antwort von cantsin:

pillepalle hat geschrieben:
cantsin hat geschrieben:
Tu mir doch bitte mal den kleinen Gefallen und setze mal experimentellerweise den "Output Color Space" in Resolve auf ein Log-Profil (z.B. Cineon oder S-Log). Das bedeutet, da sind wir uns sicher einig, eine drastische Veränderung der Farben. Warum ändern sich dann, nach dieser Einstellung, die Farben im GUI-Video-Viewer nicht? Weil das den Output ColorSpace betrifft, in den der Clip gerendert wird. Stell dann auch mal den Timeline Color Space auf Cineon oder SLog um. Du wirst Dich wundern.



Antwort von pillepalle:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:
Von Umbiegen steht da nichts. Aber von Resolve-interner Display-Kalibrierung ausserhalb der Betriebssystem-Mechanismen.

Hier nochmal das Zitat aus dem Handbuch: "An additional issue, however, is that depending on your combination of workstation and computer display, the Viewer does not necessarily display each clip’s image data as it is displayed by the calibration that your operating system applies to your computer display, depending on which OS you’re running DaVinci Resolve on". Aber so arbeitet ja auch kein Profi. Die reden von nicht kalibrierten Monitoren bei denen die Farben vom Betriebssystem gesteuert werden.

VG






Antwort von dienstag_01:

cantsin hat geschrieben:
pillepalle hat geschrieben:


Weil das den Output ColorSpace betrifft, in den der Clip gerendert wird. Stell dann auch mal den Timeline Color Space auf Cineon oder SLog um. Du wirst Dich wundern. Welcher Monitor macht denn sLog bzw. Cineon?



Antwort von cantsin:

dienstag_01 hat geschrieben:
cantsin hat geschrieben:


Stell dann auch mal den Timeline Color Space auf Cineon oder SLog um. Du wirst Dich wundern. Welcher Monitor macht denn sLog bzw. Cineon? Ja eben. Resolve zeigt aber auch dann im GUI-Viewer sRGB-Farben an, wenn der Timeline Color Space auf sLog oder Cineon steht, weil es - wie schon mehrfach gesagt -, die Farben im GUI-Viewer immer als sRGB ausgibt bzw. in sRGB umrechnet, egal in welchem Farbraum die Timeline bzw. das Projekt steht. (Ich hätte damals wirklich eine Audioaufnahme der beiden Resolve-Entwickler machen sollen, damit mir hier jemand mal glaubt, obwohl man es ja mit dem einfachen Setzen des Timeline-Arbeits-Farbraums auf so etwas absurdes wie Cineon in einer Sekunde nachprüfen kann...) Unter Windows und Linux, wohlgemerkt, um Missverständnisse zu vermeiden.



Antwort von pillepalle:

@ catsin

Wenn es stimmen würde was Du schreibst, dann hätte Resolve auch kein Color Management. Und es widerspricht allen Erfahungen die ich bisher gemacht habe. Wie gesagt, ich sehe in keinem Farbraum irgendwas über die Decklink anders. Und ich arbeite ja auch am Mac (da allerdings ohne Decklink) und mir sind nie Unterschiede zum PC aufgefallen. Auch wenn ich Projekte am PC angefangen und am Mac beendet habe.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
@ catsin

Wenn es stimmen würde was Du schreibst, dann hätte Resolve auch kein Color Management. Und es widerspricht allen Erfahungen die ich bisher gemacht habe. Bitte, bitte, stelle doch einfach mal Deinen Timeline-Farbraum auf sLog oder Cineon, wenn Du mir nicht glaubst.



Antwort von pillepalle:

Hab ich schon. Was soll den Da passieren? Du transformierst das Material beim Importieren und beim Exportieren, nicht im Arbeitsfarbraum. Im Arbeitsfarbraum braucht es andere Monitoreinstellungen damit Du irgendetwas anders siehst. Auch mit 'ner Decklink.

VG



Antwort von Frank Glencairn:

pillepalle hat geschrieben:


Weil das den Output ColorSpace betrifft, in den der Clip gerendert wird. Du stellst normalerweise einen Input-ColorSpace ein (der Farbraum in dem sich das Quellmaterial befindet) einen Timeline Color Space (das ist Dein Arbeitsfarbraum auf den auch Dein Monitor kalibriert sein sollte), Da hat sich ein Denkfehler eingeschlichen.

Resolve arbeitet eigentlich immer (egal ob Color Management oder nicht) Scene-Referrred - außer man zwingt es mit Gewalt in einen Display-Referred Workflow, aber warum sollte man das machen?

Der Timeline Colorspace, oder Arbeitsfarbraum hat (gottseidank) nix mit dem Monitor zu tun.
Dafür ist dein Output Colorspace zuständig. Wenn man also irgendwelche Unterschiede am Vorschau Monitor sehen möchte, muß man schon den Output ändern.

Solange der Output auf 709 (oder sonstwas) steht wird er immer - egal in welchem Timeline Farbraum du arbeitest - alles was aus der Timeline kommt nach 709 (oder sonstwas) wandeln.



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
[
Der Timeline Colorspace, oder Arbeitsfarbraum hat (gottseidank) nix mit dem Monitor zu tun.
Dafür ist dein Output Colorspace zuständig. Wenn man also irgendwelche Unterschiede am Vorschau Monitor sehen möchte, muß man schon den Output ändern.

Solange der Output auf 709 (oder sonstwas) steht wird er immer - egal in welchem Timeline Farbraum du arbeitest - alles was aus der Timeline kommt nach 709 (oder sonstwas) wandeln. Nur hat eben, wie wir bereits festgestellt haben, die Einstellung des Output Color Space unter Windows keinerlei Auswirkung auf die Video-Anzeige im GUI. Was wiederum beweist, dass im GUI stur sRGB ausgegeben wird.

Ich werde das gleich einmal noch mit einem Praxisexperiment überprüfen und ggfs. untermauern.



Antwort von pillepalle:

"Frank Glencairn" hat geschrieben:
Der Timeline Colorspace, oder Arbeitsfarbraum hat (gottseidank) nix mit dem Monitor zu tun.
Dafür ist dein Output Colorspace zuständig. Wenn man also irgendwelche Unterschiede am Vorschau Monitor sehen möchte, muß man schon den Output ändern.

Solange der Output auf 709 (oder sonstwas) steht wird er immer - egal in welchem Timeline Farbraum du arbeitest - alles was aus der Timeline kommt nach 709 (oder sonstwas) wandeln. Ja, das fand ich bei Resolve ohnehin immer etwas verwirrend. Der eigentliche Punkt ist aber, dass wenn ich den Output verändere sich nicht nur der Vorschauonitor verändert, sondern auch die GUI Ansicht in der Color Page. Das ausgegebene Bild sieht dann über die GUI genauso aus wie über den Videoout des Referenzmonitors via Decklink. Deshalb fand ich cantsins Aussage, er würde die Farben in der GUI anders darstellen (z.B. nur in sRGB) ja auch so irritierend. Ich habe einfach den Eindruck dass aus einer 10bit Grafikarte genau die gleichen Farben herauskommen wie aus einer Decklink-Karte, vorausgesetzt man benutzt bei beiden einen Kalibrierten Monitor.

VG



Antwort von pillepalle:

Kommando zurück... sorry, eventuell könnte das doch stimmen, denn wenn ich gerade hin und her schalte sieht's über die Decklink doch etwas anders aus. Das heißt aber, dass man in Resolve tatsächlich nur über eine Decklink arbeiten sollte, wenn man es genau nimmt. Nix für ungut cantsin, aber mir war das bei Resolve nie so richtig klar.

VG






Antwort von Frank Glencairn:

pillepalle hat geschrieben:
.. dass wenn ich den Output verändere sich nicht nur der Vorschauonitor verändert, sondern auch die GUI Ansicht in der Color Page. Das ausgegebene Bild sieht dann über die GUI genauso aus wie über den Videoout des Referenzmonitors via Decklink. Deshalb fand ich cantsins Aussage, er würde die Farben in der GUI anders darstellen (z.B. nur in sRGB) ja auch so irritierend. Ich habe einfach den Eindruck dass aus einer 10bit Grafikarte genau die gleichen Farben herauskommen wie aus einer Decklink-Karte, vorausgesetzt man benutzt bei beiden einen Kalibrierten Monitor.
Ja was soll denn das GUI dann auch sonst machen?

Natürlich spiegelt das GUI eine Änderung im Output ebenfalls - also wenigstens irgendwie, was nicht heißt daß es richtig ist, halt nur anders.

Nebenbei gesagt möchte ich mal jemanden sehen, der sRGB von 709 im Blindtest unterscheiden kann, beide sind weitgehend Identisch was die Farben betrifft.
The chromaticity coordinates of the primaries are identical to those defined in sRGB standard. The white point is also D65. So far, the both color spaces seem to be identical. https://www.image-engineering.de/librar ... 09-vs-srgb


zum Bild


Die tatsächlichen Unterschiede liegen hauptsächlich im Gamma.
..this is where the difference comes to light. The sRGB transfer function is very close to, but not identical to Rec. 709.
Both transfer functions are defined piece-wise, with a small linear part in the beginning and a main power function part. Although, the exponent in the power function of sRGB transfer function is 2.4, sRGB is often said to have a decoding gamma of 2.2. Due to the influence of the linear part of the function, the median is close to 2.2.



Antwort von pillepalle:

@ Frank

sRGB und REC709 sind ja auch sehr ähnlich. Die Unterschiede im Gamma sieht man schon, aber es ist kein großer Unmterschied. Deutlicher wird das vor allem, wenn man größere Farbräume darstellt, vorausgesetzt der Monitor macht das mit.

VG



Antwort von Frank Glencairn:

pillepalle hat geschrieben:
Deutlicher wird das vor allem, wenn man größere Farbräume darstellt, vorausgesetzt der Monitor macht das mit.
Das stimmt zwar, aber das ist natürlich vor allem ne theoretische Anwendung. In 99% aller Fälle wird unsereiner am Ende mit 709 arbeiten, weil das ist was die meisten sehen können (und die meisten Endgeräte darstellen).



Antwort von cantsin:

pillepalle hat geschrieben:
Kommando zurück... sorry, eventuell könnte das doch stimmen, denn wenn ich gerade hin und her schalte sieht's über die Decklink doch etwas anders aus. Verwendest Du Resolve 17 oder 18?

Denn die Frage des TO war ja eigentlich, ob sich mit der in Resolve 18 neu hinzugekommenen Unterstützung für 10bit-Ausgabe im GUI-Viewer an diesem Verhalten etwas geändert haben könnte. Das würde mich auch interessieren.



Antwort von pillepalle:

@ cantsin

Die 18 Beta.

Das Ding ist aber, dass es über die GUI trotzdem etwas anders aussieht, als über die Decklink. Ist zwar kein riesen Unterschied, aber eben doch etwas anders. Im Zweifel richtet man sich nach der Decklink. Die Frage ist nur was Resolve in der GUI anders macht? Immer sRGB kann es irgendwie auch nicht sein.

VG



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
pillepalle hat geschrieben:
Deutlicher wird das vor allem, wenn man größere Farbräume darstellt, vorausgesetzt der Monitor macht das mit.
Das stimmt zwar, aber das ist natürlich vor allem ne theoretische Anwendung. In 99% aller Fälle wird unsereiner am Ende mit 709 arbeiten, weil das ist was die meisten sehen können (und die meisten Endgeräte darstellen). Wobei das jetzt noch stimmt. Mittel- und langfristig sehe ich die Reise doch in Richtung HDR und wide color gamuts gehen. Die Handy- und Tablet-Bildschirme können das ja schon, und einigermaßen aktuelle Flatscreen-TVs auch. Und bei aktuellen TV-Serien und sonstigen -Produktionen auf Netflix & Co. sieht man - finde ich - mit denen eigenen Augen einen echten Bildqualitätssprung, wenn HDR-Content gespielt wird.

Bei der spatialen bzw. Pixelauflösung war's ja früher nicht anders. Als wir hier vor 10-15 Jahren mit ersten HD-Kameras und Video-DSLRs angefangen haben, war das Zielmedium immer noch zu 90% SD-Video, ob nun auf DVD oder bei dem damaligen Briefmarkenstreaming von YouTube & Co, und waren mehr Auflösung im Kameramaterial vor allem 'nice to have' um mehr Reserven in der Nachbearbeitung zu haben. So ist das ja auch heute bei 10bit Log/Raw und wide gamuts beim Zielmedium SDR-Video. Könnte sich aber irgendwann mal ändern, vor allem wenn die Betriebssysteme endlich mal erweiterte Farbräume vernünftig nativ unterstützen. Apple hat ja den (wenn auch nicht gerade optimalen...) Anfang mit Display-P3 schon gemacht.



Antwort von Frank Glencairn:

Wobei das Apple P3 mit so nem schrägen Gamma daherkommt, daß es - außer auf Apple Geräten - überall falsch ausschaut. Außerdem nutze ich in der Praxis nicht mal 709 auch nur ansatzweise bis zum Anschlag aus, geschweige denn einen noch weiteren Farbraum.

Was HDR betrifft, bin ich noch nicht wirklich sicher ob das nicht auch den Weg von 3D TVs geht.
War ja damals bei dem Hype genau das selbe:

"Mittelfristig wird alles 3D, weil es gibt ja jetzt schon Geräte, es wird ja schon gesendet und auf YT und BR ist es auch schon und fast jeder neue TV kann das und blah...."

Ist aber nix draus geworden.

Ich denke so lange es da keinen wirklichen Standard gibt den alle Geräte sprechen, wird das auch nix, und selbst wenn, wer weiß...

Mein TV kann auch HDR allerdings nur das schnöde HDR10 - außer irgendwelche Demovideos auf YT bekomme ich also auf Netflix oder Prime quasi nix HDRiges zu sehen.

Aktuell gibt's 5 verschiedene Standards und noch ist kein Ende abzusehen (obwohl ich schätze daß es am Ende auf Dolby rauslaufen wird).

Schaumermal...



Antwort von SamSuffy:

wow, dass ging ja dann plötzlich mal schnell rund hier.
cantsin hat geschrieben:
Tu mir doch bitte mal den kleinen Gefallen und setze mal experimentellerweise sowohl den "Timeline Colorspace", als auch den "Output Color Space" in Resolve auf ein Log-Profil (z.B. Cineon oder S-Log). Das bedeutet, da sind wir uns sicher einig, eine drastische Veränderung der Farben. Warum ändern sich dann, nach dieser Einstellung, die Farben im GUI-Video-Viewer nicht? Also, ich arbeite in ACEScct v1.3 und setze als IDT entweder Panasonic v35 oder eben nichts, wenn ich (B)RAW Material habe. Ist aber eigentlich irrelevant, solange das eine standard ACES IDT ist.

Nach dem Zitat oben von cantsin dürfte ich keine Unterschiede in der GUI bzw. dem Video Clean Feed sehen, egal auf was ich die ODT stelle?

Dem ist aber bei weitem nicht so. Die Unterschiede sind drastisch!

Am besten fahre ich mit mit P3-D65 / P3-DCI (mit passendem Monitor Profil dazu). Da passen die Farben soweit ich beurteilen kann und vorallem die Sättigung dieser.

Wenn ich nun mit den selben Vorraussetzungen die ODT auf rec709 setze, ist alles übersättigt. Nicht extrem aber viel zu viel.
Zum testen habe ich dann mal die ODT auf sRGB gesetzt -> sieht aus wie rec709.

Das wiederspricht irgendwie dem Zitat.



Antwort von pillepalle:

Ja, im Moment ist das noch zuviel Hickhack mit HDR, weil es keinen einheitlichen Standard gibt. Bis sich da eines wirklich durchsetzt dauert es noch ein Weilchen.

Erschwerdend kommt noch dazu, das die Wiedergabe-Geräte immer vielfältiger werden und die Consumenten immer zahlreicher. Als man 'nur' für's Fernsehn gearbeitet hat, war es ja noch relativ einfach und es gab einen einheitlichen Standard für 'mehr oder weniger' einen Gerätetyp. Wenn ich was für's Netz mache, dann mache ich mittlerweile auch immer eine Mischkalkulation und schaue mir die Sachen z.B. auch mal auf dem Smartphone an. Wenn's da halbwegs gut ausschaut, dann passt es in der Regel auch für viele Nutzer.

VG






Antwort von cantsin:

SamSuffy hat geschrieben:
Das wiederspricht irgendwie dem Zitat. Gut möglich, dass sich Resolve unter ACES anders verhält - hatte ich nicht getestet!



Antwort von SamSuffy:

cantsin hat geschrieben:
Gut möglich, dass sich Resolve unter ACES anders verhält - hatte ich nicht getestet! Entschuldigung, hätte ich vielleicht erwähnen sollen.



Antwort von SamSuffy:

"Frank Glencairn" hat geschrieben:
Mein TV kann auch HDR allerdings nur das schnöde HDR10 - außer irgendwelche Demovideos auf YT bekomme ich also auf Netflix oder Prime quasi nix HDRiges zu sehen. HDR10 ist aber der doch der Standard bzw. der Fallback den alle anderen "Standards" gemein haben. Du solltest mit deinem HDR10 TV bei Prime auf jedenfall HDR bekommen, denn die streamen ja nur so und Netflix streamt dir auch HDR10 wenn dein TV kein Dolby Vision unterstützt da ja bei Dolby Vision HDR10 als Fallback dient.
Zudem gibt es oft nur minimale Unterschiede zwischen HDR10 und DV/HDR+.

Warum viele Leute keinen mehrwert in HDR sehen, verstehe ich nicht. Gerade wenn man z.B. Naturaufnahmen selbst schießt und dann in HDR exportiert, WOW !
Bei Arbeiten mit kreativer Bildgestaltung kann ich das ja noch etwas verstehen, aber selbst da ist es besser.

Wenn ich nur an Saving Private Ryan denke und dieser Film wurde nun bei Gott nicht mit wenig kreativem Look umgesetzt. Da kommt die 4k disc mit HDR so viel besser als die Blu-Ray und dass bestimmt nicht wegen der Auflösung. Der erweiterte Farbraum und die dynamik des Bildes bringen dieses Grading des Filmes nochmals so viel besser rüber und ich hab nicht Mal einen OLED sondern "nur" einen LCD (zugegeben, es ist ein High-End Sony XG95).



Antwort von Frank Glencairn:

Sicherlich Geschmacksache - persönlich hat mich HDR bisher noch nicht umgehauen.

Das beste an der Nummer ist noch das schwarze Schwarz bei entsprechenden TVs die das dann auch tatsächlich darstellen können, geht aber halt auch wieder nur in einem entsprechend dunklem Raum.

Farbmäßig seh ich jetzt nicht soooo die großen Unterschiede, es sei den man übersättigt alles bis zum Anschlag, wie bei den typischen Democlips.

Und die NITs - na ja, geschenkt, finde ich gerade in einer abgedunkelten Umgebung eher unangenehm, aber wenn's gefällt - warum nicht, jedem das seine.

Wobei Ryan gerade wegen seinem Bleach Bypass Proceccing eigentlich ein eher schlechtes Beispiel ist.



Antwort von pillepalle:

@ SamSuffy

Natürlich hat das einen Mehrwert und ist auch schöner, aber bisher eher großen Produktionen und Produktionshäusern vorbehalten. Klar kann man auch mit einem weniger Leuchtstarken Monitor irgendwie in HDR Graden, aber alleine ein echter und guter 10Bit HDR Monitor für's Grading, der einen fünfstelligen Betrag kostet, übersteigt das Budget der meisten Leute. Die Technik ist einfach noch sehr teuer und der Nutzen in vielen Bereichen noch nicht wirklich relevant. Das einzige was bisher bezahlbar ist sind günstige TV-Geräte die HDR fähig sind. Also eher Consumerware - und die nutzen dann einige auch für's Grading.

VG



Antwort von Frank Glencairn:

Ja, einige LG TVs gelten mittlerweile als "nicht optimal, aber gut genug" für's HDR Grading - zumal das was man da sieht, dem Endverbraucher Erlebnis relativ nahe kommen dürfte.



Antwort von cantsin:

Auf meinem LG OLED sehen auch heutige, auf 35mm gedrehte Produktionen in HDR klar und sichtbar besser aus - ich denke da z.B. an "Succession" (mit seiner IMHO fantastischen Kameraarbeit).

Und zwar weniger wegen HDR und seinem Kontrastumfang als solchem - der bei OLEDs sowieso nur sehr begrenzt erreicht wird -, sondern weil im HDR-Mode einfach das vorhandene Farbspektrum bzw. die mögliche Wiedergabequalität des OLED voll genutzt und nicht (wie bei Rec709) künstlich beschnitten wird.

Das ist einfach wie ein Foto, das auf einem besseren Fotodrucker gedruckt wurde, so dass man das volle Farbspektrum überhaupt erst sieht, ggü. einem Fotodruck aus dem Drogeriemarkt.



Antwort von Jörg:

cantsin schreibt Auf meinem LG OLED sehen auch heutige auf welchem Modell schaust Du?



Antwort von cantsin:

Jörg hat geschrieben:
cantsin schreibt Auf meinem LG OLED sehen auch heutige auf welchem Modell schaust Du? 55" C9.






Antwort von DKPost:

Ich habe den LG CX9LA, auch 55". Sowohl als TV zu Hause, als auch als Vorschau- und Gradingmonitor im Studio. Ich bin immer wieder von dem Bild begeistert. Und über die Software von Calman lässt sich der Screen auch hervorragend für Grading kalibrieren.



Antwort von cantsin:

DKPost hat geschrieben:
Ich habe den LG CX9LA, auch 55". Sowohl als TV zu Hause, als auch als Vorschau- und Gradingmonitor im Studio. Ich bin immer wieder von dem Bild begeistert. Und über die Software von Calman lässt sich der Screen auch hervorragend für Grading kalibrieren. Jetzt wäre natürlich die Frage: auch in/für Resolve, über die normale Grafikkarte? ;-)



Antwort von Jörg:

danke



Antwort von DKPost:

cantsin hat geschrieben:
DKPost hat geschrieben:
Ich habe den LG CX9LA, auch 55". Sowohl als TV zu Hause, als auch als Vorschau- und Gradingmonitor im Studio. Ich bin immer wieder von dem Bild begeistert. Und über die Software von Calman lässt sich der Screen auch hervorragend für Grading kalibrieren. Jetzt wäre natürlich die Frage: auch in/für Resolve, über die normale Grafikkarte? ;-) Über eine Intensity. Funktioniert in Resolve, Avid, Premiere, After Effects etc.
Hier ist die Software von Calman: https://store.portrait.com/consumer-sof ... or-lg.html



Antwort von SamSuffy:

cantsin hat geschrieben:
Und zwar weniger wegen HDR und seinem Kontrastumfang als solchem - der bei OLEDs sowieso nur sehr begrenzt erreicht wird -, sondern weil im HDR-Mode einfach das vorhandene Farbspektrum bzw. die mögliche Wiedergabequalität des OLED voll genutzt und nicht (wie bei Rec709) künstlich beschnitten wird. Genau so sehe ich das auch!

Wenn ich das richtig verstehe, dann pressen wir, wenn wir als rec709 abgeben (müssen), unseren zuvor oft sehr teuer erkauften (wortwörtlich) Dynamikbereich der Kamera in einen oft nichtmal halb so großen Dynamikbereich des rec709.
Soweit so bekannt aber nicht gut. Die "stops" sind ja immer noch da und wir müssen uns halt entscheiden, wieviel wir von den Spitzenlichtern und dem Schatten wegwerfen damit wir von den Mitten noch soviel haben, dass wir ein Bild schaffen können, dass unseren natürlichen Sehgewohnheiten entspricht.
Wir werfen also einiges weg.
Schau ich mir das original Material auf einem normalen SDR Gerät an, sei als log oder raw (Hauptsache nicht schon bei Aufnahme in rec709 gepresst), dann sehe ich auch den kompletten Dynamikbereich auf meinem SDR Gerät. Ich sehe in den Schatten diesen enormen Detailreichtum und in die Lichter sind nicht ausgebrannt doch das ganze ist komplett gefühlt kontrastarm und blaß, da wir ja nun nichts weggeschmissen haben, aber es auf einem SDR Gerät dargestellt wird.
Damit dies dann eben nicht mehr blaß und kontrastarm aussieht, gehen wir her und machen zuvor genanntes.

Ein wide gamut oder HDR Gerät kann viel mehr des Dynamikbereiches darstellen und wir müssen somit viel weniger (bei HLG Aufnahmen gar nichts) an Informationen wegschmeißen.
Nicht umsonst sieht HDR Material an einem SDR Gerät aus wie log.

Und jetzt dazu meine Frage:

Warum soll ich freiwillig mein Bild an Informationen beschneiden, wenn dies nicht nötig ist?!

Das war jetzt gerade off-topic, sorry dafür, habe mich verleiten lassen :)
cantsin hat geschrieben:
Jetzt wäre natürlich die Frage: auch in/für Resolve, über die normale Grafikkarte? ;-) Da bin ich leider noch nicht schlauer geworden. Habe auch bei BM gestöbert aber bis auf einen Einzeiler (der nur sagt, dass nun 10bit angezeigt werden können) nichts gefunden.

Denn auch schon in 17 und 16 konnte ich in ACES P3 als ODT wählen und empfand das Signal als passend.

Muss mal schauen, ob ich auf der mobilen Workstation die 17 zurückspiele und dann wechsel ich mal am Monitor zwischen mobil und Desktop.



Antwort von SamSuffy:

hat von euch jemand einen Tipp für Testmaterial dass in 8bit klares Banding aufweißt und in 10bit nicht mehr?



Antwort von pillepalle:

@ SamSuffy

Ich würde das nicht unbedingt wegschmeißen nennen. Es wird eher in einen anderen Farbraum übersetzt (transformiert). Dazu gibt es ja auch unterschiedliche Methoden die im Übersetzungsergebnis dann variieren. Natürlich stellt man in einem kleineren Farbraum numerisch weniger Farben dar, aber das muss nicht unbedingt schlecht aussehen, bzw schlecht wirken. In der Regel fällt es ja vor allem im direkten Vergleich auf und an der höheren Luminanz.

SamSuffy hat geschrieben:
Und jetzt dazu meine Frage:

Warum soll ich freiwillig mein Bild an Informationen beschneiden, wenn dies nicht nötig ist?! Man macht das um auf den keinsten gemeinsamen Nenner zu kommen. Dann können es alle richtig sehen. Wenn Du in HDR gradest, dann machst Du das, zumindest zur Zeit noch, nur für eine sehr kleine Elite, die mit spezieller Hardware und Einstellungen schaut. Für alle Anderen sieht es dann eher mittelmäßig aus.

VG



Antwort von dienstag_01:

Warum soll ich freiwillig mein Bild an Informationen beschneiden, wenn dies nicht nötig ist?! Wann ist es denn nötig? Wenn Zuschauer vor ihrem TV eine Sonnenbrille tragen, wie draussen an einem sonnigen Tag?



Antwort von SamSuffy:

dienstag_01 hat geschrieben:
Wann ist es denn nötig? Wenn Zuschauer vor ihrem TV eine Sonnenbrille tragen, wie draussen an einem sonnigen Tag? So sarkastisch wie das hier gemeint ist, so war ist es leider auch.
Das entgültige Wunschziel dieser Technik ist es ja tatsächlich die Wiedergabe so realitätsnah wie möglich zu schaffen.
Ich mein Dolby Vision wird aktuell schon bis 4000nits gemastered. Die meisten beklagen sich schon bei nichtmal 1000nits.

Aber es zwingt dich ja keiner soweit zu gehen. Aber rec709 zwingt dich dich zu beschränken.
Kannst auch in HDR dein geliebtes rec709 Bild schaffen, bleibt ja dir überlassen.

Aber Du hast halt dann die Wahl !






Antwort von Frank Glencairn:

SamSuffy hat geschrieben:
... wir müssen uns halt entscheiden, wieviel wir von den Spitzenlichtern und dem Schatten wegwerfen damit wir von den Mitten noch soviel haben, dass wir ein Bild schaffen können, dass unseren natürlichen Sehgewohnheiten entspricht.
Wir werfen also einiges weg. Wenn du weißt, was du tust wirfst du da gar nix weg, sondern du komprimierst es nur - die Anmutung bleibt die selbe, nur weniger gespreizt - oder vereinfacht gesagt, deine Highlights sind nicht so hell.



Antwort von Axel:

Bezüglich HDR dieses etwas unernste Video:


Meine momentane Einschätzung ist, dass man Naturdokus gar nicht zu hoch auflösend gucken kann. 8k HDR @ 120p? Bring it on!

Ansonsten tun OLED/QLED/Mini-LED-TVs dem kinogerechten SDR-Content nur gut durch die erwähnten besseren Schwarzwerte. Wir kümmern uns erstmal um den Grauschleier, der Rest wird sich zeigen.



Antwort von Jörg:

Meine momentane Einschätzung ist, dass man Naturdokus gar nicht zu hoch auflösend gucken kann. 8k HDR @ 120p? Bring it on! kannste dann gleich auch hierhin liefern lassen ...;-))



Antwort von SamSuffy:

So,
bin mir nun ziemlich, dass die 18er nun 10bit ausgibt :)

Hatte Screenshots gemacht, doch sobald ich das Tool zum Screenshots machen (Greenshot) aktiviere, Springt die Anzeige des Video Clean Feed auf 8bit zurück welches sich durch deutlich sichtbares Banding bestätigt.

Damit ihr euch aber natürlich selbst davon überzeugen könnt, darf dies jeder Interessent selbst an seinem Setup nachvollziehen :)
Hatte es zwar mit der 17er und der 18er gemacht, geht aber auch nur mit der 18er wenn man das 10bit Viewer Häckchen aktiviert oder deaktiviert (neustart Resolve erforderlich).

Zum selber nachvollziehen:
Auslösung: UHD
Farbmanagementeinstellungen: ACEScct, ACES 1.3, IDT lasst ihr leer, ODT hatte ich für meinen Monitor P3-D65, den Rest auf Standard
in der 18er noch den 10bit Viewer aktiviert (ist glaube ich von Haus aus so?!)

Im edit Modus dann einen Grauverlauf hinzugefügt, Zoom X auf 20, Position X auf 9000 (damit das Banding gut sichtbar wird).
In der 17er dann klares banding, in der 18er nichts davon zu sehen :)

PS: Denke das dies natürlich nur mit einem 10bit Monitor sichtbar wird ;)



Antwort von andieymi:

Hat sich etwas daran geändert, dass das mit AMD-Non-Workstation Karten nicht in 10-Bit möglich ist, weil kein OpenGL 10-Bit unterstützt ist, auch wenn die Anwedung das kann (sonder nur in DirectX-Anwendungen)?

Bei nVidia geht das ja mit Studiotreibern, bei AMD soweit ich weiß nicht.

Edit: Gerade am UI-Monitor mit AMD-RX-Karte wieder probiert. Windows sagt 10-Bit SDR, AMD-Treiber sagt 10bpc, raus kommen im Endeffekt trotzdem nur 8, das bezieht sich bei AMD lediglich auf DirectX-Inhalte.



Antwort von SamSuffy:

Habe nur Nvidia Karten.
Die Desktop Workstation hat eine RTX3080 drin, die gibt mir 10bit Farbtiefe aus, die Quadro P5200 in der mobilen Workstation gibt 12bit Farbtiefe aus.

Beide haben nun in Resolve kein Banding mehr unter Windows :)

Ist denn Resolve eine DX Anwendung?



Antwort von andieymi:

SamSuffy hat geschrieben:
Ist denn Resolve eine DX Anwendung? Nein, OpenCL (vorhin verwechselt mit OpenGL), CUDA oder Metal je nach Hardware. Hat per se nichts mit OpenCL oder CUDA zu tun, nur dass AMD keine Treiberaufteilung in Studio oder GameReady betreibt und damit das Feature gar nicht hat. Nvidia hat(te?) das früher auch nur im Studio-, nicht im GeForce/GameReady Treiber.

Und die Krux liegt in der Umsetzung: AMD behauptet zwar nirgends, dass sie das können, sagen aber auch nirgendwo offiziell das Gegenteil. Alles was Consumer sehen ist 10-Bit im Treiber eingestellt (wie bei nVidia) und 10-Bit unter Windows in den Monitoreinstellungen. Die Ausgabe, das was letztendlich am Panel ankommt erfolgt dann aber in 8-Bit.



Antwort von dienstag_01:

andieymi hat geschrieben:
SamSuffy hat geschrieben:
Ist denn Resolve eine DX Anwendung? Nein, OpenCL (vorhin verwechselt mit OpenGL), CUDA oder Metal je nach Hardware. Hat per se nichts mit OpenCL oder CUDA zu tun, nur dass AMD keine Treiberaufteilung in Studio oder GameReady betreibt und damit das Feature gar nicht hat. Nvidia hat(te?) das früher auch nur im Studio-, nicht im GeForce/GameReady Treiber.

Und die Krux liegt in der Umsetzung: AMD behauptet zwar nirgends, dass sie das können, sagen aber auch nirgendwo offiziell das Gegenteil. Alles was Consumer sehen ist 10-Bit im Treiber eingestellt (wie bei nVidia) und 10-Bit unter Windows in den Monitoreinstellungen. Die Ausgabe, das was letztendlich am Panel ankommt erfolgt dann aber in 8-Bit. Game-ready-Treiber unterstützen auch die 10bit-Ausgabe.



Antwort von andieymi:

dienstag_01 hat geschrieben:
Game-ready-Treiber unterstützen auch die 10bit-Ausgabe. Dann ist nvidia da scheinbar Welten vor AMD unterwegs wieder mal, oder sollte man sagen immer noch?






Antwort von dienstag_01:

andieymi hat geschrieben:
dienstag_01 hat geschrieben:
Game-ready-Treiber unterstützen auch die 10bit-Ausgabe. Dann ist nvidia da scheinbar Welten vor AMD unterwegs wieder mal, oder sollte man sagen immer noch? 10bit-Ausgabe auf einen zweiten Monitor in Resolve ohne Decklink gibt seit wann? Heute?
Welten ;)



Antwort von andieymi:

Um das geht's eigentlich den ganzen Thread schon.
Punkt ist: Mit nvidia geht das jetzt - da war der Flaschenhals Resolve - mit AMD nicht.

Soll man ja auch nicht überbewerten, die Decklinks haben schon eine Berechtigung.



Antwort von dienstag_01:

andieymi hat geschrieben:
Um das geht's eigentlich den ganzen Thread schon.
Punkt ist: Mit nvidia geht das jetzt - da war der Flaschenhals Resolve - mit AMD nicht.

Soll man ja auch nicht überbewerten, die Decklinks haben schon eine Berechtigung. Ja, mit einer Decklink ist man auf alle Fälle safe.



Antwort von Frank Glencairn:

Zumal der Preis mittlerweile sowieso ein Witz ist.
Für die ersten Decklinks haben wir damals 1800,- Öcken das Stück bezahlt.

Ich weiß nicht weshalb man sich den ganzen Stress antut, nur um ein paar Euro zu sparen.



Antwort von TheBubble:

Wenn der Monitor es kann, dann kann man 10bpc schon lange einstellen. Nur die Software muss es unterstützen.

Ansonsten kann Windows bzw. DirectX im Prinzip auch automatisches Dithering. Damit können 10 bpc Flächen auf 8 bpc Displays wiedergegeben werden. Der Unterschied ist schwer auszumachen.

10bpc sind übrigens nicht mit einem größeren Farbraum oder HDR zu verwechseln, 10 bpc geht auch bei sRGB.



Antwort von andieymi:

TheBubble hat geschrieben:
Wenn der Monitor es kann, dann kann man 10bpc schon lange einstellen. Nur die Software muss es unterstützen. Nicht die Software. Im Fall von AMD & Resolve (oder Photoshop, Premiere, quasi alles was nicht unter "Game" sondern "Programm" fällt, unterstützt die Software das, nicht jedoch der Treiber für die Anzeige der Software).

Alles was ich ausdrücken will: Nur weil man bei AMD 10-Bit einstellen kann und Windows 10-Bit anzeigt, kommen keine 10-Bit raus, außer Du bist hauptsächlich Zocker. Die 10-Bit beziehen sich rein auf DirectX PLUS Vollbild Anwendungen.

Ich wollte auch nie die Sinnhaftigkeit von Decklinks schmälern. Nur weil das ein Parade-Thread ist, wie Resolve ein Feature (10-Bit Ausgabe im Viewer) einführt (man kann es schwer nicht sinnvoll finden, selbst wenn man Decklinks nutzt, das ist einfach ein Feature, das ist sinnvoll, Punkt aus Ende, ob man es nutzen möchte oder nicht weil z.B. Decklink eh vorhanden), das allerdings Treiberseitig bei einem der 3 großen (mittlerweile muss man Apple/Metal da hinzuzählen) bei einem Großteil der Grafikkarten nicht unterstützt wird und das allerdings nirgendwo gesagt wird und auch die Anzeigen trügen, da man 10-Bit ja überall einstellen kann.

Hab selten so viele "Ja, aber" oder schlichtweg falsche Antworten auf ein tatsächlich vorhandenes Problem, das so auch nirgendwo erwähnt wird gelesen wie hier. Und nein, ich verwechsle auch nicht 10-Bit mit HDR und der Unterschied zwischen sRGB-Windows-Fensterdarstellung und Rec709 ist mir auch klar. Hier geht's nur um 10-Bit vs. 8-Bit.



Antwort von TheBubble:

andieymi hat geschrieben:
Alles was ich ausdrücken will: Nur weil man bei AMD 10-Bit einstellen kann und Windows 10-Bit anzeigt, kommen keine 10-Bit raus, außer Du bist hauptsächlich Zocker. Die 10-Bit beziehen sich rein auf DirectX PLUS Vollbild Anwendungen. Zu aktuellen dedizierten AMD-Grafikkarten und deren Einstellungen kann ich nicht so viel sagen, kann mir aber nur schwer vorstellen, dass sie sich völlig anders verhalten. Ich sehe allerdings keinen Unterschied zwischen Spielen und anderen Programmen: Das OS bietet Features an, Software kann sie nutzen, oder eben auch nicht.

Hier noch ein Link mit aktuellen Informationen (APIs, Verhalten vom Desktop Compositor uvm.):
https://docs.microsoft.com/en-us/window ... amic-range



Antwort von Huitzilopochtli:

"Frank Glencairn" hat geschrieben:
Zumal der Preis mittlerweile sowieso ein Witz ist.
Für die ersten Decklinks haben wir damals 1800,- Öcken das Stück bezahlt.

Ich weiß nicht weshalb man sich den ganzen Stress antut, nur um ein paar Euro zu sparen. Ich hab die keine Kosten und Mühen gescheut, bin aber sehr enttäuscht von der Decklink-Karte (Minimonitor 4K), nachdem die Wiedergabe deutlich langsamer ist, als wenn ich zwei Monitor an meiner Radeon VII über Display-Port hängen habe. Ich muss einige Nodes ausmachen, damit die Wiedergabe über Decklink flüssig läuft. Läuft alles über die Radeon, dann läuft alles flüssig, ohne irgendwelche Nodes auszumachen. Weiß jemand, ob der Clean Video Feed auch wirklich 10 bit RGB 444 ausgibt? Mein Monitor zeigt zumindest "10 bit RGB 444" an. Das einzige was mir aufgefallen ist, ist dass man im Gegensatz zur Decklinkausgabe und GUI-Ausgabe kein 3D-Lut für die Kalibrierung auswählen kann. Das könnte ich allerdings per HDMI über eine externe LUT-Box laufen lassen.

Arbeite aktuell mit macOS 11.6.8 Bis Sur.



Antwort von dienstag_01:

Huitzilopochtli hat geschrieben:
"Frank Glencairn" hat geschrieben:
Zumal der Preis mittlerweile sowieso ein Witz ist.
Für die ersten Decklinks haben wir damals 1800,- Öcken das Stück bezahlt.

Ich weiß nicht weshalb man sich den ganzen Stress antut, nur um ein paar Euro zu sparen. Ich hab die keine Kosten und Mühen gescheut, bin aber sehr enttäuscht von der Decklink-Karte (Minimonitor 4K), nachdem die Wiedergabe deutlich langsamer ist, als wenn ich zwei Monitor an meiner Radeon VII über Display-Port hängen habe. Ich muss einige Nodes ausmachen, damit die Wiedergabe über Decklink flüssig läuft. Läuft alles über die Radeon, dann läuft alles flüssig, ohne irgendwelche Nodes auszumachen. Weiß jemand, ob der Clean Video Feed auch wirklich 10 bit RGB 444 ausgibt? Mein Monitor zeigt zumindest "10 bit RGB 444" an. Das einzige was mir aufgefallen ist, ist dass man im Gegensatz zur Decklinkausgabe und GUI-Ausgabe kein 3D-Lut für die Kalibrierung auswählen kann. Das könnte ich allerdings per HDMI über eine externe LUT-Box laufen lassen.

Arbeite aktuell mit macOS 11.6.8 Bis Sur. Für mich klingt das nach einem Konfigurationsfehler, der Decklink ist es egal, wie viele Nodes das sind, die berechnet keinen einzigen davon. Effektberechnungen müssen auf der Radeon passieren.






Antwort von Huitzilopochtli:

dienstag_01 hat geschrieben:
Huitzilopochtli hat geschrieben:
Ich hab die keine Kosten und Mühen gescheut, bin aber sehr enttäuscht von der Decklink-Karte (Minimonitor 4K), nachdem die Wiedergabe deutlich langsamer ist, als wenn ich zwei Monitor an meiner Radeon VII über Display-Port hängen habe. Ich muss einige Nodes ausmachen, damit die Wiedergabe über Decklink flüssig läuft. Läuft alles über die Radeon, dann läuft alles flüssig, ohne irgendwelche Nodes auszumachen. Weiß jemand, ob der Clean Video Feed auch wirklich 10 bit RGB 444 ausgibt? Mein Monitor zeigt zumindest "10 bit RGB 444" an. Das einzige was mir aufgefallen ist, ist dass man im Gegensatz zur Decklinkausgabe und GUI-Ausgabe kein 3D-Lut für die Kalibrierung auswählen kann. Das könnte ich allerdings per HDMI über eine externe LUT-Box laufen lassen.

Arbeite aktuell mit macOS 11.6.8 Bis Sur. Für mich klingt das nach einem Konfigurationsfehler, der Decklink ist es egal, wie viele Nodes das sind, die berechnet keinen einzigen davon. Effektberechnungen müssen auf der Radeon passieren. Ja, hat mich auch gewundert, sollte aber alles richtig konfiguriert sein.wüsste jedenfalls nicht wo ich noch etwas anderes einstellen könnte.



Antwort von Frank Glencairn:

Ist vielleicht ein Mac spezifisches Problem, ich seh das hier auf keiner der Workstations - ist alles immer gleich schnell (oder langsam) - mit und ohne Decklink.



Antwort von Huitzilopochtli:

dienstag_01 hat geschrieben:
Huitzilopochtli hat geschrieben:


Ich hab die keine Kosten und Mühen gescheut, bin aber sehr enttäuscht von der Decklink-Karte (Minimonitor 4K), nachdem die Wiedergabe deutlich langsamer ist, als wenn ich zwei Monitor an meiner Radeon VII über Display-Port hängen habe. Ich muss einige Nodes ausmachen, damit die Wiedergabe über Decklink flüssig läuft. Läuft alles über die Radeon, dann läuft alles flüssig, ohne irgendwelche Nodes auszumachen. Weiß jemand, ob der Clean Video Feed auch wirklich 10 bit RGB 444 ausgibt? Mein Monitor zeigt zumindest "10 bit RGB 444" an. Das einzige was mir aufgefallen ist, ist dass man im Gegensatz zur Decklinkausgabe und GUI-Ausgabe kein 3D-Lut für die Kalibrierung auswählen kann. Das könnte ich allerdings per HDMI über eine externe LUT-Box laufen lassen.

Arbeite aktuell mit macOS 11.6.8 Bis Sur. Für mich klingt das nach einem Konfigurationsfehler, der Decklink ist es egal, wie viele Nodes das sind, die berechnet keinen einzigen davon. Effektberechnungen müssen auf der Radeon passieren. Anscheinend ist das wohl normal, da zwar die Effekte über die Videokarte gerechnet werden. wenn sie aber nicht direkt über die Videokarte ausgespielt werden, sondern über die Decklink-Karte muss der Stream einfach nochmal durch das Motherboard etc. Dem Ganzen kann man wohl nur mit extremer Rechenpower entgegenwirken. Für mich heißt das aber bye bye Decklink. Seh absolut KEINEN unterschied ob das signal über die grafikkarte per clean video feed oder die decklink-karte rausgeht. weder banding noch sonst irgendwas. und mein monitor sagt jedes mal brav 10bit RGB 444.



Antwort von dienstag_01:

Huitzilopochtli hat geschrieben:
dienstag_01 hat geschrieben:

Für mich klingt das nach einem Konfigurationsfehler, der Decklink ist es egal, wie viele Nodes das sind, die berechnet keinen einzigen davon. Effektberechnungen müssen auf der Radeon passieren. Anscheinend ist das wohl normal, da zwar die Effekte über die Videokarte gerechnet werden. wenn sie aber nicht direkt über die Videokarte ausgespielt werden, sondern über die Decklink-Karte muss der Stream einfach nochmal durch das Motherboard etc. Dem Ganzen kann man wohl nur mit extremer Rechenpower entgegenwirken. Für mich heißt das aber bye bye Decklink. Seh absolut KEINEN unterschied ob das signal über die grafikkarte per clean video feed oder die decklink-karte rausgeht. weder banding noch sonst irgendwas. und mein monitor sagt jedes mal brav 10bit RGB 444. Ich benutze keine Decklink, von anderen Monitoring Cards kenne ich aber nur die Anzeige des Videosignals, also sowas wie 1080p etc.. RGB444 kam da nicht vor. Der Witz von einer Monitoring Card ist ja, das die broadcastkonforme Signale ausgibt. RGB444 kenne ich da nicht. Vielleicht hab ich aber auch zu wenig Ahnung.



Antwort von Huitzilopochtli:

dienstag_01 hat geschrieben:
Huitzilopochtli hat geschrieben:


Anscheinend ist das wohl normal, da zwar die Effekte über die Videokarte gerechnet werden. wenn sie aber nicht direkt über die Videokarte ausgespielt werden, sondern über die Decklink-Karte muss der Stream einfach nochmal durch das Motherboard etc. Dem Ganzen kann man wohl nur mit extremer Rechenpower entgegenwirken. Für mich heißt das aber bye bye Decklink. Seh absolut KEINEN unterschied ob das signal über die grafikkarte per clean video feed oder die decklink-karte rausgeht. weder banding noch sonst irgendwas. und mein monitor sagt jedes mal brav 10bit RGB 444. Ich benutze keine Decklink, von anderen Monitoring Cards kenne ich aber nur die Anzeige des Videosignals, also sowas wie 1080p etc.. RGB444 kam da nicht vor. Der Witz von einer Monitoring Card ist ja, das die broadcastkonforme Signale ausgibt. RGB444 kenne ich da nicht. Vielleicht hab ich aber auch zu wenig Ahnung. Da.



Antwort von dienstag_01:

Aha.



Antwort von eli17:

Hallo,

ich habe diesen thread interessiert durchgelesen, da ich gerade dabei bin ein DCP mit Resolve für eine Kurzfilmpremiere zu erstellen.

Das erste Color Grading wurde im Rec709 Gamma 2.4 Timeline Farbraum durchgeführt. Meine Überlegung war nun für die Version fürs Kino eine weitere Timeline auf DCI P3 Gamma 2.6 einzustellen um dort nochmal bessere Anpassungen fürs Kino machen zu können. Der Monitor unterstützt diesen Farbraum zu 96% und er lässt sich als Profil direkt am Monitor anschließen.

Nur Frage ich mich nun nach Lektüre dieses Threads ob das überhaupt Sinn macht, da mir ja die Conclusio zu sein scheint, dass DaVinci - sofern man keine Decklink Karte besitzt (das tue ich nämlich nicht, der Monitor ist direkt an eine Nvidia GTX 1060 Karte angeschossen) - sowieso nur ein sRGB Signal an den Monitor ausgibt, ob jetzt GUI oder Video Clean Feed. Liege ich mit der Annahme richtig? Und ist es daher besser einfach im Rec709 Farbraum zu Graden und Davinci die Farbumwandlung zu machen? So hatte ich es in der Vergangenheit getan und die Ergebnisse auf der Leinwand sahen immer passabel aus.

LG



Antwort von Frank Glencairn:

Ja, am Ende des Tages wirst du kaum einen Unterschied sehen.