cantsin
Beiträge: 8703

Re: Color Management in Resolve

Beitrag von cantsin » Di 26 Jan, 2021 12:55

dienstag_01 hat geschrieben:
Di 26 Jan, 2021 12:41
Ich glaube, dass ist ein Missverständnis. Im Handbuch steht das sinngemäß nur für Mac.
Du kannst es selbst ausprobieren: In der Windows- und Linux-Versionen von Resolve Dein Projekt im internen Viewer ansehen und die systemweite (sRGB-) Farbkalibrierung ändern - Resolve nimmt die Änderungen mit.

Auch die Farben, die z.B. der (color-managed) mpv-Mediaspieler bei aus Resolve rausgerenderten Videos anzeigt, stimmen mit den Farben im Resolve-Viewer zwar nicht 100% mathematisch, aber fürs menschliche Auge ununterscheidbar überein.

Das ist erst seit Resolve 15 der Fall, in den Versionen davor war die programminterne Videoanzeige in der Tat ein ziemlicher Blindflug (wie ich aus eigener Praxiserfahrung eines Resolve-Nutzers seit Version 10/2012 weiss).




mash_gh4
Beiträge: 4009

Re: Color Management in Resolve

Beitrag von mash_gh4 » Di 26 Jan, 2021 12:57

roki100 hat geschrieben:
Di 26 Jan, 2021 12:48
Eben, es ist so einfach. Doch in DR muss es doch eine Möglichkeit geben, diese auch passend auszuwählen.
einigen wir uns auf ein: "...sollte es doch eine Möglichkeit geben,..."

es wirklich nicht so, das dieser wunsch völlig neue wäre, nur scheint er auf der liste BMD-prioriträtenliste nicht besonders hoch oben zu stehen -- wie man ja überhaupt in sehr viele dingen dort keine große rücksicht auf die tatsächliche benutzeranforderzungen nimmt, sondern eben oft andere ziele verfolgt.




roki100
Beiträge: 6369

Re: Color Management in Resolve

Beitrag von roki100 » Di 26 Jan, 2021 12:59

Frank Glencairn hat geschrieben:
Di 26 Jan, 2021 12:55
roki100 hat geschrieben:
Di 26 Jan, 2021 12:32

man kann echt nicht verstehen, warum BMD es nicht schafft bei DR Installation ein paar *.icc's in dem Verzeichnis zu installieren und ein Color Management GUI in DR zu integrieren, wo man auf die *.icc dann zugreifen bzw. einstellen kann. Einfache Sache und alle sind zufrieden.
Weil Profis sowieso nen externen Monitor via Decklink haben, und es bei Youtubern völlig egal ist.
aber auch unter YouTuber gibt es Profis. Ich behaupte mal, dass in der Masse, DR mehr von YouTuber und Instragamer genutzt wird, als von den Profis, manche dabei die m.M. professioneller mit DR arbeiten...
Boris, die P6KPro hat all das was Dir bei P4K fehlt. Vergiss daher die P6KPro!




mash_gh4
Beiträge: 4009

Re: Color Management in Resolve

Beitrag von mash_gh4 » Di 26 Jan, 2021 13:04

cantsin hat geschrieben:
Di 26 Jan, 2021 12:55
Das ist erst seit Resolve 15 der Fall, in den Versionen davor war die programminterne Videoanzeige in der Tat ein ziemlicher Blindflug (wie ich aus eigener Praxiserfahrung eines Resolve-Nutzers seit Version 10/2012 weiss).
das schlimmste an diesen älteren versionen war die tatsache, dass auch innerhalb des programms tlw. völlig unterschiedliche farben zu sehen waren! :(

die viewer im color- und editing-mode haben jeweils andere methoden der video-ausgabe genutzt, die eben auch eine unterschiedliche farbwiedergabe nach sich gezogen haben.

aber damals wie heute -- auch wenn es mitterweile eher um die höchst undurchsichtige und unflexible konfiguration gehen dürfte --, bekommt man die selbe leier von wegen notwendiger decklink-karte etc. zu hören, obwohl es bei der geschichte eigentlich um ganz andere mängel der software geht.
Zuletzt geändert von mash_gh4 am Di 26 Jan, 2021 13:09, insgesamt 1-mal geändert.




roki100
Beiträge: 6369

Re: Color Management in Resolve

Beitrag von roki100 » Di 26 Jan, 2021 13:08

mash_gh4 hat geschrieben:
Di 26 Jan, 2021 12:57
roki100 hat geschrieben:
Di 26 Jan, 2021 12:48
Eben, es ist so einfach. Doch in DR muss es doch eine Möglichkeit geben, diese auch passend auszuwählen.
einigen wir uns auf ein: "...sollte es doch eine Möglichkeit geben,..."

es wirklich nicht so, das dieser wunsch völlig neue wäre, nur scheint er auf der liste BMD-prioriträtenliste nicht besonders hoch oben zu stehen -- wie man ja überhaupt in sehr viele dingen dort keine große rücksicht auf die tatsächliche benutzeranforderzungen nimmt, sondern eben oft andere ziele verfolgt.
im BMD Forum gab es bereits anfragen... nur wurden diese immer auf LUT verwiesen bzw. mit Kallibrierungstools passende LUT zu erstellen, was ja auch geht. Trotzdem, solche "Kleinigkeiten" kennt man auch schon von BMD Fusion und ignorierte Wünsche der Nutzer.
Boris, die P6KPro hat all das was Dir bei P4K fehlt. Vergiss daher die P6KPro!




pillepalle
Beiträge: 3618

Re: Color Management in Resolve

Beitrag von pillepalle » Di 26 Jan, 2021 13:09

Ich glaube eine Profi-Disskussion bringt einem an diesem Punkt nicht weiter. Es geht ja darum die Vorgänge und Zusammenhänge zu verstehen um offensichtliche Fehler zu vermeiden. Eine valide Option haben wir ja schon von Anfang an. Die über eine Decklink-Karte zu einem hardwarekalibrierbaren Monitor. Über die andere Option (die Anzeige über die Grafikkarte) wird eher spekuliert. Gerade weil Blackmagic im Handbuch solche Sätze wie 'eine richtige Darstellung wird nicht garantiert' fallen läßt. Wenn man es dann aber tatsächlich ausprobiert, kommt einem daran nichts 'unrichtig' vor. Man kann es nur nicht beweisen/garantieren. Deshalb denke ich ja, dass ich nach Installation einer Decklink Karte diesbezüglich mehr Gewissheit habe. Entweder die Bilder unterscheiden sich, oder sie tun es nicht.

Und das ist ja jetzt nicht nur eine akademische Diskussion. Der NAchteil einer Decklink Karte ist ja auch der, dass ich meinen Monitor damit ja quasi nur noch als Viewer verwenden kann, während ich über die Grafikkarte zwischen Timeline und Vollbild-Ansicht hin und her schalten kann. also ggf. auch mal mit einem Setup mit nur einem Monitor arbeiten könnte.

VG
Eigene Gedanken müsste man haben...

Zuletzt geändert von pillepalle am Di 26 Jan, 2021 13:11, insgesamt 1-mal geändert.




roki100
Beiträge: 6369

Re: Color Management in Resolve

Beitrag von roki100 » Di 26 Jan, 2021 13:10

mash_gh4 hat geschrieben:
Di 26 Jan, 2021 13:04
die viewer im color- und editing-mode haben jeweils andere methoden der video-ausgabe genutzt, die eben auch eine unterschiedliche farbwiedergabe nach sich gezogen haben.
Das ist heute noch so. Mit dem Unterschied, dass die Farbwiedergabe aber gleich bleibt. Interessant dass Du das auch weißt... Das wurde irgendwo auf steakunderwater.com erwähnt bzw. "die viewer im color- und editing-mode haben jeweils andere methoden der video-ausgabe".
Boris, die P6KPro hat all das was Dir bei P4K fehlt. Vergiss daher die P6KPro!

Zuletzt geändert von roki100 am Di 26 Jan, 2021 13:19, insgesamt 5-mal geändert.




cantsin
Beiträge: 8703

Re: Color Management in Resolve

Beitrag von cantsin » Di 26 Jan, 2021 13:12

pillepalle hat geschrieben:
Di 26 Jan, 2021 12:32
Ja, aber an dieser Stelle scheiden sich eben unsere Geister :) Wenn es stimmt was Du sagst, dann könnte man als Output Color Space nur sRGB Einstellen und würde bei allen anderen Einstellungen die Darstellung in der Timeline und im Viewer nicht mehr richtig angezeigt bekommen. Das erscheint beim ändern des Output Color Spaces in der Praxis aber nicht der Fall zu sein.
Hast Du das konkret getestet? Also z.B. als Output Color Space in Resolve P3 eingestellt, und an Deinem Monitor auch P3, und dann eine zuverlässige Ausgabe erhalten?

AFAIK, und wenn ich Deine Informationen über Photoshop richtig verstehe, liegt der Unterschied so:
- Photoshop kann in seiner Bildschirmausgabe die Betriebssystem-Routinen bzw. im Betriebssystem konfigurierten Farbprofile komplett links liegen lassen und an den Monitor direkt ein Signal im konfigurierten Farbraum (wie z.B. P3) schicken.
- Resolve geht in seiner internen Bildschirmausgabe (also seinem GUI-Timeline-Viewer, also nicht der Decklink-Ausgabe) über die Standard-Routinen/Pipeline des Betriebssystems, und zwar (bei Windows) so, wie in dem zuvor geposteten Microsoft-Schema:

Bild

Bei Linux wäre das dementsprechend der Grafikausgabestack von X11/Wayland + Kernel-GPU-Treiber.

Sowohl bei Windows, als auch bei Linux beziehen sich alle im System installierten Monitorprofile und -Kalibrierungen auf sRGB (mit der einzigen Ausnahme des Consumer-HDR in neueren Windows 10-Versionen), während es bei MacOS in der Betriebssystem-Display-Konfiguration tatsächlich eine schöne, systemweite "P3"-Option gibt (von der ich allerdings nicht weiss, wie gut sie in der Praxis mit Standardprogrammen wie Webbrowsern funktioniert).

Wenn Du jetzt also in (Windows-/Linux-) Resolve als Ausgabefarbraum P3 einstellst, und an Deinem Monitor auch P3, und Dein Video im Resolve-GUI-Viewer betrachtest, wird es trotzdem durch den ganzen Betriebssystem-Grafikstack geschickt und greifen alle Profile, Kalibrierungen bzw. (faktischen) Farbverbiegungen, die aber für sRGB gedacht sind. Das ist effektiv das gleiche wie die Nutzung einer für Rec709 designten LUT in einem P3-Projekt, oder wie die Nutzung einer ASCII-Tastaturtabelle in einer Unicode-Textverarbeitung.

Wie gesagt, würde mich ehrlich interessieren, was Deine Praxisresultate bei so einem Workflow sind. (Auch, wie Du Deinen Monitor im P3-Farbraum kalibrierst.)




pillepalle
Beiträge: 3618

Re: Color Management in Resolve

Beitrag von pillepalle » Di 26 Jan, 2021 13:18

@ catsin

Das werde ich machen sobald ich eine Decklink Karte habe (in einer guten Woche). Dann wird sich zeigen wie brauchbar das arbeiten über die Grafikkarte im Vergleich zum Arbeiten über die Karte ist. Und ob ein Grading in P3 sinnvoll sein kann, werde ich bei Carsten im Kino testen. Denn dann wird man recht genau sehen wo die Unterschiede zwischen Display und Projektion liegen und wie brauchbar das Ganze in der Praxis sein kann. Ich kann mir vorstellen, das man einen besseren Bildeindruck beim graden bekommt, wenn man in einer dunkelen Umbegung mit einem dunkelen Monitor gradet, als wenn man mit einem helleren Monitor in einer helleren Umgebung gradet.

VG

PS: Der P3 Farbraum ist mit einer Helligkeit von 48cd/m2, einem Gamma von 2.6 und einer Farbtemperatur von D65 kalibriert. Ich kann diese Parameter aber auch ändern, z.B. wenn Carstens Kino/System auf D60 kalibriert ist.
Eigene Gedanken müsste man haben...




Bluboy
Beiträge: 1507

Re: Color Management in Resolve

Beitrag von Bluboy » Di 26 Jan, 2021 13:24

Ohne Color Korrektur schauts meisten recht Lila aus ;-))
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von Bluboy am Di 26 Jan, 2021 13:27, insgesamt 1-mal geändert.




roki100
Beiträge: 6369

Re: Color Management in Resolve

Beitrag von roki100 » Di 26 Jan, 2021 13:27

Blueboy, du hast echt ne coole Friseur!
Boris, die P6KPro hat all das was Dir bei P4K fehlt. Vergiss daher die P6KPro!




pillepalle
Beiträge: 3618

Re: Color Management in Resolve

Beitrag von pillepalle » Di 26 Jan, 2021 13:27

Deshalb sollte man ja auch von Anfang an alle Farbräume richtig einstellen. Wenn ich meinen Arbeitsfarbraum von REC709 zu P3 ändere, dann wärde der Input Farbraum ja auch schon falsch übersetzt worden. Ich glaube man muss hier schon versuchen sauber zu arbeiten und nicht wild an den Einstellungen herum spielen.

VG
Eigene Gedanken müsste man haben...




Bluboy
Beiträge: 1507

Re: Color Management in Resolve

Beitrag von Bluboy » Di 26 Jan, 2021 13:31

Input UND Output
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.




carstenkurz
Beiträge: 4899

Re: Color Management in Resolve

Beitrag von carstenkurz » Di 26 Jan, 2021 13:32

Nur mal als Erläuterung für die Spätgeborenen:

Wieso folgt die Videoausgabe einer Anwendung ggfs. anderen 'Farbregeln' als die GUI Elemente, aka, warum durchlaufen GUI Elemente (inkl. z.B. Vorschaubilder/Thumbnails) das Colormanagement des Betriebssystems (oder auch ohne Colormanagement Gradations-/Farbbalanceregler des Betriebssystems/der Grafikkarte), aber die Videoausgabe im gleichen Programm nicht?

Dafür gibts verschiedene Gründe. Einer der ältesten sind frühe Ansätze der Videobeschleunigung. Mit den ersten grafischen Betriebssystemen haben Anwendungen nicht mehr direkt in den Videospeicher der Grafikkarte geschrieben, sondern sind den Umweg über den Grafikkartentreiber gegangen. Das war zunächst ein Vorteil - Anwendungen mussten nicht mehr wissen, was für eine Grafikkarte im System steckte, welche Farbtiefe, wie der Videospeicher organisiert ist. Das Betriebssystem meldete einfach global 'Hier ist ein Fenster mit der Auflösung x/y und der Farbtiefe z', die Anwendung kann dort mit standardisierten Funktionen reinschreiben.

Später hat das Betriebssystem dann auch höhere Teilfunktionen übernommen, Linien, Fensterelemente,Text, etc. Da alle Schreibvorgänge durch eine einheitliche Schnittstelle liefen, war es auch kein Problem, hinter diese Schnittstelle eine globale Farbkorrektur zu setzen, die alle Zeichenvorgänge dann zwangsläufig durchlaufen mussten. Es gab schlicht keinen Weg daran vorbei. Bei frühen Betriebssystemen ohne Colormanagement war das aber oft nur eine einfache Gradationskontrolle oder Farbbalance.

Das funktionierte so lange, wie es um rein grafische Elemente ohne Echtzeitanforderungen ging. Als die ersten Anwendungen für Videobearbeitung aufkamen, war diese etablierte Schnittstelle einfach zu langsam, um 30 hochauflösende 24Bit Bilder pro Sekunde an die Grafikkarte zu übertragen. Man musste viel schneller werden. Und die erste Lösung dafür war, für Videoanwendungen den Weg über die normale Kooperation von GUI und Grafikkartentreiber zu umgehen, und der Videoanwendung wieder zu erlauben, direkt in den Grafikkartenspeicher zu schreiben. Der Videoplayer konnte mit optimierten maschinennahen Funktionen einen kompletten Bildblock direkt in den Speicher der Grafikkarte übertragen und mit hoher Geschwindigkeit updaten. Damit war die Videowiedergabe wieder schnell genug, aber die Ausgabe ging an der Grafikschnittstelle des Betriebssystems vorbei und berücksichtigte keinerlei Farbkontrolle mehr. Das musste die Videoanwendung dann selbst erledigen.

Aus diesen Mechanismen entwickelten sich dann später die diversen APIs für schnelles Video und 3D, und diesem Wildwuchs (zumindest unter Windows) hat man es zu verdanken, dass Videoanwendungen heutzutage eine Vielzahl alter und neuer solcher Spezial-APIs benutzen können, die jeweils unterschiedlich mit der Farbwiedergabe umgehen. Wer mal in die Videoausgabeoptionen seines Windows VLC Players reingeschaut hat und eine bewusste Entscheidung treffen wollte, welche am besten zu benutzen ist, weiss wovon ich rede.

Bild
and now for something completely different...

Zuletzt geändert von carstenkurz am Di 26 Jan, 2021 13:57, insgesamt 5-mal geändert.




mash_gh4
Beiträge: 4009

Re: Color Management in Resolve

Beitrag von mash_gh4 » Di 26 Jan, 2021 13:32

pillepalle hat geschrieben:
Di 26 Jan, 2021 13:09
Eine valide Option haben wir ja schon von Anfang an. Die über eine Decklink-Karte zu einem hardwarekalibrierbaren Monitor. Über die andere Option (die Anzeige über die Grafikkarte) wird eher spekuliert.
auch wen der Frank od. auch ein Marc Wielage vermutlich nie müde werden, von ihren decklink-karten und deren notwendig zu schwärmen, obwohl sie damit ohnehin nur den denkbar einfachsten rahmenbedingungen (rec709 + hw-kalibriertes display) arbeiten.

dass ihre ausführungen bzw. der notwendigkeit solcher hardware nicht wirklich haltbar ist, kann man evtl. auch daran ersehen, dass bspw. einer der bedeutsamsten anbieter für anspruchsvolle farbkalibrierungssoftware in der filmindustrie nicht etwa PCs mit decklinkkarten, sondern kleine, einfache und denkbar billige linux singelboard-computer als pattern generator empfieht, weil man eben auch über das dortige HDMI signal ganz genau die selben werte an einen monitor zu schicken vermag wie über entsprechende broadcast ausgabekarten. letztere machen meines erachtens nur mehr dort errnsthaft sinn, wo man SDI-connectivity braucht, weil es ja mittlerweile keine nvidia-GPUs mit derartigen anschlussmöglichkeiten mehr gibt. ansonsten kann man mit guter software und gebräuchlichen GPUs genau das selbe -- od. eigentlich sogar mehr(!) -- erreichen.




cantsin
Beiträge: 8703

Re: Color Management in Resolve

Beitrag von cantsin » Di 26 Jan, 2021 13:38

mash_gh4 hat geschrieben:
Di 26 Jan, 2021 13:32
pillepalle hat geschrieben:
Di 26 Jan, 2021 13:09
Eine valide Option haben wir ja schon von Anfang an. Die über eine Decklink-Karte zu einem hardwarekalibrierbaren Monitor. Über die andere Option (die Anzeige über die Grafikkarte) wird eher spekuliert.
auch wen der Frank od. auch ein Marc Wielage vermutlich nie müde werden, von ihren decklink-karten und deren notwendig zu schwärmen, obwohl sie damit ohnehin nur den denkbar einfachsten rahmenbedingungen (rec709 + hw-kalibriertes display) arbeiten.
@mash_gh4, pillepalle geht es ja nicht ums Arbeiten in Rec709/sRGB, sondern in einem erweiterten Farbraum wie P3, mit Videoansicht/-vorschau in P3 sowohl auf dem Monitor, als auch in Resolves internem GUI-Viewer. Also einen kompletten P3-Preview-Workflow auf reiner Computerebene, mit Windows oder Linux. Wie würdest Du das denn angehen?




dienstag_01
Beiträge: 10952

Re: Color Management in Resolve

Beitrag von dienstag_01 » Di 26 Jan, 2021 13:41

cantsin hat geschrieben:
Di 26 Jan, 2021 12:55
dienstag_01 hat geschrieben:
Di 26 Jan, 2021 12:41
Ich glaube, dass ist ein Missverständnis. Im Handbuch steht das sinngemäß nur für Mac.
Du kannst es selbst ausprobieren: In der Windows- und Linux-Versionen von Resolve Dein Projekt im internen Viewer ansehen und die systemweite (sRGB-) Farbkalibrierung ändern - Resolve nimmt die Änderungen mit.

Auch die Farben, die z.B. der (color-managed) mpv-Mediaspieler bei aus Resolve rausgerenderten Videos anzeigt, stimmen mit den Farben im Resolve-Viewer zwar nicht 100% mathematisch, aber fürs menschliche Auge ununterscheidbar überein.

Das ist erst seit Resolve 15 der Fall, in den Versionen davor war die programminterne Videoanzeige in der Tat ein ziemlicher Blindflug (wie ich aus eigener Praxiserfahrung eines Resolve-Nutzers seit Version 10/2012 weiss).
Das hat ja nichts mit Farbmanagment zu tun, dass gelingt die auch mit jeder nicht-farbmanagment Software (ich meine den Punkt mit der sRGB-Umstellung).
Zuletzt geändert von dienstag_01 am Di 26 Jan, 2021 13:49, insgesamt 1-mal geändert.




carstenkurz
Beiträge: 4899

Re: Color Management in Resolve

Beitrag von carstenkurz » Di 26 Jan, 2021 13:43

pillepalle hat geschrieben:
Di 26 Jan, 2021 13:09
Und das ist ja jetzt nicht nur eine akademische Diskussion. Der NAchteil einer Decklink Karte ist ja auch der, dass ich meinen Monitor damit ja quasi nur noch als Viewer verwenden kann, während ich über die Grafikkarte zwischen Timeline und Vollbild-Ansicht hin und her schalten kann. also ggf. auch mal mit einem Setup mit nur einem Monitor arbeiten könnte.
Du hast immerhin die Möglichkeit, System-GPU und Decklink parallel an den Eizo Monitor anzuschließen, und dann zu wählen. Es macht sicher keinen Spaß, die komplette Bearbeitung bei 48cd/qm in einem abgedunkelten Raum durchzuführen. Ich denke es ist zulässig, in diesem P3 Modus nur die finalen Bearbeitungsschritte oder die Feinarbeit, respektive kritische Szenen, und die 'Endabnahme' durchzuführen. Da brauchst Du dann natürlich noch einen zweiten Monitor fürs GUI, aber das kann ja wirklich ein einfacher sein.
and now for something completely different...




Frank Glencairn
Beiträge: 12883

Re: Color Management in Resolve

Beitrag von Frank Glencairn » Di 26 Jan, 2021 13:44

Mash, so sehr ich deine fachliche Expertise schätze, so sehr nervt deine Linux Obsession.
Und ja, ich versteh schon daß das toll ist und alles, nur nutzt hier außer die kaum jemand Linux zur Videobearbeitung.
Deshalb sind die meisten deiner - durchaus interessanten und klugen - Einlassungen meistens leider für die Katz, weil - Win oder Mac.

Resolve (mit Decklink und entsprechendem Monitor) spielt ganz weit oben in der internationalen Oberliga mit, und die bekommen alle ihre Filme völlig problemlos mit Resolve für Kino/TV undwasnichtalles gegraded - du suchst hier also nach einem Problem für deine Lösung.
Daß die Kombination seit Jahren anstandslos funktioniert, steht völlig außer Frage.

Wenn externe Lösungen (Egal ob Decklink, Aja oder sonstwas) so völlig unnütz sind, warum sind sie dann in allen großen Studios der Standard, und warum diskutieren wir hier seitenlang darüber - einfach mit dem Computerbildschirm graden und fertig, geht ja mit dem tollen OS-eigenen Colormanagement oder sonst einer Softwarekrücke ganz wunderbar, laut deiner Aussage.
http://frankglencairn.wordpress.com/

Finger weg von der PocketPro Boris!




carstenkurz
Beiträge: 4899

Re: Color Management in Resolve

Beitrag von carstenkurz » Di 26 Jan, 2021 13:51

mash_gh4 hat geschrieben:
Di 26 Jan, 2021 13:32
dass ihre ausführungen bzw. der notwendigkeit solcher hardware nicht wirklich haltbar ist, kann man evtl. auch daran ersehen, dass bspw. einer der bedeutsamsten anbieter für anspruchsvolle farbkalibrierungssoftware in der filmindustrie nicht etwa PCs mit decklinkkarten, sondern kleine, einfache und denkbar billige linux singelboard-computer als pattern generator empfieht, weil man eben auch über das dortige HDMI signal ganz genau die selben werte an einen monitor zu schicken vermag wie über entsprechende broadcast ausgabekarten.
Das Argument ist bullshit, und das weisst Du auch. Sofern mir die nötigen Durchgriffsmöglichkeiten auf die Grafikausgabe gewährt werden (da braucht's nicht viel), reicht natürlich notfalls ein Raspberry PI Zero als Testsignalgenerator. Und ähnlich rudimentär kriegt man auch die Zugriffe für so eine Spezialanwendung unter einem notfalls handgetunten Linux hin.

Das ist aber was ganz Anderes, als bei einer Videoschnittanwendung aus verschiedensten Gründen auf den Unterbau eines vollständigen Betriebssystems mit nicht umgehbarer Treiberarchitektur und Grafik-APIs setzen zu MÜSSEN. Und da beisst sich deine Argumentation in den ***, genau DESWEGEN gibt es die Decklink Karten, weil BMD bei denen vollkommen frei selbst entscheiden kann, was auf die Leitung geht - genau wie am Raspberry PI.

Nebenbei hat HDMI im Bereich professionellen Masterings im Grunde halt auch nix zu suchen. Dolbys sündhaft teurer Referenzmonitor hat nichtmal einen einzigen HDMI Eingang.
and now for something completely different...

Zuletzt geändert von carstenkurz am Di 26 Jan, 2021 14:10, insgesamt 3-mal geändert.




dienstag_01
Beiträge: 10952

Re: Color Management in Resolve

Beitrag von dienstag_01 » Di 26 Jan, 2021 13:54

Mit welchen Hilfsmitteln generiert Windows10 eigentlich ein Video Overlay wie den Clean Video Feed.
Der wird nämlich bei der Verwendung von Luts für den Viewer nicht angesprochen.




cantsin
Beiträge: 8703

Re: Color Management in Resolve

Beitrag von cantsin » Di 26 Jan, 2021 14:13

carstenkurz hat geschrieben:
Di 26 Jan, 2021 13:51
Das ist aber was ganz Anderes, als bei einer Videoschnittanwendung aus verschiedensten Gründen auf den Unterbau eines vollständigen Betriebssystems mit nicht umgehbarer Treiberarchitektur und Grafik-APIs setzen zu MÜSSEN.
Ja - und ich frag' mich, wie Photoshop das offenbar anders hinkriegt... Oder liegt das in der Natur von Videoanwendungen, weil deren Grafikausgabe zwangsläufig Hardware-/GPU-beschleunigt sein muss, und die darum nicht an diesen APIs vorbeikönnen?




pillepalle
Beiträge: 3618

Re: Color Management in Resolve

Beitrag von pillepalle » Di 26 Jan, 2021 14:17

Eigentlich ist Photoshop auch Grafikkartenbeschleunigt...

VG
Eigene Gedanken müsste man haben...




carstenkurz
Beiträge: 4899

Re: Color Management in Resolve

Beitrag von carstenkurz » Di 26 Jan, 2021 14:19

Das ist ne gute Frage, aber, schon in den 1990ern konnte ich meine Targa-Karte als Video-Out-Karte in Photoshop platzieren. Es gab schon immer gute Gründe für solche Lösungen.

Im Übrigen ist Photoshop kein Videoeditor. Es benutzt zwar auch bestimmte Beschleunigungsfunktionen von Grafikkarten, aber Resolve ist derartig GPU zentriert im Vergleich, dass man annehmen darf, dass man sich bei Photoshop die Performanceverluste durch das Farbmanagement leisten kann.
and now for something completely different...

Zuletzt geändert von carstenkurz am Di 26 Jan, 2021 14:22, insgesamt 1-mal geändert.




cantsin
Beiträge: 8703

Re: Color Management in Resolve

Beitrag von cantsin » Di 26 Jan, 2021 14:22

carstenkurz hat geschrieben:
Di 26 Jan, 2021 14:19
Im Übrigen ist Photoshop kein Videoeditor.
Ja, aber laut pillepalle geht damit ein nativer Monitoring-Workflow in (ggü. sRGB) erweiterten Farbräumen, mit dem normal an den Computer angeschlossenen Monitor.

[sorry, meine obige Gegenfrage hat sich erübrigt, nach dem Du Deine obige Antwort editiert hattest.]
Zuletzt geändert von cantsin am Di 26 Jan, 2021 14:24, insgesamt 1-mal geändert.




pillepalle
Beiträge: 3618

Re: Color Management in Resolve

Beitrag von pillepalle » Di 26 Jan, 2021 14:23

@ catsin

Genau das ist der Eindruck den ich habe. Aber wissen werde ich es erst, wenn ich es anders ausprobiere.

VG

PS: Was eben nervig an dem ganzen Thema ist, ist das so wenig Informationen dazu verfügbar sind. Je 'professioneller' ein Workflow wird, desto geheimnisvoller scheint er auch zu werden. Und Blackmagic fürt (ab Version 16 glaube ich) extra ein Resolve Color Management ein, um es dann aber bei der Ausgabe auf dem Monitor via Karte wieder zu umgehen. Das ist eigentlich nicht der Sinn eines Color Managements. Es geht doch gerade darum Farbverbindlich arbeiten zu können.
Eigene Gedanken müsste man haben...

Zuletzt geändert von pillepalle am Di 26 Jan, 2021 14:30, insgesamt 2-mal geändert.




cantsin
Beiträge: 8703

Re: Color Management in Resolve

Beitrag von cantsin » Di 26 Jan, 2021 14:28

Wahrscheinlich wird's so kommen, dass sich besseres Farbmanagement und konsistente, native, kopfschmerz- und bastelfreie Unterstützung ggü. sRGB erweiterter Farbräume erst dann durchsetzt, wenn das ein Thema für Gaming und Gamer wird, und die Industrie dadurch einen kritischen Massenmarkt erreicht.

Auch unsere typischen Videoschnitt-Rechner sind ja nur Abfallprodukte der Gaming-Industrie. (Und der hat eben 8bit sRGB bisher gereicht.)
Zuletzt geändert von cantsin am Di 26 Jan, 2021 14:29, insgesamt 1-mal geändert.




carstenkurz
Beiträge: 4899

Re: Color Management in Resolve

Beitrag von carstenkurz » Di 26 Jan, 2021 14:29

Photoshop muss halt nicht die Anforderung erfüllen, 4k/60p garantiert ruckelfrei durch sein Farbmanagement schleusen zu müssen. Und ein paar andere Sachen hat Resolve nebenher ja auch noch zu tun.
and now for something completely different...




dienstag_01
Beiträge: 10952

Re: Color Management in Resolve

Beitrag von dienstag_01 » Di 26 Jan, 2021 14:32

Das Farbmanagment von Photoshop basiert auf ICC Profilen. Resolve macht das nur auf dem Mac (wenn ich das Handbuch richtig verstehe).
Mit Hardwarebeschleunigung hat das nichts zu tun.




carstenkurz
Beiträge: 4899

Re: Color Management in Resolve

Beitrag von carstenkurz » Di 26 Jan, 2021 14:47

pillepalle hat geschrieben:
Di 26 Jan, 2021 14:17
Eigentlich ist Photoshop auch Grafikkartenbeschleunigt...
Das ist jetzt nur geraten oder vermutet - Photoshop kann es sich leisten, einige/wenige komplexe Funktionen (im Grunde ja nur Filter/Plugins) beschleunigt auf der Grafikkarte laufen zu lassen, das daraus resultierende Bild aber wieder von der CPU entgegen nehmen zu lassen und für die Ausgabe durch das CPU/OS basierte Farbmanagement zu schicken. Ob der Vorgang insgesamt 1ms oder 100ms dauert, ist egal.

Ich bezweifle, dass Resolve das so macht, da wird der Weg direkt von der GPU auf die Ausgabe gehen, und die Ausgabe 'kennt' daher das Farbmanagement des Betriebssystems garnicht. Dürfte jedenfalls wesentlich einfacher sein, so die Echtzeit-Performanceanforderungen zu erfüllen. Man darf vermuten, dass Resolve versucht, die Verarbeitungspipeline so durchgängig wie möglich auf der GPU zu halten.

Ein anderer Grund kann halt sein, wenn Windows gegenwärtig tatsächlich grundsätzlich nur im Rahmen von sRGB arbeitet, das für Resolve einfach 'zu wenig' ist, es also gar keinen Sinn macht, diesen Weg zu gehen, selbst wenn es für viele rec.709 Nutzungen ausreichend sein könnte. Es gibt halt genug andere professionelle Nutzer, denen es nicht reicht.
and now for something completely different...

Zuletzt geändert von carstenkurz am Di 26 Jan, 2021 15:14, insgesamt 3-mal geändert.




mash_gh4
Beiträge: 4009

Re: Color Management in Resolve

Beitrag von mash_gh4 » Di 26 Jan, 2021 15:08

carstenkurz hat geschrieben:
Di 26 Jan, 2021 13:51
Das Argument ist bullshit, und das weisst Du auch. Sofern mir die nötigen Durchgriffsmöglichkeiten auf die Grafikausgabe gewährt werden (da braucht's nicht viel), reicht natürlich notfalls ein Raspberry PI Zero als Testsignalgenerator. Und ähnlich rudimentär kriegt man auch die Zugriffe für so eine Spezialanwendung unter einem notfalls handgetunten Linux hin.

Das ist aber was ganz Anderes, als bei einer Videoschnittanwendung aus verschiedensten Gründen auf den Unterbau eines vollständigen Betriebssystems mit nicht umgehbarer Treiberarchitektur und Grafik-APIs setzen zu MÜSSEN. Und da beisst sich deine Argumentation in den ***, genau DESWEGEN gibt es die Decklink Karten, weil BMD bei denen vollkommen frei selbst entscheiden kann, was auf die Leitung geht.
nein -- man braucht wirklich nicht viel!

die meisten video-ausgaben nutzen techniken, die in cantsins diagramm ganz rechts angeordnet sind -- d.h. sie überspringt die GUI-zwischenschichten bzw. retained mode grafik aufbereitung und kommunzieren relativ harwarenah mit der GPU. das geschieht mittlerweile unter linux und windows derart ähnlich, dass man im genannten diagramm problemlos manche bezeichnungen einfach abändern könnte, und es würde perfekt auf das andere system zutreffen.

bei der ausgabe in einzelne fester od. bildschirmbereiche sind ohnehin einige beschränkungen vorgegeben, die nicht on-the-fly geändert werden können, ohne alles umgebende völlig durcheinander zu bringen, aber zumindest im full-screen mode, wie man ihn sinnvollerweise auch zum abspielen von clips in ganz einfachen video-playern nutzen sollte, um ein möglichst befriedigende darstellung zu erhalten, fallen viele dieser einschränkungen völlig weg.

uns geht's hier aber ohnehin nur um die farben.

die werden heute praktisch in jeder ernsthaften video-anwendung nicht mehr in der selben weise behandelt, wie man sie über das kabel an video-monitore schickt (also in YCbCr codierung mit ganzzahligen 8- od. 10bit-bit werten), sondern im regelfall als RGB in 32bit-fließkommadarstellung und bei den besseren programmen auch noch in relativ großen linearen bearbeitungsfarbräumen, die charakteristiken aufweisen, die mit den physikalischen gesetzmäßigkeiten der farbmischung besser harmonieren als es bei operationen innerhalb typischer display referred farbräume bzw. werteangaben, wie man sie im monitorkabel antrifft, der fall wäre. erst am ende der verarbeitungskette werden die bilder dann doch wieder in solch einfache werteangaben übersetzt, die man über normierte übertragungsprotokolle (HDMI etc.) an die ausgabegeräte schickt.

wäre letzteres nicht ganz klar spezifiziert und technisch sehr eng festgelegt, würden geräte verschiedener hersteller wohl kaum austauschbar die selben bilder zeigen.

ich glaub, so weit ist uns das allen aus dem alltag vertraut, dass man an diesen ganz elementaren errungenschaften des fortschritts und der techn. standardisierung nicht unbedingt zweifeln muss.

was nun die frage einer möglichst korrekten farbwiedergabe betrifft, gibt's tatsächlich ein paar feinheiten, die auf den ersten blick überraschen bzw. mit feinheiten der entsprechender ausgabetechniken zu tun haben.

so arbeite z.b. OpenGL grundsätzlich colorspace agnostic -- d.h. die RGB fließkommawerte mit denen man dort operiert, sind nicht ohne weites und direkt in sinnvolle farbangaben am monitor zu übersetzten. den notwendigen kontext einer korrekten zuordnung, verwaltung der referenzangaben für ein- und ausgaben anderer bildquellen und die notwendigen umrechnung muss tatsächlich die anwendung selbst unter zuhilfenahme div. dafür geeigneter hilfsmittel bereitstellen. das ändert aber nichts daran, dass es für eine derartige anwendung trotzdem eine relative triviale anforderung bleibt, am ende dann doch wieder nur ein tripple aus drei zahlenwerten an den monitor zu schicken -- und dieses geht dann, wenn man einige details beachtet, auch tatsächlich in genau dieser weise ohne großartige veränderungen, vor denen man sich fürchten müsste, dorthin raus!

es wirklich ziemlich erhellend, wenn man sich anschaut, wie das dafür notwendige vorgehen bzw. zusammenspiel mit der systemweiten-farbverwaltung in div. apple entwicker-anleitungen am beispiel von OpenGL und anderer non-color managed frameworks beschreiben wird:

https://developer.apple.com/library/arc ... NT_EXAMPLE

die apple doku macht hier deshalb sinn, weil dort systemweites color-managment schon länger eine selbstverständlichkeit darstellt, weil man ja sonst kaum seine kunden mit eingebauten P3-diplays zufriedenstellen könnte.

natürlich ist die ganze geschichte im detail dann doch wieder relativ kompliziert, auf allen systemen wieder ein klein wenig anders und voller fallstricke und stolpersteine. trotzdem -- von einem programm wie resolve, muss man einfach erwarten, dass es diese aufgabe befriedigend bewältigt und tatsächlich eine brauchbare farbvorschau bietet. ohne diesen punkt einzulösen, bleibt das ganze ein lustiges spiel mit bunten farben, dem jeder feste grund und orientierungsrahmen fehlt.

wie gesagt, es gibt wirklich genug programme, die das deutlich befriediegender umsetzten.
Zuletzt geändert von mash_gh4 am Di 26 Jan, 2021 16:10, insgesamt 5-mal geändert.




mash_gh4
Beiträge: 4009

Re: Color Management in Resolve

Beitrag von mash_gh4 » Di 26 Jan, 2021 15:14

carstenkurz hat geschrieben:
Di 26 Jan, 2021 14:29
Photoshop muss halt nicht die Anforderung erfüllen, 4k/60p garantiert ruckelfrei durch sein Farbmanagement schleusen zu müssen. Und ein paar andere Sachen hat Resolve nebenher ja auch noch zu tun.
wie gesagt -- dafür gibt's z.b. OpenColorIO, das von relativ vielen programmen bzw. herstellern verwendet wird. damit bekommt man umrechnungshilfestellungen -- einfache matrix-angaben für die farbraumanpassung und vollständige 1D-LUTs für die transferfunktionsverarbeitung -- die sich auf heutigen grafikkarten extrem effizient nutzen lassen.




Bluboy
Beiträge: 1507

Re: Color Management in Resolve

Beitrag von Bluboy » Di 26 Jan, 2021 15:18

Von einem programm wie resolve, muss man einfach erwarten, ....

Von Resolve darfst Du bestenfalls erwarten, dass es die Mängel der BM Kameras ausbügerlt, denn dazu wurde es entwickelt




dienstag_01
Beiträge: 10952

Re: Color Management in Resolve

Beitrag von dienstag_01 » Di 26 Jan, 2021 15:26

Bluboy hat geschrieben:
Di 26 Jan, 2021 15:18
Von einem programm wie resolve, muss man einfach erwarten, ....

Von Resolve darfst Du bestenfalls erwarten, dass es die Mängel der BM Kameras ausbügerlt, denn dazu wurde es entwickelt
Nee, nee, Resolve gibts schon länger.




mash_gh4
Beiträge: 4009

Re: Color Management in Resolve

Beitrag von mash_gh4 » Di 26 Jan, 2021 16:50

pillepalle hat geschrieben:
Di 26 Jan, 2021 14:23
PS: Was eben nervig an dem ganzen Thema ist, ist das so wenig Informationen dazu verfügbar sind. Je 'professioneller' ein Workflow wird, desto geheimnisvoller scheint er auch zu werden....
ich find das auch ziemlich traurig -- z.t. hat das auch mit den zumutungen zu tun, die uns die GPU hersteller mit ihren closed source treibern schon länger aufzwingen.

trotzdem -- z.b. in den aktuellen nvidia treibern unter windows gibt's zumindest diese "Color Accuracy Mode"-einstellungen, mit denen man u.a. folgendes erzwingen kann:

"Override to reference mode: Select this check box to override the current color processing and force the reference mode. When selected, color adjustments from the OS or other adjustment applications are ignored and rendered pixels are processed through the GPU pipeline in 1:1 pixel matching mode."

darauf aufbauend kann man auch ohne exotische zusatzhardware sauberes farbmanagement jenseits etwaiger systembeschränkungen umsetzen.
Zuletzt geändert von mash_gh4 am Di 26 Jan, 2021 17:12, insgesamt 1-mal geändert.




Social Media

       
 Aktuelle Beiträge [alle Foren]
 
» >Der LED Licht Thread<
von pillepalle - Mo 1:35
» Rodelink Lav mit Kabelschaden, reparierbar?
von pillepalle - Mo 0:49
» DPReviewTV Fujifilm X-S10 vs Sony a6400
von Funless - Mo 0:17
» Atomos Ninja Bild drehen und mit Dauerstrom
von pillepalle - So 23:44
» Topaz Labs Video Enhance AI 2.0: Videoverbesserungen per KI zum Sonderpreis
von markusG - So 23:07
» Blackmagic Pocket Cinema Camera 6K Pro - mit integriertem ND-Filter und optionalem Sucher
von roki100 - So 23:00
» Neue ARRI Kamera vorgestellt: AMIRA Live - für Broadcast Einsätze
von Mantas - So 21:50
» How a Film Camera works in Slow Motion
von StanleyK2 - So 21:11
» Neue Phantom TMX Ultrahigh-Speed Kamera mit BSI Sensor: 1.280 x 800 HD mit 76.000 FPS
von medienonkel - So 19:25
» DIY - Rüssel MEMS Mikrofon(e)
von ruessel - So 18:58
» BenQ SW271C: 27" 4K Profi-Monitor mit 99% AdobeRGB und nativen 24P/25P/30P
von Borke - So 18:43
» Multikamera/Synchron mit 7 Kameras ca. 5 Std. am Stück aufzeichnen mit 50fps
von videofreund23 - So 18:28
» Canon EOS R1 Specifications
von iasi - So 18:03
» DJI FPV: Neue FPV-Drohne mit OcuSync 3.0 ist bis zu 140 km/h schnell
von Mediamind - So 17:35
» Agenten sterben einsam
von Kevin Reimann - So 17:30
» Sony Alpha S-Cinetone ähnlich
von sim - So 17:04
» Sirui kündigt anamorphotisches Weitwinkel-Objektiv 35mm F/1.8 1.33x an
von roki100 - So 16:09
» Was schaust Du gerade?
von Bluboy - So 16:07
» YouTube 4K Video Encoding zu langsam? Mit diesem Hack geht’s schneller …
von r.p.television - So 16:05
» Neue Mittelklasse GPU von AMD - Radeon RX 6700XT
von MLJ - So 14:41
» KEP 59 1A Wölfe in Berlin
von Heinrich123 - So 13:49
» HD Camcorder mit 24p
von Jott - So 11:54
» Aufschlussreiches Golem-Interview zu 20 Jahren VLC-Player
von medienonkel - So 11:41
» Umfrage: In RAW filmen, Deine Meinung?
von pillepalle - So 10:34
» Meine Fränkische
von manfred52 - So 10:34
» Was hast Du zuletzt gekauft?
von Bluboy - So 10:20
» Wie unbedeutend...
von markusG - So 9:20
» Nikon NX-Studio: Kostenlose Bild- und Videobearbeitungssoftware inkl. Metadaten-Support
von pillepalle - So 1:54
» RØDE Wireless Go II: kompakte Lösung für drahtlosen 2-Kanal Videoton mit zwei Sendern
von iMac27_edmedia - Sa 23:06
» Schnitt- und Compositing-Trends 2030 - Videoanwendungen im nächsten Jahrzehnt
von roki100 - Sa 21:29
» Latenz bei Sennheiser AVX-MKE2
von iMac27_edmedia - Sa 20:39
» Lagerung der Akkus, brandgefährlich?
von nicecam - Sa 20:36
» Blackmagic Fusion. Zeig deine Kunst! :)
von roki100 - Sa 20:04
» Nikon Z6/Z7 II-Kameras - Neue Firmware, neues Movie Kit und Blackmagic RAW
von roki100 - Sa 18:52
» Da Vinci Resolve V14 +++ Audioformat
von cantsin - Sa 16:21
 
neuester Artikel
 
Schnitt- und Compositing-Trends 2030

Welche Entwicklungen darf man bei Schnitt- und Compositing-Anwendungen in den nächsten 10 Jahren erwarten? Ein paar Trends zeichnen sich jedenfalls schon deutlich ab... weiterlesen>>

Sony FX3 - Praxistest

Wir hatten bereits Gelegenheit zu einem ausführlichen Test der neuen Sony FX3 in der Praxis und haben uns vor allem die Ergonomie, den Autofokusbetrieb bei 200mm f2.8 (!), die Hauttonreproduktion inkl. LOG/LUT, Cinetone und allen Farbprofilen, die starke Zeitlupenfunktion, den Akkuverbrauch, die Stabilisierungsleistung uvm. angeschaut: Ist die Sony FX3 die bessere A7S III? weiterlesen>>

neuestes Video
 

Aktuelles Video:
concatenation 2 OLYMPIC GAME

Die olympischen Spiele als großes bewegtes Puzzle, bei dem man sich die Teilchen passend zuschneiden kann -- genug Geduld vorausgesetzt...