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 ;)
Was ist eigentlich mit den neuen BMD Video Assist Modellen ?
Irgendwo habe ich gelesen die sollen irgend wie nach einer Hollywood Norm, kalibriert sein ?
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 09:41
pillepalle hat geschrieben:@ 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 ;)
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
Meine Lieblingsfilme:
Es war ein Mahl in Amerika
Molkerei auf der Bounty
Dune - Der Würstchenplanet
"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 hat geschrieben: ↑Mo 25 Jan, 2021 09:41
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 ;)
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.
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
Alles vor und rund herum um die Kamera ist für einen guten Film viel, viel wichtiger als die Kamera selber.
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
Alles vor und rund herum um die Kamera ist für einen guten Film viel, viel wichtiger als die Kamera selber.
Zuletzt geändert von Darth Schneider am Mo 25 Jan, 2021 10:13, insgesamt 2-mal geändert.
cantsin hat geschrieben: ↑Mo 25 Jan, 2021 02:09
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.
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 09:55
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...
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.
mash_gh4 hat geschrieben: ↑Mo 25 Jan, 2021 10:27
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?
pillepalle hat geschrieben: ↑Mo 25 Jan, 2021 03:07
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.
Zuletzt geändert von mash_gh4 am Mo 25 Jan, 2021 11:13, insgesamt 2-mal geändert.
klusterdegenerierung hat geschrieben: ↑Mo 25 Jan, 2021 10:39
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.
klusterdegenerierung hat geschrieben: ↑Mo 25 Jan, 2021 10:39
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 hat geschrieben: ↑Mo 25 Jan, 2021 11:31
mash_gh4 hat geschrieben: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!
Zuletzt geändert von mash_gh4 am Mo 25 Jan, 2021 11:38, insgesamt 1-mal geändert.
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 hat geschrieben: ↑Mo 25 Jan, 2021 11:31
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 hat geschrieben: ↑Mo 25 Jan, 2021 00:56
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.
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 11:46
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
Meine Lieblingsfilme:
Es war ein Mahl in Amerika
Molkerei auf der Bounty
Dune - Der Würstchenplanet
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 11:46
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.
"Was von Natur aus flach ist, bläht sich auf!"
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 11:46
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 Farbein benötigen, das man 10Bit garnicht mit bekommt und erst in der NLE am footage sieht.
Keine Ahnung wie das heute ist, aber früher gab es überhaupt kein richtiges Farbmanagement in Windows. Deshalb hat man sich auch dazu entschieden sRGB als Standard zu nehmen, weil das einem unprofiliertem Bild sehr nahe kommt. Und der Grund das ein Bild z.B. unter Photoshop anders aussieht, als in Windows ist, weil man dort den Arbeitsfarbraum selber festlegen kann und Farben dort innerhalb eines gewissen Farbraums entsprechend interpretiert werden.
VG
Meine Lieblingsfilme:
Es war ein Mahl in Amerika
Molkerei auf der Bounty
Dune - Der Würstchenplanet
pillepalle hat geschrieben: ↑Mo 25 Jan, 2021 11:56
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 11:46
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
Das sind alles nur Behauptungen, Windows kann gar nichts darstellen, das kann nur der Monitor. Windows stellt Standardprofile bereit, nicht nur in sRGB. Aber safe ist diese Darstellung nur, wenn Anwendung, OS und Display korrekt miteinander kommunizieren.
andieymi hat geschrieben: ↑Mo 25 Jan, 2021 11:38
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.
Deckt sich auch mit meiner Praxis, und eben auch der Aussage der beiden Resolve-Chefentwickler. Was aber heisst, das über die GUI-Ausgabe nur sRGB funktionieren kann, es sei denn, man konfiguriert auch das ganze Betriebssystem in seinen Monitoreinstellungen auf ein selbstgebasteltes Profil mit erweitertem Farbraum und lebt damit, das dann 90% oder mehr aller Anwendungen extreme Falschfarben anzeigen.
Die Frage ist auch, ob pillepalles Workflow in anderen Anwendungen wie Photoshop - dort und am Monitor einen erweiterten Farbraum einstellen - wirklich sauber funktioniert, oder ab da nicht auch Grafikkartentreiber und im Betriebssystem (dann wahrscheinlich auf sRB) konfigurierte Monitorprofile/-kalibrierungen dazwischenfunken.
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 12:07
Das sind alles nur Behauptungen,
Du bist wieder in Deinem Element *lol* Der Monitor stellt das dar, was ihm das Monitorprofil vorgibt. Wie das Bild dargestellt wird, hängt davon ab, ob es Color-Managed ist, oder nicht, je nachdem wie man es betrachtet. Das Farbprofil im Bild ist ein anderes als das vom Monitor.
VG
Meine Lieblingsfilme:
Es war ein Mahl in Amerika
Molkerei auf der Bounty
Dune - Der Würstchenplanet
Für alle, die immer noch nicht verstehen, was da schief laufen kann, die können sich ja mal ein Foto in zwei verschiedenen Fotoviewern unter Windows anschauen, einmal Windows Foto und einmal einen, der farbmanagmentfähig ist. Das Foto darf ruhig sRGB sein ;)
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.
schau -- ich will nicht unbedingt sinnlos herumstreiten, sondern eben wirklich erfahrungen, sichtweisen und orientierungen für ein eigenes urteil mit anderen gleichgesinnte austauschen.
so gesehen kann ich einfach nur nocheinmal feststellen, dass es verdammt wenig mit farbmanagement im engeren sinne zu tun hat, display referred rec709 daten gemäß den gebräuchlichen konventionen und standards über die leitung an einen monitor zu schicken.
dagegen spricht man normalerweise dort von colormanagment, wo bildmaterial, dass für für die ausgabe in einen anderen farbraum vorgesehen ist, auf einem anzeigegerät, wie dem computer-monitor, korrekt dargestellt werden soll bzw. dabei sogar evtl. abweichungen des konkreten geräts gegenüber den benutzten farbstandards mitberücksichtigt werden.
was letzteres betrifft, schaut's eben im resolve jeseits der apple-ausgabe noch immer relativ unbefriediegend aus, und ersters ist technisch gesehen im grunde eine derart triviale aufgabe, dass man gar nicht lange drüber reden od. es als anspruchsvolle profi-anforderungen ausgeben sollte.
jeder besser pimperl-video-player sollte dazu in der lage sein, im full-screen-mode eine saubere unmodifizierte videoausgaben über eien ganz normale grafikkarte zu realisieren! -- in den meisten fällen sogar mit zusätzlichem aushandeln bzw. umkonfigurieren der passenden bildwiederholfrequenz, 10bit-untersützung via display-port und ggf. auch noch farbanpassungen über ICC-profile od. andere LUTs für div, zusätzliche korrekturen -- das ist jedenfalls in etwa der funktionsumfang, den man bspw. im mpv geboten bekommt.
die einschränkung auf die vollbild-darstelllung ist dabei wirklich extrem bedeutsam! -- dort verhält sich nämlich vieles völlig anders als im normalen GUI betrieb bzw. im kontext frei platzierter fenster oder grafik-toolkit-widgets -- aber auch die decklink-lösunge bietet ja bekanntlich nicht mehr als eben eine solche vollbild-darstellung am angeschlossenen schirm!
Zuletzt geändert von mash_gh4 am Mo 25 Jan, 2021 12:32, insgesamt 3-mal geändert.
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 11:46
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.
schau -- ich will nicht unbedingt sinnlos herumstreiten, sondern eben wirklich erfahrungen, sichtweisen und orientierungen für ein eigenes urteil mit anderen gleichgesinnte austauschen.
so gesehen kann ich einfach nur nocheinmal feststellen, dass es verdammt wenig mit farbmanagement im engeren sinne zu tun hat, display referred rec709 daten gemäß den gebräuchlichen konventionen und standards über die leitung an einen monitor zu schicken.
dagegen spricht man normalerweise dort von colormanagment, wo bildmaterial, dass für fpr die ausgabe in einen anderen farbraum vorgesehen ist, auf einem anzeigegerät, die dem computer-monitor, korrekt dargestellt werden soll bzw. dabei sogar evtl. abweichungen des konkreten geräts gegenüber den benutzten farbstandards mitberücksichtigt werden.
was letzteres betrifft, schaut's eben im resolve jeseits der apple-ausgabe noch immer relativ unbefriediegend aus, und ersters ist technisch gesehen im grunde eine derart triviale aufgabe, dass man gar nicht lange drüber reden od. es als anspruchsvolle profi-anforderungen ausgeben sollte.
jeder besser pimperl-video-player sollte dazu in der lage sein, im full-screen-mode eine saubere unmodifizierte videoausgaben über die GPU zu realisieren! -- in den meisten fällen sogar mit mzusätzlichem aushandeln bzw. umkonfigurieren einer einer passenden bildwiederholfrequenz, 10bit-untersützung via display-port und ggf. auch noch farbanpassungen über ICC-profile od. anderen LUTs für div, zusätzliche korrekturen -- das ist jedenfalls in etwa der funktionsumfang, denn man bspw. im mpv geboten bekommt.
die einschränkung auf die vollbild-darstelllung ist dabei wirklich extrem bedeutsam! -- dort verhält sich nämlich vieles völlig anders als im normalen GUI betrieb bzw. im kontext frei platzierter fenster oder grafik-toolkit-widgets -- aber auch die decklink-lösunge bietet ja bekanntlich nicht mehr als eben eine solche vollbild-darstellung am angeschlossenen schirm!
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 12:14
Für alle, die immer noch nicht verstehen, was da schief laufen kann, die können sich ja mal ein Foto in zwei verschiedenen Fotoviewern unter Windows anschauen, einmal Windows Foto und einmal einen, der farbmanagmentfähig ist. Das Foto darf ruhig sRGB sein ;)
Solange man PS bei sRGB belässt, funktioniert das ganze doch und wenn man seine Cam von Adobe RGB auf sRGB umstellt erst recht.
dienstag_01 hat geschrieben: ↑Mo 25 Jan, 2021 12:14
Für alle, die immer noch nicht verstehen, was da schief laufen kann, die können sich ja mal ein Foto in zwei verschiedenen Fotoviewern unter Windows anschauen, einmal Windows Foto und einmal einen, der farbmanagmentfähig ist. Das Foto darf ruhig sRGB sein ;)
Solange man PS bei sRGB belässt, funktioniert das ganze doch und wenn man seine Cam von Adobe RGB auf sRGB umstellt erst recht.
Und wenn Dein Arbeitsfarbraum sRGB ist und Dein Bild ein anderes Farbprofil enthält (z.B. AdobeRGB) fragt Dich die Software, wie es damit umgehen soll. Also das Profil in den Arbeitsfarbraum umwandeln, das Farbprofil behalten, ect. So funktioniert Color Management.
VG
Meine Lieblingsfilme:
Es war ein Mahl in Amerika
Molkerei auf der Bounty
Dune - Der Würstchenplanet
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
