Infoseite // Color Management in Resolve

Frage von pillepalle:


Ich mache jetzt mal eigenständig einen neuen Thread dafür auf :)

@ catsin

Aber niemand in einem professionellem Umfeld macht eine Software-Kalibrierung. Deshalb benutzt man doch einen Hardware kalibrierbaren Monitor, damit die Grafikkarte eben keine Klimmzüge machen muss, oder das Betriebssystem dabei irgendwas 'denken' oder machen muss. Das Monitorprofil ist im Monitor gespeichert. Du redest immer davon, dass das Betriebssystem nichts anderes als sRGB darstellen kann. Das ist auch gut möglich, aber deshalb gradet man ja auch in Grafikprogrammen, die andere Arbeitsfarbräume erlauben. So wie z.B. in Photoshop. Und darum geht es doch nur. Ich kann in Resolve auch verschiedene Arbeitsfarbräume einstellen und es wird mir dann auch eine andere Darstellung in der Timeline und im Viewer angezeigt. Nur wird hier ja die ganze Zeit gesagt, es handele sich dabei trotzdem immer um sRGB. Es gibt aber keine wirkliche Evidenz dafür. Auch die betreffende Passage im Handbuch empfiehlt nur die Verwendung einer Karte und sagt, dass die Darstellung unter bestimmten Bedinungen auch nicht stimmen kann.

VG



Antwort von carstenkurz:

Das könnte ein langer Thread werden...

Ich habe mir mal das Handbuch zu deinem Eizo gezogen und arbeite es mal durch. Zunächst mal stimmt mich positiv, dass in der Tabelle der Farbmodi das DCI Preset offenbar tatsächlich 48cd/qm bzw. nits einzustellen scheint. Das ist nicht selbstverständlich, bei kaum einem Monitor kann man derart niedrige Leuchtdichten einstellen. Ich hoffe, dass das bei diesem Monitor auch nebenwirkungsfrei über das Backlight realisiert wird.

@pille: In welcher Gegend sitzt Du denn?



Antwort von cantsin:

pillepalle hat geschrieben:
Aber niemand in einem professionellem Umfeld macht eine Software-Kalibrierung. Deshalb benutzt man doch einen Hardware kalibrierbaren Monitor, damit die Grafikkarte eben keine Klimmzüge machen muss, oder das Betriebssystem dabei irgendwas 'denken' oder machen muss. Das Monitorprofil ist im Monitor gespeichert. Du redest immer davon, dass das Betriebssystem nichts anderes als sRGB darstellen kann. Das ist auch gut möglich, aber deshalb gradet man ja auch in Grafikprogrammen, die andere Arbeitsfarbräume erlauben. So wie z.B. in Photoshop. Und darum geht es doch nur. Ich kann in Resolve auch verschiedene Arbeitsfarbräume einstellen und es wird mir dann auch eine andere Darstellung in der Timeline und im Viewer angezeigt. Nur wird hier ja die ganze Zeit gesagt, es handele sich dabei trotzdem immer um sRGB. Es gibt aber keine wirkliche Evidenz dafür. ...ausser der Aussage der Resolve-Entwickler. Bei Photoshop & Co. gibt's eben die Option, das Color Management des Betriebssystem auszuschalten bzw. zu umgehen und den Farbraum in der Anwendung und am Monitor am Betriebssystem vorbei einzustellen.

Resolve verwendet für die Videoanzeige im eigenen GUI die Betriebssystem-Routinen, kein eigenes Color Management. Andere Farbräume kann man nur dann sicher einstellen und ansteuern, wenn man extern über Decklink & Co. ausgibt.



Antwort von dienstag_01:

cantsin hat geschrieben:
pillepalle hat geschrieben:
Aber niemand in einem professionellem Umfeld macht eine Software-Kalibrierung. Deshalb benutzt man doch einen Hardware kalibrierbaren Monitor, damit die Grafikkarte eben keine Klimmzüge machen muss, oder das Betriebssystem dabei irgendwas 'denken' oder machen muss. Das Monitorprofil ist im Monitor gespeichert. Du redest immer davon, dass das Betriebssystem nichts anderes als sRGB darstellen kann. Das ist auch gut möglich, aber deshalb gradet man ja auch in Grafikprogrammen, die andere Arbeitsfarbräume erlauben. So wie z.B. in Photoshop. Und darum geht es doch nur. Ich kann in Resolve auch verschiedene Arbeitsfarbräume einstellen und es wird mir dann auch eine andere Darstellung in der Timeline und im Viewer angezeigt. Nur wird hier ja die ganze Zeit gesagt, es handele sich dabei trotzdem immer um sRGB. Es gibt aber keine wirkliche Evidenz dafür. ...ausser der Aussage der Resolve-Entwickler. Bei Photoshop & Co. gibt's eben die Option, das Color Management des Betriebssystem auszuschalten bzw. zu umgehen und den Farbraum in der Anwendung und am Monitor am Betriebssystem vorbei einzustellen.

Resolve verwendet für die Videoanzeige im eigenen GUI die Betriebssystem-Routinen, kein eigenes Color Management. Andere Farbräume kann man nur dann sicher einstellen und ansteuern, wenn man extern über Decklink & Co. ausgibt. Hatte ich schon im anderen Thread geschrieben, im Handbuch von DR16 steht das Gegenteil:
Limitations When Grading With the Viewer on a Computer Display
Most computer displays do not operate at the color critical tolerances or specifications
required for broadcast or theatrical delivery. An additional issue, however, is that 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. This makes your computer display
potentially unsuitable for monitoring projects destined for the sRGB standard of the
web in its default state. For example, if you grade a project using the Color page
Viewer on your computer display, the resulting clip may not look the same in the
QuickTime player, or in other post-production applications.
...
Strictly speaking, if you’re doing professional work, you should restrict your grading to a
calibrated, 10- or 12-bit class A external broadcast display of some type, connected via
a Blackmagic Design video interface. Assuming everything is running properly, an
image that is output to video from DaVinci Resolve should match an image output to
video from any other post-production application you’re using, and this should be your
basis for comparison when examining the output of two different applications.
S.2582



Antwort von carstenkurz:

Deswegen ist zum einen die Verwendung von rec.709/BT.1886 sinnvoll, weil Standard sowohl im Videobereich als auch bei Computermonitoren, und andererseits, weil es sich auch mit üblichen Kalibrierungstools problemlos umsetzen lässt, und andererseits die Monitore es mit relativ hoher Zuverlässigkeit von Haus aus umsetzen.
Im Resultat hat man, sofern der Monitor nicht zu billig ist oder komplett verkurbelt wurde, 'überraschend' konsistente Resultate auf der Basis von rec.709 bei den meisten Anwendern auf den meisten Monitoren.

Komplizierter wird's eben, wenn man andere Farbräume anstrebt. Nicht unmöglich, aber kompliziert.



Antwort von klusterdegenerierung:

Was ich im Kontext Rec709 eigentlich immer noch nicht verstanden habe ist, das man doch schon seit längerem sowohl Endgeräte als auch Aufnahmegeräte hat, die in größeren Farbräumen als Rec709 arbeiten können, bzw diese abbilden können.

Auch gibt es schon neuere Standards wie 2020 oder 2100, warum ist denn dann ein so kleines Profil, welches eigentlich ständig an seine Grenzen kommt und es auch noch kaum Endgeräte gibt, die sowas zwingend benötigen, noch immer der Referenzwert?

Ist das nicht sowohl kontraproduktiv, besonders im Zusammenhang der moderenen Geräte, aber auch einfach der Zeit?
Warum ist es immer noch DIE Relevanz?



Antwort von dienstag_01:

carstenkurz hat geschrieben:
Deswegen ist zum einen die Verwendung von rec.709/BT.1886 sinnvoll, weil Standard sowohl im Videobereich als auch bei Computermonitoren, und andererseits, weil es sich auch mit üblichen Kalibrierungstools problemlos umsetzen lässt, und andererseits die Monitore es mit relativ hoher Zuverlässigkeit von Haus aus umsetzen.
Im Resultat hat man, sofern der Monitor nicht zu billig ist oder komplett verkurbelt wurde, 'überraschend' konsistente Resultate auf der Basis von rec.709 bei den meisten Anwendern auf den meisten Monitoren.

Komplizierter wird's eben, wenn man andere Farbräume anstrebt. Nicht unmöglich, aber kompliziert. Die Erklärung im Handbuch ist ja nun auch das genaue Gegenteil, von dem was du sagst. Sie beschreiben es nur an der einfachsten Variante, nämlich sRGB. Aber selbst das ist schon nicht verbindlich.

Ich hatte oben einen Teil gekürzt (bei den 3 Punkten), da beschreiben sie u.a. eine Möglichkeit über LUTs. Hab ich mir noch nicht angeschaut, aber vielleicht wäre das eine Möglichkeit.



Antwort von carstenkurz:

Wieso das komplette Gegenteil? Wenn Resolve eine Videovorschau im GUI über die System-GPU wiedergibt, darf man davon ausgehen, dass die GUI Elemente farbkorrigiert über das Colormanagement des Betriebssystems erfolgen. Das ist sRGB - kann jeder Monitor, und wird mit üblichen Kalibrierungstools auch unterstützt. Der Videofeed im Vorschaufenster durchläuft

- entweder, je nach System, durch die gleiche Colormanagement-Pipeline, oder, nicht - dann ist der Monitor, der dran hängt, aber eben im sRGB oder rec.709 Modus, was im Wesentlichen zum gleichen Resultat führt. Das ist halt der Vorteil, wenn rec.709 quasi der Default-Standard ist, und sRGB sich lediglich in einigen Bereichen der Kurve leicht davon unterscheidet.


Zur Frage 8/10 Bit in der Resolve Vorschau über System-GraKa:

https://www.slashcam.de/artikel/Test/Vi ... icht-.html

'Dennoch gab es bei genauerem Hinsehen dann doch noch einen sichtbaren Unterschied zu entdecken. Denn auch wenn das Display über AMD oder Nvidia mit 10 Bit angesprochen wurde, stellte Resolve seine Vorschau darüber nur mit 8 Bit dar. Tatsächlich waren in einem synthetischen Graustufen-Verlauf nur dann keine Stufen in der Vorschau zu entdecken, wenn der Monitor über Resolve über die Decklink Karte mit 10Bit angesprochen wurde. Ein kurzer Test am Mac ergab übrigens das gleiche Ergebnis: 8 Bit Stufen im Graufverlauf, auch wenn das Display im 10 Bit Modus angesteuert wurde. Exportiert man dagegen die Timeline als 10 Bit MOV, so wird diese von macOS-Player am Desktop auch ohne die 8 Bit-Stufen wiedergegeben. '

Ja, auch das kann sich irgendwann ändern oder hat sich schon geändert. Aber kauft man ein teures 10Bit Display, damit 'sich irgendwann mal was ändert''?

Mal abgesehen davon, dass man mit einer Decklink auch einen zusätzlichen Videoausgang am System hat, respektive einen an der GraKa frei. Gut, heutzutage vielleicht nicht mehr so furchtbar wichtig, weil die meisten Resolve geeigneten HighEnd GPUs ohnehin auch schon 3 Ausgänge bieten.

- Carsten



Antwort von mash_gh4:

pillepalle hat geschrieben:
Aber niemand in einem professionellem Umfeld macht eine Software-Kalibrierung. Deshalb benutzt man doch einen Hardware kalibrierbaren Monitor, damit die Grafikkarte eben keine Klimmzüge machen muss, oder das Betriebssystem dabei irgendwas 'denken' oder machen muss. Das Monitorprofil ist im Monitor gespeichert. ja -- grundsätzlich ist die gebräuchlichste vorgehensweise im professionellen umfeld, weil auf diese weise eben auf den verbindunsgstrecken tatsächlich überall korrekte signale anliegen und jede komponenete problemlos und ohne unnötigen konfigurationsaufwand ausgetauscht werden kann.

und obwohl das wirklich gang und gäbe ist bzw. allgemein empfohlen wird, gibt's durchaus auch gründe die eigentlich dagegen sprechen:

wenn man den herstellern professioneller farbkalibierungssysteme glauben schenkt, düfte es um die internen korrekturmechanismen vieler monitore leider nicht ganz so vorbildlich bestellt sein, wie das die prestigeträchtigen herstellernamen und preise vermuten lassen würden.

ein anders argument, dass man dagegen ins feld führen kann, hat damit zu tun, dass dieses einigen auf den kleinsten gemeinsamen nenner einer standardkonformen-übertragung in wahrheit dazu fürhrt, dass einerseits die tatsächlichen möglichkeiten der geräte oft nicht vollständig ausgenutzt werden können, und anderseits farbtransformationen, die aus den scene referred farbrepräsentationen der compunterprogramme direkt auf die drastellungsmöglichkeiten des jeweiligen anzeigegeräts abzielen, noch genauer und umfänglicher ausfallen können, als mit hw-kalibriertem gerät bzw. orientierung an diesen objektiven übergabespezifikationen.
diese sichtweise wird vor allem von entwicklern in der spielindustrie verfochten, wo man ja auch ständig die grenzen des möglichen strapaziert bzw. eigene techniken entwickelt hat, um möglichst direkt und effektiv mit den anzeigegeräten zu kommunizieren.
(bspw.: freesync2 -- "Bei FreeSync Premium Pro gibt der Monitor Spezifikationen und Daten direkt an den PC weiter. Somit ist ein direktes Tonemapping auf das Display möglich und unnötige Zwischenschritte werden vermieden, was die Eingabelatenz verringert. Außerdem übersteigen die HDR-Grundvoraussetzungen bei FreeSync Premium Pro die von HDR 400, um im Vergleich zu SDR (sRGB) mindestens das doppelte wahrgenommene Farbvolumen zu bieten.")

eine guten überblick, wie sich die sache gegenwärtig technisch darstellt, findet man bspw. in den momentanen arbeitsvorschlägen zum farbmanagement und hdr-unterstützung der wayland-entwickler:

https://gitlab.freedesktop.org/swick/wa ... /color.rst
https://www.collabora.com/news-and-blog ... mic-range/
pillepalle hat geschrieben:
Du redest immer davon, dass das Betriebssystem nichts anderes als sRGB darstellen kann. Das ist auch gut möglich, aber deshalb gradet man ja auch in Grafikprogrammen, die andere Arbeitsfarbräume erlauben. So wie z.B. in Photoshop. Und darum geht es doch nur. Ich kann in Resolve auch verschiedene Arbeitsfarbräume einstellen und es wird mir dann auch eine andere Darstellung in der Timeline und im Viewer angezeigt. Nur wird hier ja die ganze Zeit gesagt, es handele sich dabei trotzdem immer um sRGB. Es gibt aber keine wirkliche Evidenz dafür. Auch die betreffende Passage im Handbuch empfiehlt nur die Verwendung einer Karte und sagt, dass die Darstellung unter bestimmten Bedinungen auch nicht stimmen kann. im lauf der letzten jahre wurden das entsprechende processing in resolve ohnehein bereits mehrfach verändert und natürlich auch spürbar verbessert. früher hat man ja quasi "garantiert" ein falsches bild im GUI display angezeigt bekommen, weil einfach jede notwendige adaption zw. rec709 u. computerüblichem sRGB völlig ignoriert wurde. ganz so schlimm ist es mittlerweile nicht mehr. speziell am mac dürfte es schon länger einigermaßen brauchbare unterstützung für die tatsächlichen bildschirmeinstellungen geben. aber z.b. die einfache tatsache, dass ja auch mehre unterschiedliche monitore am computer hängen könnten -- bspw. ein wide gamut screen und ein normaler sRGB-schirm, die eben jeweils andere anpassungen der darstellung benötigen würden -- ist mit dem ausgesprochen minimalistischem konfigurationsspielraum im resolve unter windows od. linux natürlich nicht vernünftig hinzubekommen. im übrigen wird um die ganze geschichte herstellerseitig ständig ein derartiges geheimnis gemacht, dass auch ganz offensichtliche probleme immer sehr lange unentdeckt bzw. unkorrigiert bleiben, weil sich niemand offen zu sagen getraut, wie es sich bei korrekter funktion bzw. in wünschenswerter und erwarterter weise verhalten sollte.






Antwort von roki100:

klusterdegenerierung hat geschrieben:
Auch gibt es schon neuere Standards wie 2020 oder 2100 Aber nur für HDR?

https://www.youtube.com/watch?v=xlAqfZuU3qE



Antwort von klusterdegenerierung:

Ups, ist wohl nur für Pros & insider hier, tschö.



Antwort von dienstag_01:

carstenkurz hat geschrieben:
Wieso das komplette Gegenteil? Wenn Resolve eine Videovorschau im GUI über die System-GPU wiedergibt, darf man davon ausgehen, dass die GUI Elemente farbkorrigiert über das Colormanagement des Betriebssystems erfolgen. Das ist sRGB - kann jeder Monitor, und wird mit üblichen Kalibrierungstools auch unterstützt. Der Videofeed im Vorschaufenster durchläuft

- entweder, je nach System, durch die gleiche Colormanagement-Pipeline, oder, nicht - dann ist der Monitor, der dran hängt, aber eben im sRGB oder rec.709 Modus, was im Wesentlichen zum gleichen Resultat führt. Das ist halt der Vorteil, wenn rec.709 quasi der Default-Standard ist, und sRGB sich lediglich in einigen Bereichen der Kurve leicht davon unterscheidet.


Zur Frage 8/10 Bit in der Resolve Vorschau über System-GraKa:

https://www.slashcam.de/artikel/Test/Vi ... icht-.html

'Dennoch gab es bei genauerem Hinsehen dann doch noch einen sichtbaren Unterschied zu entdecken. Denn auch wenn das Display über AMD oder Nvidia mit 10 Bit angesprochen wurde, stellte Resolve seine Vorschau darüber nur mit 8 Bit dar. Tatsächlich waren in einem synthetischen Graustufen-Verlauf nur dann keine Stufen in der Vorschau zu entdecken, wenn der Monitor über Resolve über die Decklink Karte mit 10Bit angesprochen wurde. Ein kurzer Test am Mac ergab übrigens das gleiche Ergebnis: 8 Bit Stufen im Graufverlauf, auch wenn das Display im 10 Bit Modus angesteuert wurde. Exportiert man dagegen die Timeline als 10 Bit MOV, so wird diese von macOS-Player am Desktop auch ohne die 8 Bit-Stufen wiedergegeben. '

Ja, auch das kann sich irgendwann ändern oder hat sich schon geändert. Aber kauft man ein teures 10Bit Display, damit 'sich irgendwann mal was ändert''?

Mal abgesehen davon, dass man mit einer Decklink auch einen zusätzlichen Videoausgang am System hat, respektive einen an der GraKa frei. Gut, heutzutage vielleicht nicht mehr so furchtbar wichtig, weil die meisten Resolve geeigneten HighEnd GPUs ohnehin auch schon 3 Ausgänge bieten.

- Carsten Ich habe doch oben aus dem Handbuch zitiert, da steht es anders, als du behauptest.

Punkt 2 wegen der 10 bit, vielen Dank für den Link, schau ich mir nochmal an.



Antwort von carstenkurz:

Aber nur für HDR? Grundsätzlich existiert BT.2020 unabhängig von HDR - so wie P3 auch ohne HDR existiert. Ob es in der Praxis Sinn macht, so einen großen Farbraum auf der Basis von linearem 8 oder 10 Bit zu nutzen, ist allerdings fraglich (Banding). Das olle P3 im digitalen Kino verwendet immerhin schon seit 15 Jahren 12 Bit.


RAW, moderne Kameras mit großem Dynamikumfang, etc. sind kein Widerspruch zu rec.709. Es geht nur selten darum, den kompletten Farb- oder Kontrastumfang der Bild-Akquise 1:1 im Endergebnis wiederzugeben. Genau das ist ja der Sinn des Gradings, eine sinnvolle Auswahl aus dem Tonwertumfang zu treffen, so wie es der Sinn des Schnitts ist, eine sinnvolle Auswahl aus dem 'RAW-Material' zu treffen.

- Carsten



Antwort von carstenkurz:

dienstag_01 hat geschrieben:
Ich habe doch oben aus dem Handbuch zitiert, da steht es anders, als du behauptest.
Nee. Im Handbuch steht, und das ist dein Argument, dass Resolve nicht sicherstellen kann, dass die Videovorschau dem Farbmanagement des Host-Betriebssystems unterworfen wird.

Das macht aber nix, wenn der Monitor regelmäßig von sich aus in dem gleichen Modus (oder zumindest sRGB) läuft, und den auch hinreichend einhält, wie Resolve von sich aus dort ausgibt (typisch eben rec.709, wenn es so konfiguriert ist). Nur deswegen gibt es vermutlich überhaupt so wenig Probleme damit. Weil man eben mit großer Wahrscheinlichkeit davon ausgehen darf, dass Resolves Vorschausignal auf ein rec.709 Endgerät trifft - so oder so.

'An additional issue, however, is that 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. This makes your computer display
potentially unsuitable for monitoring projects destined for the sRGB standard of the
web in its default state.'

BMD verwendet die Begriffe 'not necessarily' und 'potentially unsuited'. Die können es eben nicht über alle Systemvarianten hinweg sicherstellen. Nur für ihre Decklink Karten können sie es.


- Carsten



Antwort von dienstag_01:

carstenkurz hat geschrieben:
dienstag_01 hat geschrieben:
Ich habe doch oben aus dem Handbuch zitiert, da steht es anders, als du behauptest.
Nee. Im Handbuch steht, und das ist dein Argument, dass Resolve nicht sicherstellen kann, dass die Videovorschau dem Farbmanagement des Host-Betriebssystems unterworfen wird.

Das macht aber nix, wenn der Monitor regelmäßig von sich aus in dem gleichen Modus (oder zumindest sRGB) läuft, und den auch hinreichend einhält, wie Resolve von sich aus dort ausgibt (typisch eben rec.709, wenn es so konfiguriert ist). Nur deswegen gibt es vermutlich überhaupt so wenig Probleme damit. Weil man eben mit großer Wahrscheinlichkeit davon ausgehen darf, dass Resolves Vorschausignal auf ein rec.709 Endgerät trifft - so oder so.

'An additional issue, however, is that 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. This makes your computer display
potentially unsuitable for monitoring projects destined for the sRGB standard of the
web in its default state.'

BMD verwendet die Begriffe 'not necessarily' und 'potentially unsuited'. Die können es eben nicht über alle Systemvarianten hinweg sicherstellen. Nur für ihre Decklink Karten können sie es.


- Carsten Du meinst, die haben vergessen hinzuschreiben, dass es keine Decklink braucht, sondern einen sRGB Monitor (den sowieso mehr oder weniger jeder hat)?!
Jede farbmanagmentfähige Software greift auf die ICC-Profile zurück, die im Betriebssystem hinterlegt sind. Nicht farmmangmentfähige Software machen das nicht.
Resolve macht das eben nicht.



Antwort von roki100:

dienstag_01 hat geschrieben:
Jede farbmanagmentfähige Software greift auf die ICC-Profile zurück, die im Betriebssystem hinterlegt sind. Nicht farmmangmentfähige Software machen das nicht.
Resolve macht das eben nicht.
und was ist das hier?
Bildschirmfoto 2021-01-25 um 00.13.47.png



Antwort von mash_gh4:

roki100 hat geschrieben:
und was ist das hier? resolve am mac verhält sich in dieser hinsicht immer schon völlig anders als unter linux und windows.



Antwort von dienstag_01:

roki100 hat geschrieben:
dienstag_01 hat geschrieben:
Jede farbmanagmentfähige Software greift auf die ICC-Profile zurück, die im Betriebssystem hinterlegt sind. Nicht farmmangmentfähige Software machen das nicht.
Resolve macht das eben nicht.
und was ist das hier?

Bildschirmfoto 2021-01-25 um 00.13.47.png Weil das Handbuch so schwer zu finden ist (hatte ich oben weggelassen):
If you’re using DaVinci Resolve on macOS, you can turn on “Use Mac Display
Color Profile for viewers” in the Hardware Configuration panel of the System
Settings. This lets DaVinci Resolve use one whichever of the color profiles you
choose in the Color tab of the Displays panel in the macOS System Preferences,
thereby taking advantage of ColorSync on macOS to let DaVinci Resolve display
color the way your computer monitor does. This now works for all color profiles
that ship with macOS, even ones generated by calibration software, such as that
available from X-rite, Datacolor, or other applications. On supported computers,
there’s also an option to “Use 10-bit precision in viewers,” if available, that you
can turn on. With this option enabled, rendered output displayed in QuickTime
Player will match what is seen in the DaVinci Resolve Viewer.






Antwort von carstenkurz:

dienstag_01 hat geschrieben:

Du meinst, die haben vergessen hinzuschreiben, dass es keine Decklink braucht, sondern einen sRGB Monitor (den sowieso mehr oder weniger jeder hat)?! Nein, die haben geschrieben, dass sie nicht für jede Systemumgebung sicherstellen können, dass das Resolve Vorschaufenster das Farbmanagement des Host-Betriebssystems durchläuft. Das kann in manchen Systemkonfigurationen zu Problemen führen, wenn man das von Resolve erwartet. Bei der Mehrzahl der Anwender fällt es nicht auf, weil es so oder so rec.709 oder sRGB ist. Alle, die es nicht dem Zufall überlassen wollen oder was Anderes nutzen als rec.709, müssen eben eine Decklink verwenden. Dass es dadurch nicht zum totalen Chaos ausgerechnet bei einer Colorgrading-Anwendung kommt liegt an der Dominanz respektive weiten Verbreitung von rec.709 und sRGB.



Antwort von dienstag_01:

carstenkurz hat geschrieben:
dienstag_01 hat geschrieben:

Du meinst, die haben vergessen hinzuschreiben, dass es keine Decklink braucht, sondern einen sRGB Monitor (den sowieso mehr oder weniger jeder hat)?! Nein, die haben geschrieben, dass sie nicht für jede Systemumgebung sicherstellen können, dass das Resolve Vorschaufenster das Farbmanagement des Host-Betriebssystems durchläuft. Das kann in manchen Systemkonfigurationen zu Problemen führen, wenn man das von Resolve erwartet. Bei der Mehrzahl der Anwender fällt es nicht auf, weil es so oder so rec.709 oder sRGB ist. Alle, die es nicht dem Zufall überlassen wollen oder was Anderes nutzen als rec.709, müssen eben eine Decklink verwenden. Dass es dadurch nicht zum totalen Chaos ausgerechnet bei einer Colorgrading-Anwendung kommt liegt an der Dominanz von rec.709 und sRGB. Carsten, ich dreh gleich durch. Natürlich geht es darum, dass sie nicht sicherstellen können. Sicher stellen ist aber eine Grundbedingung von Farbmanagment.
Und das bei sRGB, was das verbreitetste aller Profile ist. Und das Grundprofil für Computer.
Das die - scheinbar funktionierende - Alternative die Monitoring Card ist, ja, ob wir die zwingend brauchen, darum diskutieren wir hier die ganze Zeit.
Und schreib jetzt bitte nicht wieder, näherungsweise gehts schon. So klug bin ich auch ;)

Edit: Das Gegenbeispiel scheint ja MacOS zu sein, da greift Resolve über den Viewer auf die Profile im OS zu, Farbmanagment funktioniert.



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
und was ist das hier? resolve am mac verhält sich in dieser hinsicht immer schon völlig anders als unter linux und windows. man muss also z.B. unter Windows mit DisplayCAL&Co. sein Bildschirm Kalibrieren, davon eine LUT generieren und diese immer wieder in Davinci verwendet? https://forum.blackmagicdesign.com/view ... 60#p575225



Antwort von dienstag_01:

roki100 hat geschrieben:
mash_gh4 hat geschrieben:


resolve am mac verhält sich in dieser hinsicht immer schon völlig anders als unter linux und windows. man muss also z.B. unter Windows mit DisplayCAL&Co. sein Bildschirm Kalibrieren, davon eine LUT generieren und diese immer wieder in Davinci verwendet? https://forum.blackmagicdesign.com/view ... 60#p575225 Keine Ahnung, aber ich habe ein Handbuch ;)
Alternately, you can apply a dedicated Color Viewer LUT for calibration, using
the 1D/3D Color Viewer Lookup Table drop-down menu that’s found in the
Color Management panel of the Project Settings. This lets you analyze your
computer display for calibration in the same way you would calibrate an external
display, using a probe and color management software, and apply the resulting
calibration LUT in DaVinci Resolve. Keep in mind that monitor calibration can only
make a high quality display standards compliant; it cannot make up for a display
gamut that’s too small. For more information, see the “Lookup Tables” section of
Chapter 3, “System and User Preferences.”

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



Antwort von roki100:

dienstag_01 hat geschrieben:
Edit: Wie man die Lut generiert, habe ich noch nicht verstanden. Keine Ahnung, aber ich habe Google ;)
To generate LUTs use LUTCalc https://cameramanben.github.io/LUTCalc/ ... index.html
Or use LUT tools from DisplayCAL package (3D LUT Maker, Synthetic ICC) https://displaycal.net/
https://forum.blackmagicdesign.com/view ... 60#p575225



Antwort von dienstag_01:

roki100 hat geschrieben:
dienstag_01 hat geschrieben:
Edit: Wie man die Lut generiert, habe ich noch nicht verstanden. Keine Ahnung, aber ich habe Google ;)
To generate LUTs use LUTCalc https://cameramanben.github.io/LUTCalc/ ... index.html
Or use LUT tools from DisplayCAL package (3D LUT Maker, Synthetic ICC) https://displaycal.net/
https://forum.blackmagicdesign.com/view ... 60#p575225 Ja, gelesen hatte ich es schon, muss es aber noch verstehen. Dispcal hab ich...



Antwort von roki100:

3D LUT creation workflow for Resolve
https://hub.displaycal.net/wiki/3d-lut- ... r-resolve/



Antwort von dienstag_01:

roki100 hat geschrieben:
3D LUT creation workflow for Resolve
https://hub.displaycal.net/wiki/3d-lut- ... r-resolve/ Danke.



Antwort von cantsin:

dienstag_01 hat geschrieben:
roki100 hat geschrieben:
3D LUT creation workflow for Resolve
https://hub.displaycal.net/wiki/3d-lut- ... r-resolve/ Danke. Ist aber auch auf Rec. 709 / BT.1886 beschränkt.






Antwort von dienstag_01:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:

Danke. Ist aber auch auf Rec. 709 / BT.1886 beschränkt. Der Artikel ist von 2016. Resolve Version war 14.



Antwort von cantsin:

Der Artikel ist von 2016. Resolve Version war 14. 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.



Antwort von pillepalle:

Sorry Leute, hatte mich für ein paar Stunden ausgeklinkt. Danke für die Antworten :)

Ja, den Link von Carsten zu dem Slashcam Beitrag kannte ich auch noch nicht. Der deutet zumindest darauf hin, dass es bei Resolve wohl doch noch eine Decklink Karte für die 10bit Darstellung braucht. Da würde ja quasi auch eine 200,-€ Mini Monitor 4K Karte reichen. Ich kann zwar verstehen das Blackmagic Hardware verkaufen möchte, aber etwas skuril ist das schon. Blackmagic Design ist da leider nicht so deutlich bei ihren Angaben. Natürlich bekommen die vermutlich ständig blöde Supportanfragen von Usern, die sich gar nicht um sowas kümmern und empfehlen deshalb mit einen Class A Monitor über eine Decklink Karte zu gehen. Dann sind sie auf der sicheren Seite und es ist erstmal Ruhe im Karton :)

Ich habe eigentlich zwei 10bit Monitore an meinem System, würde aber dann aber natürlich nur einen (den Eizo) an die Karte anschließen (über HDMI) und bräuchte dann nur das Eingangssignal des Monitors umstellen. Bei allen anderen Anwendungen würde der Monitor dann über den Display Port Anschluß der Grafikkarte laufen, über den ich ihn bisher angeschlossen habe.

Nur um das nochmal klar zu stellen. Mir ging es nicht darum zweihundert Euro für eine Karte sparen zu wollen. Ich möchte nur verstehen, wie das nun tatsächlich funktioniert und gemanaged wird. Mir war das nämlich überhaupt nicht klar. Und das gleiche gilt auch für die Diskussion über das Color Management und die Arbeitsfarbräume in Resolve. Wenn man nicht versteht warum man etwas macht, dann ist es auch nicht plausibel/sinnhaft. Im Fotobereich arbeite ich schon lange in einem professionellem Umfeld. Da ist es auch einfacher an nützliche Informationen zu kommen und man weiß warum der Workflow so ist wie er ist. Bei Video ist das bisher bei mir noch nicht der Fall. Da hat ehrlich gesagt niemand in meinem näheren Umfeld Ahnung, und nur hier im Forum gibt es ein paar Leute die einem diesbezüglich wirklich weiterhelfen. Neben den Infos die man sonst so im Netz findet, die aber eben auch mal falsch oder unnütz sein können. Am besten wäre es natürlich mal einen Monat neben einem professionellem Coloristen zu arbeiten, aber die Möglichkeit hat auch nicht jeder.

Im übrigen sind Monitorprofile nichts großartig anderes als 3D-LUTs, nur weil das in der Diskussion hier auch mal aufkam.

@ Kluster

Falls Du noch mit liest... 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. Würde man einen großen Farbraum verwenden, käme es bei einem Großteil der Nutzer zu einer falschen Darstellung, weil die jeweiligen Endgeräte das gar nicht darstellen können. In einem professionellem Workflow macht man das aber erst ganz zum Schluß. D.h., man arbeitet in einem großeren Farbraum (idealerweise dem originalen der bei der Aufzeichnung verwendet wurde) und konvertiert die Farbräume erst im Delivery-Stadium individuell und je nach Nutzung. Also bei Fotos arbeitet man z.B. in 16bit AdobeRGB und wandelt die Aufnahmen dann z.B. einmal in CMYK um (für den Druck) und einmal vielleicht in sRGB JPEGs für's Netz. Genauso macht ein Arbeiten in anderen Farbräumen bei Film natürlich nur Sinn, wenn man auf ein bestimmtes Zielmedium hin arbeitet (z.B. Kinoprojektion, oder HDR, ect). Um ein Video im Netz, oder für's Fernsehn zu veröffentlichen braucht es nichts anderes als REC709/BT1886.

VG

PS: Hab' übrigens gerade noch ein ganz interessantes Interview mit einen Coloristen zum Thema Farbmanagement gefunden. Der liefert zwar immer noch meist REC709 arbeitet aber in der Regel in ACES (Stelle gettaged):

https://www.youtube.com/watch?v=QPoClbf4Yw4&t=18m40s



Antwort von Frank Glencairn:

roki100 hat geschrieben:
dienstag_01 hat geschrieben:
Jede farbmanagmentfähige Software greift auf die ICC-Profile zurück, die im Betriebssystem hinterlegt sind. Nicht farmmangmentfähige Software machen das nicht.
Resolve macht das eben nicht.
und was ist das hier?

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

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

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

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

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



Antwort von roki100:

"Frank Glencairn" hat geschrieben:
"Das hier" ist eine weitere Krücke (die speziellen Apple Render Einstellung ist die andere), die nötig ist um den geneigten Mac User davon abzuhalten schon wieder einen Post mit dem Titel "Mein gerenderter Clip sieht völlig anders aus als in meiner Vorschau" zu erstellen ;-) nicht ohne Grund ist bei mir da kein Häkchen gesetzt :) Ich dachte es liegt daran weil ich kein Profi Bildschirm habe und die Funktion sei sowieso nur für die Profis mit Profi Bildschirme relevant.



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
der Grund warum man immer noch sRGB (im Fotobereich) oder REC709/BT1886 (bei Video) verwendet, ist die Idee des kleinsten gemeinsamen Nenners bei relativ unspezifischen Anwendungen. Bei einem kleinen Farbraum ist sichergestellt, dass er quasi auf jedem System richtig dargestellt werden könnte. Dieses Wissen ist meiner Frage vorraus gegangen und basiert darauf, das es eben so gut wie keine Gerätre mehr gibt, bzw gebaut werden,
die diese nicht, bzw auch etwas größeren, nicht darstellen können.

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

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



Antwort von dienstag_01:

"Frank Glencairn" hat geschrieben:
roki100 hat geschrieben:



und was ist das hier?

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

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

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

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

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



Antwort von pillepalle:

@ Frank

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

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

@kluster

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

@ dienstag

Das steht in den Specs

VG



Antwort von dienstag_01:

@ dienstag

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






Antwort von Darth Schneider:

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

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

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



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Ich sehe schon, Du willst in iasis Fußstapfen treten *g* ?
Sicher, man kann auch noch ein Wählscheiben Telefon der Post, sowie ein altes Sateliten Telefon mit 24V Akku und Stabantenne benutzen.



Antwort von klusterdegenerierung:

dienstag_01 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 ;) https://www.isolapse.com/true-10-bit-vs ... ifference/



Antwort von pillepalle:

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

VG



Antwort von klusterdegenerierung:

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



Antwort von dienstag_01:

klusterdegenerierung hat geschrieben:
dienstag_01 hat geschrieben:

Bei meinen Eizos nicht.
Ausserdem war das nicht meine Frage. Frank macht hier schon wieder einen Unterschied auf, den hätte ich gern irgendwie gesehen.
Wird er ja wohl hinbekommen ;) https://www.isolapse.com/true-10-bit-vs ... ifference/ Ich weiß was FRC ist.
Ich weiß, an welcher Stelle man Informationen bekommt, welche Art Display im Monitor verbaut ist.
Was ich nicht weiß: wie man den Unterschied sichtbar machen kann, wenn es denn geht.



Antwort von pillepalle:

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

VG



Antwort von Darth Schneider:

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



Antwort von pillepalle:

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

VG






Antwort von roki100:

@Boris
die BMD Bildschirme sind 10Bit.



Antwort von Darth Schneider:

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



Antwort von mash_gh4:

cantsin hat geschrieben:
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.



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
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...



Antwort von klusterdegenerierung:

dienstag_01 hat geschrieben:
klusterdegenerierung hat geschrieben:


https://www.isolapse.com/true-10-bit-vs ... ifference/ Ich weiß was FRC ist.
Ich weiß, an welcher Stelle man Informationen bekommt, welche Art Display im Monitor verbaut ist.
Was ich nicht weiß: wie man den Unterschied sichtbar machen kann, wenn es denn geht. Oh entschuldige, wie konnte ich das übersehen!
Aber wenn Du schon so schlau bist, dann zähle doch eins und eins zusammen, dann wird bestimmt auch Dir klar, das es nur über die framerate zu sehen ist.

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



Antwort von klusterdegenerierung:

mash_gh4 hat geschrieben:
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?



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
pillepalle hat geschrieben:
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.



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
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:
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, 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...



Antwort von dienstag_01:

ohne sauberes farbmanagement kommt man da einfach nicht vom fleck. Aha. Gestern hieß es noch, dass eine Decklink nicht nötig ist.
Nennen wir es mal Erkenntnisgewinn.






Antwort von mash_gh4:

dienstag_01 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!



Antwort von andieymi:

dienstag_01 hat geschrieben:
roki100 hat geschrieben:


man muss also z.B. unter Windows mit DisplayCAL&Co. sein Bildschirm Kalibrieren, davon eine LUT generieren und diese immer wieder in Davinci verwendet? https://forum.blackmagicdesign.com/view ... 60#p575225 Keine Ahnung, aber ich habe ein Handbuch ;)
Alternately, you can apply a dedicated Color Viewer LUT for calibration, using
the 1D/3D Color Viewer Lookup Table drop-down menu that’s found in the
Color Management panel of the Project Settings. This lets you analyze your
computer display for calibration in the same way you would calibrate an external
display, using a probe and color management software, and apply the resulting
calibration LUT in DaVinci Resolve. Keep in mind that monitor calibration can only
make a high quality display standards compliant; it cannot make up for a display
gamut that’s too small. For more information, see the "Lookup Tables" section of
Chapter 3, "System and User Preferences."

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

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

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

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



Antwort von dienstag_01:

mash_gh4 hat geschrieben:
dienstag_01 hat geschrieben:

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.



Antwort von dienstag_01:

andieymi hat geschrieben:
dienstag_01 hat geschrieben:

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.



Antwort von pillepalle:

dienstag_01 hat geschrieben:
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



Antwort von klusterdegenerierung:

dienstag_01 hat geschrieben:
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.



Antwort von pillepalle:

klusterdegenerierung hat geschrieben:
dienstag_01 hat geschrieben:
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



Antwort von dienstag_01:

pillepalle hat geschrieben:
dienstag_01 hat geschrieben:
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.



Antwort von cantsin:

andieymi hat geschrieben:
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.






Antwort von pillepalle:

dienstag_01 hat geschrieben:
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



Antwort von dienstag_01:

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 ;)



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
mash_gh4 hat geschrieben:


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. 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!



Antwort von dienstag_01:

mash_gh4 hat geschrieben:
dienstag_01 hat geschrieben:

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! Mach den Test mit den Fotobetrachtern.



Antwort von klusterdegenerierung:

dienstag_01 hat geschrieben:
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.



Antwort von Darth Schneider:

Jeder Pimperl Video Player....;))))
Wusstet ihr das der eine Zwerg aus dem Märchen Schneewittchen tatsächlich Pimpel heisst ?
Gruss Boris



Antwort von pillepalle:

klusterdegenerierung hat geschrieben:
dienstag_01 hat geschrieben:
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



Antwort von klusterdegenerierung:

Mann kann das ganze mit dem Wasserwaagen Prinzip vergleichen.
Wenn ein Tisch in Waage ist (zb. sRGB) dann ist das gut für alles was dort zum leigen oder stehen kommt.

Wenn ich nun ein Brett auf den Tisch lege, welches ein Gefälle aufweist (eigenes Profil) dann wird dieses Brett erstmal richtig interpretiert, denn es liegt auf einem waagerechten Tisch.

Da das Brett aber selbst nicht in der Waage ist, braucht oder hat es ein eigenes Profil und wäre es gleich dem des Tisches, würde ich das Gefälle nicht mehr sehen, obwohl es vorhanden ist.

So ist es eben bei den Fotos und den Unterschiedlichen Programmen, ist das Programm schon nicht in der Waage, wird es schwer zu entscheiden, ob das Brett ebenso nicht in der Waage ist.

Was natürlich auf der einen Seite nervt, ist auf der anderen eine Sicherheit und ein beweis, dass das Prinzip funktioniert.



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Also das Profil in den Arbeitsfarbraum umwandeln, das Farbprofil behalten, ect. So funktioniert Color Management. Das macht nur PS und hat andere Hintergründe.






Antwort von Frank Glencairn:

klusterdegenerierung hat geschrieben:

Sicher, man kann auch noch ein Wählscheiben Telefon.... Während dessen auf meinem Schreibtisch ;-)

IMG_20210125_122629-01.jpeg



Antwort von pillepalle:

@ kluster

Nee, das macht jede Software mit Color Management. Und wenn sie Dich nicht fragt, dann macht sie es im Hintergrund von alleine. Du kannst mir aber gerne erklären welchen Hintergrund das sonst haben sollte ;)

VG



Antwort von dienstag_01:

Jungs, ich kann euch echt nur den Test mit den Fotobetrachtern nahe legen.



Antwort von klusterdegenerierung:

Eine Softwäre bettet nicht ungefragt ein Profil um, denn jenes muß dann gespeichert werden.
Ein Adobe RGB Bild sollte in sRGB anders ausehen und Du hast die Entscheidungfreiheit das Du mit dem Adobe RGB Profil innerhalb eines sRGB Raumes weiterarbeitest, oder es konvertierst in den sRGB Raum, was dann dabei unter der Haube passiert muß ich ja nicht erklären.

Gebe ich dieses Bild also wieder demjenigen zurück, in der Form wie es war, sollte ich es auch als solche importieren und wieder ausgeben, sonst seht ihr beide was anderes.



Antwort von klusterdegenerierung:

dienstag_01 hat geschrieben:
Jungs, ich kann euch echt nur den Test mit den Fotobetrachtern nahe legen. Den hab ich ja eben damit angesprochen.



Antwort von pillepalle:

Ich weiß ja nicht ob jemand bei Slashcam auch in so nerdigen Threads herum liest, aber einen Beitrag zum Thema Color-Management bei Film (von mir aus auch von externen Experten) fände ich persönlich ziemlich gut... auch wenn ich da der Einzige sein sollte *g*

VG



Antwort von klusterdegenerierung:

Wieso, der Experte schreibt doch die ganze Zeit mit, auch wenn er dabei nicht persönlich mit jedem spricht!



Antwort von klusterdegenerierung:

"Frank Glencairn" hat geschrieben:
klusterdegenerierung hat geschrieben:

Sicher, man kann auch noch ein Wählscheiben Telefon.... Während dessen auf meinem Schreibtisch ;-) Kannste aber ruhig mal wieder putzen. ;-))



Antwort von pillepalle:

klusterdegenerierung hat geschrieben:
Eine Softwäre bettet nicht ungefragt ein Profil um, denn jenes muß dann gespeichert werden.
Ein Adobe RGB Bild sollte in sRGB anders ausehen und Du hast die Entscheidungfreiheit das Du mit dem Adobe RGB Profil innerhalb eines sRGB Raumes weiterarbeitest, oder es konvertierst in den sRGB Raum, was dann dabei unter der Haube passiert muß ich ja nicht erklären.

Gebe ich dieses Bild also wieder demjenigen zurück, in der Form wie es war, sollte ich es auch als solche importieren und wieder ausgeben, sonst seht ihr beide was anderes. Das wovon Du redest ist doch nicht anderes als Color Management. Die Option das Profil zu verwerfen, oder es nicht zu konvertieren führt nicht zu einer richtigen Darstellung in PS, kann aber auch so gewollt sein, wenn man z.B. nur Änderungen vornehmen möchte die die Farben gar nicht betreffen. Jede unnötige Konvertierung von einen Farbraum in einen anderen verschlechtert die Farben im Bild in der Regel.

VG






Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:
.. 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. ..ooooder man gibt einmalig die lächerlichen 150 Öcken für eine BM Mini Monitor box (oder Karte) aus, spart sich das ganze Gefrickel, und ist schlagartig nicht nur aller Colormanagement Sorgen enthoben, sondern ist sogar für den kommenden 12Bit Standard gewappnet.

Muß jeder selbst wissen - ich denke, wer den Unterschied zwischen 8 und 10 Bit sowie zwischen 10 Bit und FRC nicht sieht, oder glaubt die Ausgabe ist doch jetzt schon wunderbar, was soll da noch besser werden - der braucht sich da überhaupt keine Gedanken zu machen.



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
klusterdegenerierung hat geschrieben:
Eine Softwäre bettet nicht ungefragt ein Profil um, denn jenes muß dann gespeichert werden.
Ein Adobe RGB Bild sollte in sRGB anders ausehen und Du hast die Entscheidungfreiheit das Du mit dem Adobe RGB Profil innerhalb eines sRGB Raumes weiterarbeitest, oder es konvertierst in den sRGB Raum, was dann dabei unter der Haube passiert muß ich ja nicht erklären.

Gebe ich dieses Bild also wieder demjenigen zurück, in der Form wie es war, sollte ich es auch als solche importieren und wieder ausgeben, sonst seht ihr beide was anderes. Das wovon Du redest ist doch nicht anderes als Color Management. Die Option das Profil zu verwerfen, oder es nicht zu konvertieren führt nicht zu einer richtigen Darstellung in PS, kann aber auch so gewollt sein, wenn man z.B. nur Änderungen vornehmen möchte die die Farben gar nicht betreffen. Jede unnötige Konvertierung von einen Farbraum in einen anderen verschlechtert die Farben im Bild in der Regel.

VG Ja, schon klar, aber das ist doch das Ding, warum sollte ein Windows 900kb Fotobetrachter dies können?
Und ist das sinnvoll, denn wenn ein Foto based on FM plötzlich anders aussieht, kann doch eine Kindergärtnerin oder Speditionskaufmann da nix mit anfangen. :-)



Antwort von cantsin:

pillepalle hat geschrieben:
klusterdegenerierung hat geschrieben:


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. Nee, du beschreibst was anderes - nämlich die Darstellung von Bilder im AdobeRGB-Farbraum auf einem sRGB-kalibrierten System. Das ist natürlich auch was Resolve & Co machen, wenn sie Videomaterial mit anderen Farbräumen im GUI-Viewer darstellen. Die Frage ist doch, wie eine Monitoranzeige in größeren Farbräumen als sRGB konsistent und verlässlich im Zusammenspiel von Monitor, Anwendungssoftware und Betriebssystem machbar ist.



Antwort von pillepalle:

@ Frank

Ich mag ja Deinen pragmatischen Ansatz :) Es hat doch niemand davon geredet, dass das eigene Setup das Maß aller Dinge sei und es nicht besser ginge. Hier geht es auch um's Prinzip und das Verstehen der Vorgänge. Ich selber brauche in Absehbarer Zeit jedenfalls nichts für's Kino zu graden. Trotzdem würde ich gerne wissen wie man auch ohne 50.000,-€ Hardware zu einem passablem Ergebnis kommen kann und welche Wege dorthin führen können.

VG



Antwort von klusterdegenerierung:

"Frank Glencairn" hat geschrieben:
mash_gh4 hat geschrieben:
.. 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. ..ooooder man gibt einmalig die lächerlichen 150 Öcken für eine BM Mini Monitor box (oder Karte) aus, spart sich das ganze Gefrickel, und ist schlagartig nicht nur aller Colormanagement Sorgen enthoben, sondern ist sogar für den kommenden 12Bit Standard gewappnet.

Muß jeder selbst wissen - ich denke, wer den Unterschied zwischen 8 und 10 Bit sowie zwischen 10 Bit und FRC nicht sieht, oder glaubt die Ausgabe ist doch jetzt schon wunderbar, was soll da noch besser werden - der braucht sich da überhaupt keine Gedanken zu machen. Aber nur unter der bewiesenen Vorraussetzung, das eine GPU mit 10Bit Unterstützung dies nicht kann.
Wissen wir das denn? ;-)



Antwort von pillepalle:

@ catsin

Ich hab schon an anderer Stelle versucht Dir das zu erklären. Was Windows und irgend eine GUI macht, haben bezüglich der Farbdarstellung wenig miteinander zu tun. Das möchtest Du aber anscheinend nicht verstehen.

VG



Antwort von klusterdegenerierung:

Kommt Jungs, reicht doch wenn ich & dienstag das machen. ;-)



Antwort von dienstag_01:

pillepalle hat geschrieben:
Ich weiß ja nicht ob jemand bei Slashcam auch in so nerdigen Threads herum liest, aber einen Beitrag zum Thema Color-Management bei Film (von mir aus auch von externen Experten) fände ich persönlich ziemlich gut... auch wenn ich da der Einzige sein sollte *g*

VG Ich kenne keine Software im Filmbereich, die ohne eigene Hardware farbmanagmentfähig ist. (Resolve und MacOS ausgenommen, wie erst kürzlich gelesen).
Dazu muss man aber wissen, dass bis vor wenigen Jahren z.B. eine 50Hz Ausgabe ohne Tearing nicht mit den Standardgrafikkarten möglich war. Vorher brauchte man sogar noch Hardwareunterstützung, um Video überhaupt flüssig abspielen zu können. Farbmanagment ist sozusagen das letzte Glied in einer langen Kette.



Antwort von Frank Glencairn:

andieymi hat geschrieben:


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. Nicht zwangsläufig. Wenn ich irgendeine LUT in den Color Viewer Slot lade, ändert sich weder meine Vorschau (extern via Decklink), noch meine UI Oberfläche, sondern wirklich nur das Vorschaufenster - was ja auch zu erwarten wäre. Die Frage ob sich das jetzt irgendwie aufdoppelt, hängt IMHO hauptsächlich davon ab, wie der Clip im Vorschaufenster vom OS durchgereicht wird, und ob Resolve dabei das Farbmanagement überhaupt beachtet. Was ich meine ist, es gibt ja mehrere Möglichkeiten so ein Vorschaufenster zu realisieren (direct-X z.b.) keine Ahnung wie das softwaretechnisch bei Resolve gemacht ist. Ich schätze davon hängt ne Mange ab.



Antwort von cantsin:

pillepalle hat geschrieben:
@ catsin

Ich hab schon an anderer Stelle versucht Dir das zu erklären. Was Windows und irgend eine GUI macht, haben bezüglich der Farbdarstellung wenig miteinander zu tun. Das möchtest Du aber anscheinend nicht verstehen. Nein, Du verstehst da etwas prinzipiell nicht, und deswegen kommt diese Diskussion nicht voran. Erkläre mir mal bitte, wie Photoshop (oder Resolve) am Betriebssystem und Grafiktreiber vorbei ein Farbsignal auf dem Monitor ausgeben soll (zumindest im GUI-Modus)?



Antwort von mash_gh4:

cantsin hat geschrieben:
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. schau dir einfach an, wie das in anderen hochwertigen videobearbeitungsprogrammen gelöst ist.

am transparentesten erscheint mir das im nuke u. natron ungesetzt zu sein, wo du oben in jedem der viewer eine auswahl geboten bekommst, wie die bilddaten per OpenColorIO an den dort einstellbaren ausgabefarbraum umgewandelt werden sollen.

damit werden zwar nicht die mängel einzelner ausgabegeräte korrigiert, aber eben ein DCI-P3 footage od. rec709 mit dem dort gebräuchlichen gamma für einen computerbildschirm, der sRGB od. eben auch DCI-P3 korrekt darzustellen vermag, völlig ausreichend umgewandelt.

OpenColorIO stellt dafür ohnehin die ganze umrechnerei zw. den gebräuchlichen farbräunem fertig bereit, genauso wie man es auch in ACES workflows handhabt.

im mistika ist es ähnlich, aber an einem springenden punkt doch wieder ein klein wenig anders gelöst. dort spielen die sgn. "display-filter" eine entscheidende rolle in der ausgabe-aufbereitung. dier erledigen zwar über weite strecken ganz ähnliches wie die oben beschriebenen viewer einstellungen im nuke od. die projekt-arbeitsraum-einstellungen im resolve, sind aber deutlich flexibler und zur not auch mit mehren ausgabegeräten, die unterschiedliche anpassungen benötigen, verwendbar. das ist auch der grund, warum diese lösung gerne herangezogen wird, um gleichzeitig HDR und SDR output zu mastern.

flame und mistika sind eben auch insofern interesssant, als sie im gegensatz zu den meisten gebräuchlichen anwendungen aus historischen gründen quasi durchgängig diese eigenartige vorhin bereist erwähnte vollbilddarstellung nutzen. wenns't flame startest bzw. ein projekt konfigurierst, wird nicht nicht einfach nur eineoberflächliche umwandlung der farben in der ausgabe vorgenommen, sondern es wird tatsächlich das ganze grafik-ausgabesystem deines rechners so umkonfiguriert, dass es mit der beildwiederholrate im projekt möglichst gut harmoniert. das zwar eher nur ein ganz seltsames relikt aus ferner vergangenheit, weil man diese anpassungen heute auch ein bisserl eleganter auf linux-workstations für einzelne bildschirme umsetzten kann, trotzdem vermittelt es noch immer einen eindruck davon, wie weit man derartige software tatsächlich an die erfordernisse ernsthafter arbeit anpassen kann.



Antwort von pillepalle:

@ catsin

Der Farbraum und die Farbdarstellung die das Betriebssystem nutzt, wird doch nicht 1:1 an die GUI weitergereicht. Bei Dir klingt das so, als ob das Betreibssystem ein Flaschenhals für die verwendete Software oder die Peripherie Geräte wären. Aber das ist nicht so, die GUI oder ein Monitor bekommen die Signal ganz normal aus der Grafikkarte, nur nutzen sie andrere für die Darstellung als z.B. das Betriebssystem.

VG



Antwort von carstenkurz:

pillepalle hat geschrieben:
Ich selber brauche in Absehbarer Zeit jedenfalls nichts für's Kino zu graden. Trotzdem würde ich gerne wissen wie man auch ohne 50.000,-€ Hardware zu einem passablem Ergebnis kommen kann und welche Wege dorthin führen können.
Naja, dein Eizo ist jedenfalls in der Tat diesbezüglich nicht uninteressant, wie ich nach der Lektüre des Handbuches und einem Vergleich mit anderen Postproduktions-EIZOs zugebe. Nochmal die Frage, in welcher Gegend sitzt Du?



Antwort von cantsin:

pillepalle hat geschrieben:
@ catsin

Der Farbraum und die Farbdarstellung die das Betriebssystem nutzt, wird doch nicht 1:1 an die GUI weitergereicht. Bei Dir klingt das so, als ob das Betreibssystem ein Flaschenhals für die verwendete Software oder die Peripherie Geräte wären. Aber das ist nicht so, die GUI oder ein Monitor bekommen die Signal ganz normal aus der Grafikkarte, nur nutzen sie andrere für die Darstellung als z.B. das Betriebssystem. Sorry, das ist jetzt aber Dadaismus: "die GUI oder ein Monitor bekommen die Signal ganz normal aus der Grafikkarte".

(Dein ganzes obiges Zitat ist Dadaismus, du verstehst da offensichtlich die Grundlagen nicht. Und offenbar auch nicht, was wir mit "GUI" meinen.)



Antwort von Frank Glencairn:

pillepalle hat geschrieben:
@ Frank

Ich mag ja Deinen pragmatischen Ansatz :) Es hat doch niemand davon geredet, dass das eigene Setup das Maß aller Dinge sei und es nicht besser ginge. Hier geht es auch um's Prinzip und das Verstehen der Vorgänge. Ich selber brauche in Absehbarer Zeit jedenfalls nichts für's Kino zu graden. Trotzdem würde ich gerne wissen wie man auch ohne 50.000,-€ Hardware zu einem passablem Ergebnis kommen kann und welche Wege dorthin führen können.

VG Das eigene Setup ist für mich nur der pragmatische Sweetspot, ich hätte auch gerne einen 200000 Sony Monitor :-)

Ich hab in den Rechnern hier relativ billige Decklink Karten (eine gebraucht für 50 Öcken von Ebay),
einen älteren - ebenfalls gebrauchten - Mittelklasse Flanders, einen kleinen 17 Zoll Osee, und einen gebrauchten Dreamcolor der ersten Generation.
Von 50.000 bin ich also eher weit entfern - eher im Bereich von 5000, wobei der Flanders noch das teuerste war.

Damit hab ich für alle möglichen Anwendungen von YT-Kino gegraded und hatte noch nie wirklich ein Problem.
Ich kalibrier die einmal im Monat auf 709 und fertig.



Antwort von mash_gh4:

cantsin hat geschrieben:
Erkläre mir mal bitte, wie Photoshop (oder Resolve) am Betriebssystem und Grafiktreiber vorbei ein Farbsignal auf dem Monitor ausgeben soll (zumindest im GUI-Modus)? es gibt verschiedene möglichkeiten, wie programme grafikausgaben realisieren können.
viele davon arbeiten mit dem betriebsystem bzw. dessen grafikoberfläche in einer weise zusammen, dass eben die ausgabe erst dort für die tatsächliche anzeige fertig aufbereitet wird. es gibt aber daneben auch andere ausgabemodi, die sehr effizient direkt über die karte daten rausrendern, ohne bremsende zwischenschichten.

bei ausgaben über OpenGL war das bspw. in der regel so. wobei es in dem fall dann halt wieder das problem gab, dass die nvidia-OpenGL treiber keine 10bit ausgabe unter windows auf den billigern GTX-karten erlaubt haben, während das mit der selben hardware und den proprietären treibern des herstellers unter linux sehr wohl möglich war... ;)



Antwort von pillepalle:

@ carstenkurz

In Düsseldorf. Der Eizo steht zur Zeit allerdings in meiner Privatwohnung an meinem Rechner. Du findest auch ein paar Infos im Netz dazu.





Mir gefiel der vor allem, weil ich damit eben schnell mal das Farbprofil wechseln kann, was mir bei einer wechselnden Arbeit zwischen Fotos und Film entgegen kommt. Der große Bruder CG319X (mit 4K Auflösung) war mir persönlich zu teuer. Bisher bin ich jedenfalls super zufrieden mit ihm.

@ Frank

Ja, so wie Du (mit Karte) werde ich das in Zukunft auch machen. Ich habe mich bisher nur wenig mit dem Color Management im Filmbereich auseinander gesetzt und wundere mich ein wenig, wie anders das im Gegensatz zum Foto-Bereich läuft.

VG



Antwort von cantsin:

mash_gh4 hat geschrieben:
cantsin hat geschrieben:
Erkläre mir mal bitte, wie Photoshop (oder Resolve) am Betriebssystem und Grafiktreiber vorbei ein Farbsignal auf dem Monitor ausgeben soll (zumindest im GUI-Modus)? es gibt verschiedene möglichkeiten, wie programme grafikausgaben realisieren können.
viele davon arbeiten mit dem betriebsystem bzw. dessen grafikoberfläche in einer weise zusammen, dass eben die ausgabe erst dort für die tatsächliche anzeige fertig aufbereitet wird. es gibt aber daneben auch andere ausgabemodi, die sehr effizient direkt über die karte daten rausrendern, ohne bremsende zwischenschichten. Ja, klar, in der Theorie, bzw. bei einigen spezialisierten Anwendungen, aber nicht bei Mainstream-Software und deren Bild-/Videoanzeige innerhalb der Anwendungs-GUI-Anzeige. Bei Windows sieht die Pipeline z.B. so aus (offizielle Microsoft-Grafik):


zum Bild


(nur für diejenigen, die das nicht wissen)



Antwort von carstenkurz:

Na Düsseldorf ist nicht weit weg von mir respektive unserem Kino...nur mal so dahin gesagt...

- Carsten



Antwort von pillepalle:

Woher kommst Du denn? Auf so einen Vergleich hätte ich dann schon Lust :) Vielleicht kann ich den vor oder nach den Vorführzeiten mal mitbringen und wir kalibrieren den an einem Rechner vor Ort (oder ich bringe meinen Laptop mit), um ihn direkt mit einer Kinoprojektion vergleichen zu können... also für sowas wäre ich zu haben :)

VG



Antwort von carstenkurz:

Das Kino ist nen Tacken westlich von Köln.



Antwort von pillepalle:

Also wenn Du magst, gerne :) Du müsstest mir nur sagen wann es dir passt und wir müssten vorher mal überlegen was wir wie abspielen, damit wir auch vergleichbares Material haben... Müsste dann ggf. vorher ja noch DCP-Player installieren, wenn wir das nicht mit Deinem Rechner machen.

VG



Antwort von Bluboy:

Ich glaub das ist die beste Idee 2021

hier gleich mal ein Testbild



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Mir gefiel der vor allem, weil ich damit eben schnell mal das Farbprofil wechseln kann, was mir bei einer wechselnden Arbeit zwischen Fotos und Film entgegen kommt. Das interessiert mich dann doch mal, denn an der Stelle dürfte es ja laut Deiner Aussaugen zu einem Mischmasch kommen, oder?
Wenn Du in Resolve den Moni auf Rec umstellst, sieht das dann nicht total gruselig aus?

Mein Benq soll das ja angeblich auch können, wenn ich dann aber umstelle, ohweh, dann schauts gar luschtig aus.
Zumindest würde ich mit der Vorschau in Resolve wie Hölle nachkorrigieren und wenn sich das dann wieder jemand auf einem sRGB Moni ansieht, sähe es auch wieder ganz schlimm aus.



Antwort von mash_gh4:

cantsin hat geschrieben:
Ja, klar, in der Theorie, bzw. bei einigen spezialisierten Anwendungen, aber nicht bei Mainstream-Software und deren Bild-/Videoanzeige innerhalb der Anwendungs-GUI-Anzeige. naja -- man kann da leider diese faktischen gegebenheiten nicht völlig ignorieren.

deshalb eben meine momentane pragmatische herangehebsweise, dass ich mich am desktop bzw. normler GUI-ausgabe mit 8-bit begnüge, aber trotzdem zumindest eine korrekte umrechnung zwischen den farbräumen von jeder ernsthafteren anwendung verlange -- was ja duchaus hinzubekommen ist --, ergänzt duch 10bit-vollbildausgabe, dort wo es tasächlich ums finale bild od. befriediegenden medienkonsum geht.

ich mach da gar keinen großen unterschied, ob's dabei um werkzeuge geht, mit denen man ernsthafte arbeit erledigt, oder eben video-player, mit denen man sich nur irgendwelchen schwachsinn in der freien zeit dazwischen reinzieht -- in beiden fällen will man schließlich eine vernünftige darstellung erhalten.



Antwort von carstenkurz:

pillepalle hat geschrieben:
Also wenn Du magst, gerne :) Du müsstest mir nur sagen wann es dir passt und wir müssten vorher mal überlegen was wir wie abspielen, damit wir auch vergleichbares Material haben...

Ja, müssten mal ein bißchen Vorplanung betreiben. Ich gebe zu, es wäre eventuell praktisch, wenn Du eine Decklink im Rechner hättest. Ich habe aber ne Intensity 4k im Kino. Aber vielleicht willst Du ja jetzt die 100 Ocken für eine Decklink Mini Monitor oder sowas investieren.


Original/amtliches DCP Material haben wir genug.
Du müsstest ggfs. was aus modernen Kameras mitbringen. Raw Footage kann ich nichts beisteuern ausser dem, was man so im Netz findet.

Vielleicht verlegen wir das diesbezüglich weitere aber auf PM/email.



Antwort von pillepalle:

@ carsten

Ja, können wir gerne machen :)


@ kluster

Nee, wieso sollte das gruselig aussehen? Das was sich in REC709 ändert ist das Gamma, der Weisspunkt und die Helligkeit. Das Bild wirkt also etwas dunkeler, hat eine steilere Gradationskurve und ist etwas kühler im direkten Vergleich.

VG



Antwort von mash_gh4:

pillepalle hat geschrieben:
Nee, wieso sollte das gruselig aussehen? Das was sich in REC709 ändert ist das Gamma, der Weisspunkt und die Helligkeit. Das Bild wirkt also etwas dunkeler, hat eine steilere Gradationskurve und ist etwas kühler im direkten Vergleich. ja -- im prinzip ist es das, wobei viele bildschirme in den mitgeliferten profilen auch ganz andere helligkeitseinstellungen für rec709 und sRGB vorsehen -- meist ohnehin in beiden fällen viel zu hell leuchtend. ;)



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
@ carsten

Ja, können wir gerne machen :)


@ kluster

Nee, wieso sollte das gruselig aussehen? Das was sich in REC709 ändert ist das Gamma, der Weisspunkt und die Helligkeit. Das Bild wirkt also etwas dunkeler, hat eine steilere Gradationskurve und ist etwas kühler im direkten Vergleich.

VG Eben und jetzt stell Dir vor Du nimmst das für bare Münze und hellst die Clips auf und ziehst das Gamma runter, dann kannst Du danach alle Clips in "the fog" umbenennen.



Antwort von pillepalle:

@ kluster

Sie sind ja nur 'the fog' wenn ich sie in einem anderen Monitorprofil anschaue. Und so foggy, wie Du meinst, sind sie dann auch nicht. Am meisten merkt man das an den Schatten.

VG



Antwort von carstenkurz:

Ooops, ich sehe grade, laut den technischen Daten kann die kleine DeckLink Mini Monitor 'nur' YUV in 4:2:2/10Bit - wenn das so stimmt, wäre das natürlich für eine P3-4:4:4 Ausgabe nicht tauglich. Meine Intensity kann das aber.

Die Mini Monitor 4k kostet ein bißchen mehr als die 'normale' Mini Monitor, kann aber bis 12 Bit in 4:4:4 über HD-SDI und HDMI.



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Sie sind ja nur 'the fog' wenn ich sie in einem anderen Monitorprofil anschaue. Aachsooo, Deine Kunden nutzen ein Rec709 Profil in ihren 99€ Acer Büromonitoren, das wußte ich natürlich nicht.



Antwort von pillepalle:

Ja, die Mini Monitor 4K Karte würde ich dann auch holen. Ist eben nur etwas Schlepperei wenn ich auch noch den Desktop mitbringe *haha* aber das ist es mir Wert.

VG



Antwort von pillepalle:

@ kluster

Ich liefere meinen Kunden die Formate die sie haben möchten. Bisher gab es wenig beschwerden...

VG



Antwort von mash_gh4:

Die Mini Monitor 4k kostet ein bißchen mehr als die 'normale' Mini Monitor, kann aber bis 12 Bit in 4:4:4 über HD-SDI und HDMI. sehr viele monitore unterstützen diese anspruchsvolleren HDMI varaianten ohnehein nicht, sondern stellen die entsprechende funktionalität nur per display port bereit.

das ändert sich zwar ständig, aber DP ist meistens HDMI doch wieder um eine generation an hinzugekommenen neuen ansprüchen voraus.

SDI ist dann ohnehin wieder eine ganz andere geschichte bzw. in der regel auch anderes gerät.



Antwort von pillepalle:

@ mash_gh4

Klar, da die Karte nur SDI und HDMI out hat, kann ich nur über HDMI in den Monitor. Gehe mal davon aus, das es funktionieren sollte...

VG



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
@ kluster

Ich liefere meinen Kunden die Formate die sie haben möchten. Bisher gab es wenig beschwerden...

VG Das macht keinen Sinn und das eine hat mit dem anderen nix zu tun.

Du glaubst doch jetzt nicht im Ernst, das Deine Kunden einen Monitor mit einer Rec709 profilierung nutzen, so das ein auf Rec709 Vorschau gegradetes Bild auf deren Monis so aussieht wie bei Dir?

Das wäre das verblüffenste was ich je gehört habe.
Ich will Dir sagen was passiert, wenn Du das wirklich durchziehst.

Du bearbeitest das footage auf einem Rec709 Moni und Deine Kunden betrachten es auf einem RGB Monitor und wundern sich warum dem Video der nötig Bums fehlt.



Antwort von mash_gh4:

pillepalle hat geschrieben:
Klar, da die Karte nur SDI und HDMI out hat, kann ich nur über HDMI in den Monitor. Gehe mal davon aus, das es funktionieren sollte... ja -- aber auch bei den guten eizos gilt bspw.:

"Der CG319X unterstützt verschiedenste Video-Formate bis zu 10-bit 4:4:4 bei 50/60p via DisplayPort-Eingang und 10-bit 4:2:2 bei 50/60 Hz via HDMI."

und sehr oft -- speziell in consumer-gefielden --- ist es noch deutlich schlimmer bzw. einengender...



Antwort von pillepalle:

@ Kluster

Ich habe auch ein paar professionelle Kunden. Die wissen in der Regel sehr genau was die haben möchten, manchmal auch das unbearbeitete 10bit log Material. Wenn ich das Gefühl habe, die Leute haben gar keine Ahnung, dann achte ich schon drauf, das es auch bei Gamma 2.2 ganz gut aussieht. Mir ist aber tendenziell eine weichere Darstellung lieber, als wenn alles in den Schwärzen zu zieht, oder clippt. Das ist eben Geschmackssache...

@ mash_gh4

Wichtig ist mir vor allem das es mit der Karte überhaupt richtig funktioniert, auch wenn es nur 10bit sein sollten.

VG



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
Du bearbeitest das footage auf einem Rec709 Moni und Deine Kunden betrachten es auf einem RGB Monitor und wundern sich warum dem Video der nötig Bums fehlt. das hängt sehr stark davon ab, welchen video-player sie für die beurteilung heranziehen.

ein bisserl besser kann man es evtl. einengen, wenn man die clips übers netzt zugänglich macht -- aber auch dort gibt's leider große mängel in der jeweiligen umsetzung in den browsern bzw. keine verbindlichen maßstäbe.



Antwort von mash_gh4:

pillepalle hat geschrieben:
@ mash_gh4
Wichtig ist mir vor allem das es mit der Karte überhaupt richtig funktioniert, auch wenn es nur 10bit sein sollten. eh klar! -- aber auch das ist leider bei etwas älteren monitoren und HDMI durchaus nicht ganz so selbstverständlich... -- leider!



Antwort von carstenkurz:

Das ist richtig, aber, wenn der Monitor P3 anbietet, macht es keinen Sinn, wenn er das nicht in RGB/4:4:4 verarbeiten kann, bei RGB gibt es kein Subsampling. Aber genau deswegen muss man eben sehr genau in die Handbücher reingucken und sich bei dem Hersteller auch drauf verlassen können, dass die Dokumentation stimmt. Da darf man von Eizo mehr verlangen als von BenQ.

Zumindest finde ich im Handbuch von Pilles Eizo erstmal keine solche Einschränkung. Über die eine oder andere Formulierung könnte man noch stolpern, und manchmal muss man selbst bei nem Hersteller wie EIZO das englischsprachige Handbuch lesen, weil die Übersetzung eventuell schludrig sein kann.
Bildschirmfoto 2021-01-25 um 14.38.12.png
Und, man muss es halt testen, um sicher zu sein. Dazu dient das ja alles 'hier'. Sicherheit gewinnen.

Wäre schön, wenn der CG279x auch noch HD-SDI hätte, aber...

Und wenn ich mir im Handbuch des CG279x auch noch andere Passagen und Optionen anschaue, dann bekomme ich Gewissheit, dass man sehr genau wusste, was man ausstattungstechnisch für genau diesen Anwendungszweck wollte, und nicht nur wie andere Hersteller mit dem Buzzword 'DCI Farbraum' werben.
Er ist nicht der preiswerteste Monitor, und auch nicht der Beste, aber er vereint ziemlich viele sehr sinnvolle Optionen und Funktionen für genau diesen Anwendungszweck.



Antwort von pillepalle:

@ carsten

Ja, als Vorraussetzung muss ich mir natürlich erstmal die Karte besorgen und sicherstellen, dass sie auch richtig funktioniert. Sonst macht das wenig Sinn.

Ich werde aber zuhause auch schon sehen wie groß der Unterschied ist, wenn ich über die Karte arbeite, oder via DisplayPort direkt über die Grafikkarte gehe.

Wie nahe die P3 Darstellung einer Kinoprojektion dann tatsächlich kommt und wie brauchbar das ist, sieht man allerdings am besten im direkten Vergleich. Und dann sieht man vielleicht auch woran es hapert und auf was man achten muss.

VG



Antwort von Bluboy:

mash_gh4 hat geschrieben:
pillepalle hat geschrieben:
Klar, da die Karte nur SDI und HDMI out hat, kann ich nur über HDMI in den Monitor. Gehe mal davon aus, das es funktionieren sollte... ja -- aber auch bei den guten eizos gilt bspw.:

"Der CG319X unterstützt verschiedenste Video-Formate bis zu 10-bit 4:4:4 bei 50/60p via DisplayPort-Eingang und 10-bit 4:2:2 bei 50/60 Hz via HDMI."

und sehr oft -- speziell in consumer-gefielden --- ist es noch deutlich schlimmer bzw. einengender... Das ist aber wieder nur die halbe Miete, wenn 12bit 4.4.4 ankommen

Allgemein
Vollständiger Name : C:\0000\Atl.mxf
Format : MXF
Format-Version : 1.2
Format-Profil : OP-Atom
Format-Einstellungen : Closed / Complete
Dateigröße : 1,03 GiB
Dauer : 1 min 24s
Gesamte Bitrate : 106 Mb/s
Kodierungs-Datum : 2021-01-25 14:34:44.000
Kodierendes Programm : MainConcept Transcoding SDK 5.1.1.2885

Video
ID : 2
Format : JPEG 2000
Format-Profil : D-Cinema 2k
Format settings, wrapping mode : Frame
Codec-ID : 0D010301020C0100-0401020203010103
Dauer : 1 min 24s
Bitrate : 106 Mb/s
Breite : 2 048 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 1,896
Bildwiederholungsrate : 24,000 FPS
Color space : RGB
Chroma subsampling : 4:2:2
Bit depth : 12 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 1.989
Stream-Größe : 1,03 GiB (100%)
Color range : Full
Transfer characteristics : SMPTE 428M

Andere #1
ID : 1-Material
Type : Time code
Format : MXF TC
Bildwiederholungsrate : 24,000 FPS
Time code of first frame : 00:00:00:00
Time code settings : Material Package
Time code, striped : Ja

Andere #2
ID : 1-Source
Type : Time code
Format : MXF TC
Bildwiederholungsrate : 24,000 FPS
Time code of first frame : 00:00:00:00
Time code settings : Source Package
Time code, striped : Ja



Und mit Prenmiere

Allgemein
Vollständiger Name : E:\Videos\Sequenz 01.dcp\Sequenz_01_dcp_3feedd73-3d24-438b-99ca-01f09f1e4b81_video.mxf
Format : MXF
Format-Version : 1.2
Format-Profil : OP-Atom
Format-Einstellungen : Closed / Complete
Dateigröße : 67,8 MiB
Dauer : 38s 792 ms
Gesamte Bitrate : 14,7 Mb/s
Package name : AS-DCP Material Package / File Package: SMPTE 429-4 frame wrapping of JPEG 2000 codestreams
Kodierungs-Datum : 2021-01-25 07:16:29.000
Kodierendes Programm : DCI asdcplib Unreleased 1.12.51
verwendete Encoder-Bibliothek : win32 1.12.51.27240.1

Video
ID : 2
Format : JPEG 2000
Format-Profil : D-Cinema 2k
Format settings, wrapping mode : Frame
Codec-ID : 0D010301020C0100-0401020203010103
Dauer : 38s 792 ms
Bitrate : 14,7 Mb/s
Breite : 1 998 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 1,85:1
Bildwiederholungsrate : 24,000 FPS
Color space : XYZ
Chroma subsampling : 4:4:4
Bit depth : 12 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.283
Stream-Größe : 67,8 MiB (100%)
Titel : Picture Track
Color range : Full

Andere #1
ID : 1-Material
Type : Time code
Format : MXF TC
Bildwiederholungsrate : 24,000 FPS
Time code of first frame : 00:00:00:00
Time code settings : Material Package
Time code, striped : Ja
Titel : Timecode Track

Andere #2
ID : 1-Source
Type : Time code
Format : MXF TC
Bildwiederholungsrate : 24,000 FPS
Time code of first frame : 01:00:00:00
Time code settings : Source Package
Time code, striped : Ja
Titel : Timecode Track



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Ich habe auch ein paar professionelle Kunden. Die wissen in der Regel sehr genau was die haben möchten, manchmal auch das unbearbeitete 10bit log Material. Haben möchten?
Das mit dem Log macht doch überhaupt keinen Sinn, denn das ist doch wie es ist.

Vereinfachter Erklärungsversuch:
Setze Dich vor Deinen Monitor, meinetwegen in sRGB und korrigiere footage in Resolve, allerdings mußt Du Dir vorher eine Sonnenbrille aufsetzen.

Nachdem rendern kannst Du Dich entscheiden, gibst Du das Material so ab, oder inkl. Sonnenbrille!
So langsam weiß ich glaube ich worauf cantsin hinaus wollte. ;-)



Antwort von pillepalle:

Das ist eine Produkitonsfirma aus Italien. Die wollen das Meterial selber graden und schneiden. Wieso sollte das keinen Sinn machen?

VG



Antwort von carstenkurz:

Das ist aber wieder nur die halbe Miete, wenn 12bit 4.4.4 ankommen Nicht alles, was JPEG2000 ist, ist DCI compliant. Deswegen ist es so wichtig, dass man die richtigen Tools benutzt.

Das hier ist z.B. der Kino-Trailer von 'Die Verlegerin' (Spielberg). Und so muss das auch aussehen:

Bildschirmfoto 2021-01-25 um 14.52.23.png

Nicht notwendigerweise in der Vorschau der Postproduktion (gut, bei Spielberg schon ;-) ) - aber spätestens im Kino.



Antwort von mash_gh4:

Bluboy hat geschrieben:
Das ist aber wieder nur die halbe Miete, wenn 12bit 4.4.4 ankommen das ganze DCI konezept ist darauf ausgerichtet, dass in der aufbereitung für die projektion noch entsprechende anpassungen vorgenommen werden können. sonst bräuchte man ja auch nicht das umständliche XYZ farbmodell, etc.



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Das ist eine Produkitonsfirma aus Italien. Die wollen das Meterial selber graden und schneiden. Wieso sollte das keinen Sinn machen?

VG Weil das eine ja gerade nix mit dem anderen zu tun hat, log gibt man ja so ab und wenn es geschnitten werden soll auch ungeschnitten, da veränderst Du ja nicht das Material, aber wenn Du welches bearbeitest und machst das an Deinem Moni mit Rec709 Darstellung, veränderst Du das Bild dahingegend das es neutral ausschaut.

Wenn der Kunde sich es dann aber ansieht, sieht er was ganz anderes, weil die wenigsten an einem Monitor arbeiten, der ein Rec709 Profil nutzt, sondern ein standard RGB.



Antwort von pillepalle:

Die sehen das nicht total anders, die Unterschiede sind nicht gewaltig. Alles gut Klusti, es hindert Dich doch niemand daran alles in sRGB mit Gamma 2.2 zu graden, wenn Du das so gewohnt bist.

VG



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
Wenn der Kunde sich es dann aber ansieht, sieht er was ganz anderes, weil die wenigsten an einem Monitor arbeiten, der ein Rec709 Profil nutzt, sondern ein standard RGB. auch ein kompetenter kunde verwendet einen player, der vorsorglich eine gewissenhafte umwandlung von rec709 nach sRGB bzw. dem unterschiedlichen gamma vornimmt, statt resolve für die beurteilung heranzuziehen, wo man sich in solchen dingen tatsächlich nie ganz sicher sein kann -- ist ja schließlich auch kein programm, wo man sich über die wiedergabe der farben gedanken machen müsste.



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Die sehen das nicht total anders, die Unterschiede sind nicht gewaltig. Alles gut Klusti, es hindert Dich doch niemand daran alles in sRGB mit Gamma 2.2 zu graden, wenn Du das so gewohnt bist.

VG Ne "Pilli"!
Aber mach mal wie Du meinst, muß ja jeder selber wissen.



Antwort von Frank Glencairn:

cantsin hat geschrieben:


Ja, klar, in der Theorie, bzw. bei einigen spezialisierten Anwendungen, aber nicht bei Mainstream-Software und deren Bild-/Videoanzeige innerhalb der Anwendungs-GUI-Anzeige. Bei Windows sieht die Pipeline z.B. so aus (offizielle Microsoft-Grafik):


zum Bild


...und genau deshalb braucht man eine kontrollierte Closed Loop I/O Vorschau auf einem externen Monitor, wo keine diese Komponenten rein pfuschen kann.



Antwort von Darth Schneider:

Was mich etwas nervt, wenn ich diese Color Science Gen 5 nützen möchte sind meine Luts zu hell und kontrastarm. Dann muss ich alles wieder neu machen, scheint alles viel flacher zu sein...Grrr.
Warum machen die von BMD sowas ? Ist das jetzt sowas wie ein anderes Raw oder was ? Ich dachte immer Raw ist Raw....
Sieht ihr da überhaupt ein Vorteil mit Gen 5 vergleichen mit Gen 4 ?
Gruss Boris



Antwort von cantsin:

@Darth: "Color Science" einer Kamera ist etwas anders als Color Management von Monitoren (sondern geht darum, wie Bayer-RGB-Daten in die Farben übersetzt werden, die man im Video sieht).

Wenn ich hier und im Nachbarthread so einige Aussagen lese - wie z.B. "sRGB ist ein 8bit-Farbraum" oder "die GUI bekommt ein Signal aus der Grafikkarte" etc., ist hier vielleicht wirklich mal ein Grundlagenartikel angesagt...



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
ist hier vielleicht wirklich mal ein Grundlagenartikel angesagt... Bitte!



Antwort von pillepalle:

@ catsin

Du musst natürlich wieder jedes Wort das im Eifer des Gefechts fällt die Goldwaage legen ;) Das der sRGB Farbraum nur 8bit kann ist natürlich nicht richtig. Es wird nur meist im Zusammenhang mit einem 8bit Workflow verwendet. Frag doch mal jemanden von Adobe, ob die GUIs nicht auch andere Farbräume darstellen können. Ich bin mir sicher die geben Dir eine andere Antwort als die beiden Inder.

VG



Antwort von carstenkurz:

Das führt uns zwar jetzt hier zu weit weg, aber ich frage mich schon, wie man realistischerweise mit Windows 10 auf einem Notebook Display arbeitet, das mit 98% DCI/P3 Abdeckung oder BT.2020 beworben wird. Ich glaube, dass es kein Problem ist, bei einem darauf angepassten Videoplayer spezielle Funktionen des Grafikkartentreibers zu nutzen, um BT.2020 oder auch eines der üblichen HDR Formate auszugeben. Aber das GUI selbst? Bonbongrell mag ja zunächst mal beeindrucken, aber nicht alles was grell ist, ist farbverbindlich.



Antwort von pillepalle:

Ich kenne ehrlich gesagt überhaupt kein Laptop-Display mit dem man halbwegs Farbverbindlich arbeiten kann. Im Studio verlassen wir uns noch nicht mal auf das Display von iMacPro. Das ist auch viel undifferenzierter als das vom NEC.

Resolve kann das, wie wir ja immerhin in diesem Thread festgestllt haben, scheinbar nicht. Zumindest nicht verbindlich. Da braucht es den Umweg über die Decklink Karte. Photoshop aber schon. Das ist auch nur eine GUI innerhalb eines Betriebssystems.

VG



Antwort von Darth Schneider:

@ Kluster und Cantsin
Ich weiss schon das das zwei ganz verschiedene Dinge sind, auf den Kopf gefallen bin ich auch nicht.
Es war ja eigentlich einfach eine grundsätzliche Frage dabei, betreffend was ist besser...Gen4 und Gen5 ? Hat aber scheinbar niemand verstanden oder gelesen, mir hat darauf auf jeden Fall niemand darauf geantwortet...
Wenn es ja zu den Grundlagen gehört sollte das ja eigentlich kein grosses Problem sein...
Das hat doch ausserdem schlussendlich auch mit dem Color Management, im ganzen Prozess,, zu tun...Das ist nicht nur abhängig von Resolve, auch der verwendeten Kamera...vielleicht. Egal.
Und klar wäre ein Grundlagen Artikel für mich sinnvoll...;)
Gruss Boris



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
Ich kenne ehrlich gesagt überhaupt kein Laptop-Display mit dem man halbwegs Farbverbindlich arbeiten kann. ?
Hab schon 2004 mein damaliges Medion Notebook mit i1Dislpay kalibriert, wo ist das Problem?
Die verbauten TFT waren auch nicht schlechter als die mit Fuß und Stromkabel.



Antwort von klusterdegenerierung:

"Darth Schneider" hat geschrieben:
@ Kluster und Cantsin
Ich weiss schon das das zwei ganz verschiedene Dinge sind, auf den Kopf gefallen bin ich auch nicht.
Es war ja eigentlich einfach eine grundsätzliche Frage dabei, betreffend was ist besser...Gen4 und Gen5 ? Hat aber scheinbar niemand verstanden oder gelesen, mir hat darauf auf jeden Fall niemand geantwortet...
Wenn es ja zu den Grundlagen gehört sollte das ja eigentlich kein grosses Problem sein...
Das hat doch ausserdem schlussendlich auch mit dem Color Management zu tun...Egal.
Und klar wäre ein Grundlagen Artikel für mich sinnvoll...;)
Gruss Boris Kluster?
Wann habe ich Dich angesprochen?



Antwort von carstenkurz:

Und weil das 20€ Display im Medion kalibriert wurde ist es so gut wie ein 2000€ Profi-Monitor?



Antwort von Frank Glencairn:

Und weil's gerade zum Thema passt.....







Antwort von pillepalle:

carstenkurz hat geschrieben:
Und weil das 20€ Display im Medion kalibriert wurde ist es so gut wie ein 2000€ Profi-Monitor? In Kluster's Welt schon ;)


Aber wo wir gerade beim Thema sind. In Beselight schaffen sie es auch ein Color Management hin zu bekommen. Die Software allerdings auch ein sündhaft teuer Spaß...

https://www.youtube.com/watch?v=qEmzBFnBT4o

VG



Antwort von pillepalle:

"Darth Schneider" hat geschrieben:
@ Kluster und Cantsin
Ich weiss schon das das zwei ganz verschiedene Dinge sind, auf den Kopf gefallen bin ich auch nicht.
Es war ja eigentlich einfach eine grundsätzliche Frage dabei, betreffend was ist besser...Gen4 und Gen5 ? Hat aber scheinbar niemand verstanden oder gelesen, mir hat darauf auf jeden Fall niemand darauf geantwortet...
Wenn es ja zu den Grundlagen gehört sollte das ja eigentlich kein grosses Problem sein...
Das hat doch ausserdem schlussendlich auch mit dem Color Management, im ganzen Prozess,, zu tun...Das ist nicht nur abhängig von Resolve, auch der verwendeten Kamera...vielleicht. Egal.
Und klar wäre ein Grundlagen Artikel für mich sinnvoll...;)
Gruss Boris Die Gen5 soll die Hauttöne besser darstellen und natürlichere Farben haben. Jeder Kamerahersteller hat da so seine eigene Rezeptur wie man Farben darstellt und meist machen sie darum auch ein großes Geheimnis. Ab Minute 40 (weiss nicht wie man vimeo tagged) geht's um die Color Science bei verschiedenen Kameraherstellern, angefangen bei klassischen Filmemulsionen.

https://vimeo.com/298129056&t=40m0s

VG



Antwort von klusterdegenerierung:

carstenkurz hat geschrieben:
Und weil das 20€ Display im Medion kalibriert wurde ist es so gut wie ein 2000€ Profi-Monitor? Nö, das hat niemand gesagt, aber es wurde ja auch nicht über einen 2000€ Moni gesprochen, sondern über ein Notebook und ein kalibriertes Notebook ist besser eals kein kalibriertes Notebook.



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
In Kluster's Welt schon ;) Was soll denn das?
Nur weil Du einen 2000€ Moni brauchst, für was Grafik Pros auch mit alter grünstichiger Röhre und Blick auf Histogramme und Waveforms können.



Antwort von pillepalle:

@ kluster

Wir sind eben nicht alle so professionell wie Du. Lass uns die Diskussion bitte nicht auf so ein Niveau ziehen. Hab' Dich lieb :)

VG



Antwort von dienstag_01:

pillepalle hat geschrieben:
carstenkurz hat geschrieben:
Und weil das 20€ Display im Medion kalibriert wurde ist es so gut wie ein 2000€ Profi-Monitor? In Kluster's Welt schon ;)


Aber wo wir gerade beim Thema sind. In Beselight schaffen sie es auch ein Color Management hin zu bekommen. Die Software allerdings auch ein sündhaft teuer Spaß...

https://www.youtube.com/watch?v=qEmzBFnBT4o

VG Das beschriebene Farbmanagment ist im Grunde das gleiche wie in Resolve. Wie die Preview Pipeline funktioniert, steht auf einem anderen Blatt.



Antwort von pillepalle:

@ dienstag_01

Aber die scheint zu funktionieren und verbindlich zu sein... trotz Windows.

VG



Antwort von dienstag_01:

pillepalle hat geschrieben:
@ dienstag_01

Aber die scheint zu funktionieren und verbindlich zu sein... trotz Windows.

VG Nö. Und das Video ist vom Mac, oder?



Antwort von pillepalle:

Das läuft genauso auf Windows. Hab gestern erst ein Video von einem Coloristen verlinkt der es auf einem Windows Rechner verwendet. Und der arbeitet sogar wirklich für Hollywood

VG



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
@ kluster

Wir sind eben nicht alle so professionell wie Du. Lass uns die Diskussion bitte nicht auf so ein Niveau ziehen. Hab' Dich lieb :)

VG Sag mal ist Dir irgendwas zu Kopf gestiegen? Nur weil Du Dir einen EIZO gekauft hast machst Du jetzt einen Color Hero?
Was soll denn dieser Ton, ich bin doch nicht Dein Mitläufer! Affig!



Antwort von dienstag_01:

pillepalle hat geschrieben:
Das läuft genauso auf Windows. Hab gestern erst ein Video von einem Coloristen verlinkt der es auf einem Windows Rechner verwendet. Und der arbeitet sogar wirklich für Hollywood

VG Hollywood ist natürlich was wert ;)
Ich habe Baselight als Plugin für Avid genutzt, auf Windows, du brauchst mir also nichts zu erzählen.

Und wenn die Vorschau von Resolve auf Mac funktioniert, warum soll sie dann nicht für Baselight auf Mac funktionieren.
Daher ist es schon relevant, was das Video zeigt, wenn du glaubst, daraus entnehmen zu können, dass die Pipeline funktioniert.



Antwort von pillepalle:

Kluster, nimm mir das nicht Übel aber das einzige was affig ist, sind die Kommentare das man es mit jedem Billig-Monitor und ohne Farbmanagement genauso hin bekommt. Wenn Dich das Thema nicht interessiert, oder Du meinst schon über alles Bescheid zu wissen, kannst Du Dich doch entspannt zurück lehnen.

VG



Antwort von pillepalle:

@ dienstag_01

Und? Lief es nicht richtig?

VG

PS: Wenn Leute viel Geld bezahlen um damit zu arbeiten, meinst Du die machen das nur so aus Spaß, oder weil sie keine Ahnung haben?



Antwort von dienstag_01:

pillepalle hat geschrieben:
@ dienstag_01

Und? Lief es nicht richtig?

VG Als Plugin läuft es natürlich über seinen Host, also Avid. Dafür hatte ich eine Matrox Karte.

Allgemein hat es mir besser gefallen, als Resolve. Aber naja...



Antwort von mash_gh4:

pillepalle hat geschrieben:
Aber wo wir gerade beim Thema sind. In Beselight schaffen sie es auch ein Color Management hin zu bekommen. Die Software allerdings auch ein sündhaft teuer Spaß...

https://www.youtube.com/watch?v=qEmzBFnBT4o ich finde, das ist eine ganz gut verständliche zusammenfassung der allerwichtigsten einstellungen und ihrer auswirkung.

baselight ist ganz bestimmt in vielerlei hinsicht ein tolles werkzeug, das tatsächlich den ansprüchen an eine kompromisslose color grading lösung auf dem stand der zeit gerecht wird, während resolve das ja eher nur in den werbesprüchen von sich zu behaupten pflegt.

es ist ja ohnehin nicht so, dass man im falle von baselight, mistika, flame usw. nicht auch im regelfall spezielle ausgabekarten nutzen würde, um wirklich teures anzeige-equipment anzubinden, aber im gegensatz zum resolve macht man gar nicht erst viel wind darum, sondern bietet vielmehr völlig selbstverständlich auch in der GUI eine einigermaßen brauchbare vorschau an, weil es natürlich auch im professionellen umfeld reichlich kontraproduktiv wirkt, wenn sich verschiedene varianten der anzeige widersprechen od. einfach etwas irreführend falsches zeigen.



Antwort von rdcl:

Man kann in Resolve doch sowohl für den externen Output, als auch für den GUI-Viewer ein Calibration-Lut einstellen.



Antwort von pillepalle:

rdcl hat geschrieben:
Man kann in Resolve doch sowohl für den externen Output, als auch für den GUI-Viewer ein Calibration-Lut einstellen. Wobei das ja wohl scheinbar eher dazu dienen soll ein Color Management zu umgehen, wenn man z.B. mit Consumer-Geräten arbeitet, wie einem in dieser PDF erklärt wird:

https://www.google.com/url?sa=t&rct=j&q ... WwDQK-Y9kB

Tatsächlich findet man zum Thema Color Management erstaunlich wenig im Netz, obwohl prinzipiell fast alle Software-Hersteller damit werben, dass es mit ihrer Software möglich sei. Ziemlich gut ist übrigens der Beginners Guide von frame.io zu einem Color Management Workflow bei den Adobe Programmen. Denn hier finden sich auch Angaben zu Premiere Pro, After Effects und dem Media Encoder (Kapitel 4 zum Color Management bei Adobe Video Apps).

https://blog.frame.io/2019/08/26/color- ... -abobe-cc/

Lesenswert in dem Zusammenhang auch der dort verlinkte Artikel zur Erstellung einer Grading Suite:

https://blog.frame.io/2019/07/22/buildi ... ing-suite/

Für Resolve findet man sowas in einer so ausführlichen Form leider nicht. Aber immerhin ein paar Diagramme aus Bezahl-Workshops zum Thema Color Management in Resolve. Wie z.B. diese allgeimeine Übersicht:

zum Bild http://giotta.de/RCM_0.jpg

Oder diese Darstellung, der die einstellbaren Farbräume beim Resolve Color Managed Workflow und dem des Resolve Color Managed Simplified Workflows darstellt. Also die verschiedenen Farbräume für Input Color Space (Farbraum des Quellmaterials), Timeline Color Space (Arbeitsfarbraum) und Output Color Space (Monitor- und Renderfarbraum).


zum Bild


Genauso wie diese Grafik, die zeigt das Resolve non destruktiv arbeitet und auch in kleinen Arbeitsfarbräumen (wie z.B. REC709) die Farben die außerhalb des Farbraum liegen erhalten bleiben. Bei einer Korrekten Angabe vom Input Color Space, werden diese in den neuen Farbraum gemapped.


zum Bild


VG



Antwort von cantsin:

pillepalle hat geschrieben:
rdcl hat geschrieben:
Man kann in Resolve doch sowohl für den externen Output, als auch für den GUI-Viewer ein Calibration-Lut einstellen. Wobei das ja wohl scheinbar eher dazu dienen soll ein Color Management zu umgehen, wenn man z.B. mit Consumer-Geräten arbeitet, wie einem in dieser PDF erklärt wird:

https://www.google.com/url?sa=t&rct=j&q ... WwDQK-Y9kB Das ist ein ziemlich altes Dokument aus dem Jahr 2013/14, das sich noch auf Resolve Version 10 ("At the time of this writing Resolve (10.1.4)") bezieht und dessen Informationen daher nicht mehr stimmen....



Antwort von Bluboy:

Fast alle Bildschirm-Color-Verbieger greifen auf die
.icc-Profile in C:\Windows\system32\spool\drivers\color. zu



Antwort von pillepalle:

@ catsin

Ja, aber der Sinn einer eigenen Output, oder GUI LUT ist derselbe.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
@ catsin

Ja, aber der Sinn einer eigenen Output, oder GUI LUT ist derselbe. In dem Dokument steht, dass der Output von Resolve nicht color-managed ist, und das trifft so eben nicht mehr ganz zu.

Und ist tatsächlich ein Unterschied von den alten zu den heutigen Resolve-Versionen: Bei den alten hatte die im Betriebssystem (mit DisplayCal oder der Bordsoftware von Spyder oder X-rite) installierte Farbkalibrierung keinen Einfluss auf die Farben in Resolves eigenem Viewer, bei den heutigen ist das der Fall, funktioniert aber eben nur richtig, wenn in Resolve sRGB-Output eingestellt wird.



Antwort von mash_gh4:

ein wesentliches problem besteht darin, dass eben resolve noch immer nur eine einzige monitoring einstellung bzw. LUT vorsieht, während andere programme sinnvollerweise mehrere solche verarbeitungsäste (im baselight: cursors, in mistika: monitor-filters....) vorsehen, um tatsächlich für alle angeschlossenen anzeigegeräte jeweils die notwendigen anpassungen vornehmen zu können.

die adaption zw. verschiedenen standardisierten farbräumen erledigt man ohnehin auch hier besser mit fertig vorbereiteten farb-matrix-transformationen + transferfunktionsumwandlung. nur für irgendwelche darüber hinausgehenden eigenheiten der anzeigegeräte ist oft tatsächlich unumgänglich auf 3D LUTs zurückzugreifen.

wie bereits erwähnt, ist das ganze in laufe der letzte jahre auch im resolve ständig verändert und natürlich auch ein klein wenig verbessert worden. im vergleich zu anderen anwendungen nimmt es sich es trotzdem noch immer extrem unflexibel, benutzerunfreundlich und unzuverlässig aus. das ist kaum vernünftig nachvollziehbar, weil man ohne eine derartige einigermaßen verlässliche ausgangsbasis eigentlich gar nicht erst mit anspruchsvollerer farbbearbeitung anzufangen braucht!



Antwort von roki100:

Bluboy hat geschrieben:
Fast alle Bildschirm-Color-Verbieger greifen auf die
.icc-Profile in C:\Windows\system32\spool\drivers\color. zu 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.



Antwort von pillepalle:

cantsin hat geschrieben:
Und ist tatsächlich ein Unterschied von den alten zu den heutigen Resolve-Versionen: Bei den alten hatte die im Betriebssystem (mit DisplayCal oder der Bordsoftware von Spyder oder X-rite) installierte Farbkalibrierung keinen Einfluss auf die Farben in Resolves eigenem Viewer, bei den heutigen ist das der Fall, funktioniert aber eben nur richtig, wenn in Resolve sRGB-Output eingestellt wird. 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. Man kann zwar jetzt argumentieren, eine richtige Darstellung sei dann nicht garantiert, aber den Gegenbeweis wird praktisch die Decklink Karte zeigen. Dann kann man nämlich den Viewer sowohl einmal über die Decklink und einmal über die Grafikkarte ausgeben und miteinander vergleichen.

VG



Antwort von Bluboy:

roki100 hat geschrieben:
Bluboy hat geschrieben:
Fast alle Bildschirm-Color-Verbieger greifen auf die
.icc-Profile in C:\Windows\system32\spool\drivers\color. zu 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. Du kannst doch *.ICC nachinstalliren, oder wenn Du einen neuen Monitor kaufst, macht dessen Software das.

Deine Schwarz-Weiß Röhre wird deswegen aber auch nicht Schwaz-Weißer.



Antwort von dienstag_01:

cantsin hat geschrieben:
pillepalle hat geschrieben:
@ catsin

Ja, aber der Sinn einer eigenen Output, oder GUI LUT ist derselbe. In dem Dokument steht, dass der Output von Resolve nicht color-managed ist, und das trifft so eben nicht mehr ganz zu.

Und ist tatsächlich ein Unterschied von den alten zu den heutigen Resolve-Versionen: Bei den alten hatte die im Betriebssystem (mit DisplayCal oder der Bordsoftware von Spyder oder X-rite) installierte Farbkalibrierung keinen Einfluss auf die Farben in Resolves eigenem Viewer, bei den heutigen ist das der Fall, funktioniert aber eben nur richtig, wenn in Resolve sRGB-Output eingestellt wird. Ich glaube, dass ist ein Missverständnis. Im Handbuch steht das sinngemäß nur für Mac.



Antwort von dienstag_01:

Bluboy hat geschrieben:
roki100 hat geschrieben:


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. Du kannst doch *.ICC nachinstalliren, oder wenn Du einen neuen Monitor kaufst, macht dessen Software das.

Deine Schwarz-Weiß Röhre wird deswegen aber auch nicht Schwaz-Weißer. Die ICC Profile werden von Resolve nicht genutzt. Nicht unter Windows.



Antwort von roki100:

Bluboy hat geschrieben:
roki100 hat geschrieben:


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. Du kannst doch *.ICC nachinstalliren, oder wenn Du einen neuen Monitor kaufst, macht dessen Software das. Eben, es ist so einfach. Doch in DR muss es doch eine Möglichkeit geben, diese auch passend auszuwählen. Dann wundern sich viele, warum das fertig exportierte Video aus DR, anders mit Win Player X/Y aussieht....



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Die ICC Profile werden von Resolve nicht genutzt. Nicht unter Windows. ja --ich glaub auch, dass man resolve unter windows od. linux nur mit jeweils selbst errechneten LUTs einigermaßen an die tatsächlichen erfordernisse der ausgabegeräte anpassen kann. am mac ist das anders.

leider muss man dann halt auch diese LUTs für jede ausgavariante von grund auf neu ausmessen und generieren, weil es eben in kein vernünftiges größeres frabmanagementsystem integriert ist.

ICC-profile sind übrigens leider im zusammenhang mit videoverarbeitung nicht unbedingt als optimale lösung zu verstehene, weil sie z.b. HDR, aber auch einigen einfacheren anforderungen, nicht klar kommen.

OpenColorIO + ergänzende 3D-korrektur-LUTs machen hier deutlich mehr sinn.



Antwort von Frank Glencairn:

roki100 hat geschrieben:

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.



Antwort von cantsin:

dienstag_01 hat geschrieben:
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).



Antwort von mash_gh4:

roki100 hat geschrieben:
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.



Antwort von roki100:

"Frank Glencairn" hat geschrieben:
roki100 hat geschrieben:

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...



Antwort von mash_gh4:

cantsin hat geschrieben:
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.



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
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.



Antwort von pillepalle:

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



Antwort von roki100:

mash_gh4 hat geschrieben:
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".



Antwort von cantsin:

pillepalle hat geschrieben:
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:


zum 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.)



Antwort von pillepalle:

@ 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.



Antwort von Bluboy:

Ohne Color Korrektur schauts meisten recht Lila aus ;-))



Antwort von roki100:

Blueboy, du hast echt ne coole Friseur!



Antwort von pillepalle:

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



Antwort von Bluboy:

Input UND Output



Antwort von carstenkurz:

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.


zum Bild




Antwort von mash_gh4:

pillepalle hat geschrieben:
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.



Antwort von cantsin:

mash_gh4 hat geschrieben:
pillepalle hat geschrieben:
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?



Antwort von dienstag_01:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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).



Antwort von carstenkurz:

pillepalle hat geschrieben:
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.



Antwort von Frank Glencairn:

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.



Antwort von carstenkurz:

mash_gh4 hat geschrieben:
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 Schwanz, 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.



Antwort von dienstag_01:

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.



Antwort von cantsin:

carstenkurz hat geschrieben:
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?



Antwort von pillepalle:

Eigentlich ist Photoshop auch Grafikkartenbeschleunigt...

VG



Antwort von carstenkurz:

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.



Antwort von cantsin:

carstenkurz hat geschrieben:
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.





Antwort von pillepalle:

@ 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.



Antwort von cantsin:

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.)



Antwort von carstenkurz:

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.



Antwort von dienstag_01:

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.



Antwort von carstenkurz:

pillepalle hat geschrieben:
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.



Antwort von mash_gh4:

carstenkurz hat geschrieben:
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.



Antwort von mash_gh4:

carstenkurz hat geschrieben:
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.



Antwort von Bluboy:

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



Antwort von dienstag_01:

Bluboy hat geschrieben:
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.



Antwort von mash_gh4:

pillepalle hat geschrieben:
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.



Antwort von carstenkurz:

Naja, aber, ehrlich gesagt macht es die Verwirrung im Resultat nur noch größer...

Das Problem ist einfach, dass es in der Praxis zu viele Einflüsse gibt und es auch fast unmöglich ist, für jeden dieser Einflüsse eine saubere Dokumentation zu pflegen. Auch weil die Softwareschnittstellen sich ständig ändern, in wenigen IT Bereichen gibt es so eine schnelle Entwicklung wie bei den GPUs.

Man kann bestenfalls exemplarisch Referenzsysteme nach bestimmten Schwerpunkten definieren.



Antwort von dienstag_01:

carstenkurz hat geschrieben:
Naja, aber, ehrlich gesagt macht es die Verwirrung im Resultat nur noch größer...

Das Problem ist einfach, dass es in der Praxis zu viele Einflüsse gibt und es auch fast unmöglich ist, für jeden dieser Einflüsse eine saubere Dokumentation zu pflegen. Auch weil die Softwareschnittstellen sich ständig ändern, in wenigen IT Bereichen gibt es so eine schnelle Entwicklung wie bei den GPUs.

Man kann bestenfalls exemplarisch Referenzsysteme nach bestimmten Schwerpunkten definieren. Mit anderer Software funktioniert ja das Farbmanagment unter Windows auch. An den GPUs kanns daher nicht liegen.



Antwort von mash_gh4:

carstenkurz hat geschrieben:
Das Problem ist einfach, dass es in der Praxis zu viele Einflüsse gibt und es auch fast unmöglich ist, für jeden dieser Einflüsse eine saubere Dokumentation zu pflegen. Auch weil die Softwareschnittstellen sich ständig ändern, in wenigen IT Bereichen gibt es so eine schnelle Entwicklung wie bei den GPUs. ich geb dir ja recht, dass die ganze sache fürchterlich nervt!

trotzdem -- man kann sich in dieser frage einfach nicht damit begnügen, irgendwelche zusatzhardware, die in der praxis fast unvermeidlich nur noch neue weitere treiberprobleme und inkompatibilitäten mit sich bringen, als lösung anzupreisen.

das wäre fast so, als würde man sich darauf hinausreden, dass eben manche datenträger -- disketten, DVDs oder USB-speicher-sticks --, wenn sich darauf wertvolles befindet, auch nur mit hardware eines ganz bestimmten prestigeträchtigen herstellers gelesen/kopiert/übertragen werden sollten, damit der inhalt der gespeicherten dokumente unverändert bleibt.

das ist jetzt nicht ganz so weit hergeholt, da in heutigen digitalen videoverbindungsprotokollem -- völlig egal, ob es um DVI-anschluss, HDI, SDI od. Display-Port handelt -- auch nur mehr derartige klar festgelegte zahlenwerte übergeben werden, von denen man ganz ähnliches wie bei einem übertragenen od. abgespeicherten textfile erwartet -- also: unveränderte buchstaben. für irgendwelchen aberglauben oder auswüchse, wie man sie etwa von analog-HiFi-esoterikern her kennt, bleibt da denkbar wenig platz zwischen den tatsächlich benutzten bits und bytes über.



Antwort von dienstag_01:

mash_gh4 hat geschrieben:
carstenkurz hat geschrieben:
Das Problem ist einfach, dass es in der Praxis zu viele Einflüsse gibt und es auch fast unmöglich ist, für jeden dieser Einflüsse eine saubere Dokumentation zu pflegen. Auch weil die Softwareschnittstellen sich ständig ändern, in wenigen IT Bereichen gibt es so eine schnelle Entwicklung wie bei den GPUs. ich geb dir ja recht, dass die ganze sache fürchterlich nervt!

trotzdem -- man kann sich in dieser frage einfach nicht damit begnügen, irgendwelche zusatzhardware, die in der praxis fast unvermeidlich nor noch neue weitere treiberprobleme und inkompatibilitäten mit sich bringen, als lösung anzupreisen.

das wäre fast so, als würde sich darauf hinausreden, das eben manche datenträger -- disketten, DVDs oder USB-speicher-sticks --, wenn es sich darauf wertvolles befindet, auch nur mit hardware eines ganz bestimmten prestigeträchtigen herstellers gelesen/kopiert/übertragen werden sollte, damit der inhalt der gespeicherten dokumente unverändert bleibt.

das ist jetzt nicht ganz so weit hergeholt, da in heutigen digitalen videoverbindungsprotokollem -- völlig egal, ob es um DVI-anschluss, HDI, SDI od. Display-Port handelt -- auch nur mehr derartige klar festgelegte zahlenwerte übergeben werden, von denen man ganz ähnliches wie bei einem übertragenen od. abgespeicherten textfile erwartet -- also: unveränderte buchstaben. für irgendwelchen aberglauben oder auswüchse, wie man sie etwa von analog-HiFi-esoterikern her kennt, bleibt da denkbar wenig platz zwischen den tatsächlich benutzten bits und bytes über. Historisch ist es natürlich genau umgekehrt, die Anbieter von Schnitt- und Color Correction Systemen MUSSTEN eigene Hardware anbieten. Da ging es um Performance aber auch, dass z.B. FBAS aus einer Consumergrafikkarte nun mal nicht das Referenzsignal für Farbkorrektur ist.



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Historisch ist es natürlich genau umgekehrt, die Anbieter von Schnitt- und Color Correction Systemen MUSSTEN eigene Hardware anbieten. Da ging es um Performance aber auch, dass z.B. FBAS aus einer Consumergrafikkarte nun mal nicht das Referenzsignal für Farbkorrektur ist. ja -- historisch und von den ganz spezifischen anforderungen im studio-umfeld her versteh ich's ohnehin. ich würde ja auch sicher niemandem raten, für längere kabelstrecken auf HDMI, DP od. USB-C aus dem consumerumfeld zu setzen. trotzdem muss man halt genauso klar sehen, wo manchens zeug, das nur mehr den charme einfachster computergrafikkarten aus den 90er jahren weiter am leben erhält, absolut keinen sinn macht bzw. besser durch vernünftig funktionierende software ersetzt wird.



Antwort von rdcl:

Irgendwie stehe ich auf dem Schlauch. Ich verstehe das Problem nicht.
- Wer einen externen Preview-Monitor hat, der LUTs intern speichern kann, kalibriert und profiliert und speichert direkt im Monitor.
- Wer einen externen Preview-Monitor hat, der keine LUTs intern speichern kann, kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den Preview-Monitor an.
- Wer keinen externen Preview-Monitor hat kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den GUI-Viewer an.
- Wer es ganz genau haben will kalibriert und profiliert sowohl GUI-Monitor als auch Preview-Monitor und wendet beide LUTs entsprechend in Resolve an.
Damit sollten doch alle Möglichkeiten offen stehen, egal ob über Grafikkarte oder I/O-Karte.

Wie machen die Leute, die damit Probleme haben, das denn dann bei z.B. Premiere oder AE, wo man gar keine Displayluts anwenden kann?



Antwort von cantsin:

rdcl hat geschrieben:
Irgendwie stehe ich auf dem Schlauch. Ich verstehe das Problem nicht.
- Wer einen externen Preview-Monitor hat, der LUTs intern speichern kann, kalibriert und profiliert und speichert direkt im Monitor.
- Wer einen externen Preview-Monitor hat, der keine LUTs intern speichern kann, kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den Preview-Monitor an.
- Wer keinen externen Preview-Monitor hat kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den GUI-Viewer an.
- Wer es ganz genau haben will kalibriert und profiliert sowohl GUI-Monitor als auch Preview-Monitor und wendet beide LUTs entsprechend in Resolve an.
Damit sollten doch alle Möglichkeiten offen stehen, egal ob über Grafikkarte oder I/O-Karte. Nicht, wenn man wie pillepalle alles, was Du oben beschreibst, im P3- statt im sRGB-/Rec709-Farbraum machen will.



Antwort von dienstag_01:

rdcl hat geschrieben:
Irgendwie stehe ich auf dem Schlauch. Ich verstehe das Problem nicht.
- Wer einen externen Preview-Monitor hat, der LUTs intern speichern kann, kalibriert und profiliert und speichert direkt im Monitor.
- Wer einen externen Preview-Monitor hat, der keine LUTs intern speichern kann, kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den Preview-Monitor an.
- Wer keinen externen Preview-Monitor hat kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den GUI-Viewer an.
- Wer es ganz genau haben will kalibriert und profiliert sowohl GUI-Monitor als auch Preview-Monitor und wendet beide LUTs entsprechend in Resolve an.
Damit sollten doch alle Möglichkeiten offen stehen, egal ob über Grafikkarte oder I/O-Karte.

Wie machen die Leute, die damit Probleme haben, das denn dann bei z.B. Premiere oder AE, wo man gar keine Displayluts anwenden kann? Preview Lut funktioniert nicht im Clean Video Feed. Wahrscheinlich ist mit Preview der über eine Monitoring Card angebundene Monitor gemeint. Oder?



Antwort von mash_gh4:

ja -- im prinzip sollte es zumindest so ähnlich gehen...

ich hab hier gerade zwei schirme vor mir, von denen der eine eher nur als normaler sRGB computerbildschirm taugt bzw. genutzt wird, und einen zweiten, der auch ein bisserl gehobenere ansprüche erfüllt bzw. als vorschau für grafikanwendungen besser geeignete ist, wenn auch nicht unbedingt in der liga, die hier ursprünglich zur debatte stand. um die qualitäten dieses zweiten schirms voll auszuschöpfen zu können, müsste man aber beide schirme getrennt und geringfügig voneinander abweichend konfigurieren. so weit ich weiß, ist genau das bisher mit mehreren schirmen, die an der normalen grafikkarte hängen, unter resolve nicht möglich.

das größere problem sehe ich allerdings weiterhin darin, dass sehr viele resolve-benutzer sich über diese ganze geschichte ohnehin noch nie gedanken gemacht haben und sehr oft mit defaulteinstellungen arbeiten, die eben nur für "externe" rec709 monitore sinn machen, nicht aber für die darstellung am computerbildschirm bzw. den unterschied zur sRGB computerdarstellungskonventionen gar nicht erst beachten.

man kann sich zwar natürlich über die bedeutsamkeit dieser voraussetzungen streiten, da ja die unterscheidlichen gammerkurven ihrer funktion nach eher nur auf die umgebenden lichtverhältnisse und die damit verbundenen wahrnehmungsverhältnisse bezug nehmen, trotzdem schadet es nicht, wenn werkzeuge tatsächlich eingermaßen exakt und verlässlich den vorgegebenen normen folgen und einem damit gestalterische entscheidungen erleichtern.



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:
Irgendwie stehe ich auf dem Schlauch. Ich verstehe das Problem nicht.
- Wer einen externen Preview-Monitor hat, der LUTs intern speichern kann, kalibriert und profiliert und speichert direkt im Monitor.
- Wer einen externen Preview-Monitor hat, der keine LUTs intern speichern kann, kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den Preview-Monitor an.
- Wer keinen externen Preview-Monitor hat kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den GUI-Viewer an.
- Wer es ganz genau haben will kalibriert und profiliert sowohl GUI-Monitor als auch Preview-Monitor und wendet beide LUTs entsprechend in Resolve an.
Damit sollten doch alle Möglichkeiten offen stehen, egal ob über Grafikkarte oder I/O-Karte.

Wie machen die Leute, die damit Probleme haben, das denn dann bei z.B. Premiere oder AE, wo man gar keine Displayluts anwenden kann? Preview Lut funktioniert nicht im Clean Video Feed. Wahrscheinlich ist mit Preview der über eine Monitoring Card angebundene Monitor gemeint. Oder? Ah, verstehe. Ok, das ist ein Problem wenn man keine I/O-Karte nutzt. Aber funktioniert da dann nicht das GUI-Viewer LUT?
Hier ist ein Bild dazu:
https://www.richardlackey.com/wp-conten ... -image.jpg

Für den externen Monitor via Decklink wäre es das "Video Monitor LUT", und für den GUI-Viewer über die Grafikkarte das "Color Viewer LUT". Zumindest in der Theorie.



Antwort von mash_gh4:

rdcl hat geschrieben:
Für den externen Monitor via Decklink wäre es das "Video Monitor LUT", und für den GUI-Viewer über die Grafikkarte das "Color Viewer LUT". Zumindest in der Theorie. genau! -- für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht.



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

Preview Lut funktioniert nicht im Clean Video Feed. Wahrscheinlich ist mit Preview der über eine Monitoring Card angebundene Monitor gemeint. Oder? Ah, verstehe. Ok, das ist ein Problem wenn man keine I/O-Karte nutzt. Aber funktioniert da dann nicht das GUI-Viewer LUT?
Hier ist ein Bild dazu:
https://www.richardlackey.com/wp-conten ... -image.jpg

Für den externen Monitor via Decklink wäre es das "Video Monitor LUT", und für den GUI-Viewer über die Grafikkarte das "Color Viewer LUT". Zumindest in der Theorie. Genau. Die Preview Lut funktioniert nicht, die für den Viewer schon. Der Clean Video Feed scheint also nochmal was ganz anderes zu sein, was gar keine Konfigurationsmöglichkeiten hat.



Antwort von rdcl:

mash_gh4 hat geschrieben:
rdcl hat geschrieben:
Für den externen Monitor via Decklink wäre es das "Video Monitor LUT", und für den GUI-Viewer über die Grafikkarte das "Color Viewer LUT". Zumindest in der Theorie. genau! -- für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht. Aber mit fixen Umrechnungsvorgaben würde doch die Profilierung des Monitors nicht mit berücksichtigt werden. Welche meisten Programme machen das denn besser? Premiere, AE oder Avid bieten z.B. überhaupt keine Display-Luts an.



Antwort von dienstag_01:

rdcl hat geschrieben:
mash_gh4 hat geschrieben:


genau! -- für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht. Aber mit fixen Umrechnungsvorgaben würde doch die Profilierung des Monitors nicht mit berücksichtigt werden. Welche meisten Programme machen das denn besser? Premiere, AE oder Avid bieten z.B. überhaupt keine Display-Luts an. Das stimmt so nicht, Avid schon. Bei Fullscreen Playback kann ich wählen, ob sRGB oder 709 und ich weiß nicht, welche noch.



Antwort von mash_gh4:

rdcl hat geschrieben:
Aber mit fixen Umrechnungsvorgaben würde doch die Profilierung des Monitors nicht mit berücksichtigt werden. schau dir einmal die seite 1379f im resolve 16 handbuch an.

leider ist das dort beschriebene ("Applying OCIO LUTs in the Viewer") nicht im resolve selbst anwendbar, sondern nur in den fusion viewern, aber im wesentlichen ist das ungefähr die herangehensweise, wie ich das von all den anderen programmen kenne, mit denen ich gerne arbeite.



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Aber mit fixen Umrechnungsvorgaben würde doch die Profilierung des Monitors nicht mit berücksichtigt werden. Welche meisten Programme machen das denn besser? Premiere, AE oder Avid bieten z.B. überhaupt keine Display-Luts an. Das stimmt so nicht, Avid schon. Bei Fullscreen Playback kann ich wählen, ob sRGB oder 709 und ich weiß nicht, welche noch. Aber das hat nichts mit einer akkuraten Ausgabe zu tun. Das ist eine Farbraum-Simulation, wo der Monitor selbst auch garnicht berücksichtigt wird.



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

Das stimmt so nicht, Avid schon. Bei Fullscreen Playback kann ich wählen, ob sRGB oder 709 und ich weiß nicht, welche noch. Aber das hat nichts mit einer akkuraten Ausgabe zu tun. Das ist eine Farbraum-Simulation, wo der Monitor selbst auch garnicht berücksichtigt wird. Kann sein, aber wie gesagt, in Resolve geht das genausowenig für die Vollbildvorschau.



Antwort von mash_gh4:

rdcl hat geschrieben:
Das ist eine Farbraum-Simulation, wo der Monitor selbst auch garnicht berücksichtigt wird. naja -- vielleicht kann man ja tatsächlich Color Management bis zu einem gewissen grad auch als Farbraum-Simulation od. eben "...-Transformation" verstehen. ;)

du darfst nicht vergessen, dass derartige programme heute intern ohnehin immer mit viel größeren arbeitsfarbräumen rechnen und damit jede ausgabe an einem der displays in wahrheit ständig solche übersetzungen benötigt.



Antwort von Bluboy:

Jetzt stellt sich nur noch die Frage ob es eine Simulation ist, oder ob man es auch Exportieren kann.



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Genau. Die Preview Lut funktioniert nicht, die für den Viewer schon. Der Clean Video Feed scheint also nochmal was ganz anderes zu sein, was gar keine Konfigurationsmöglichkeiten hat. es gibt workarounds dafür:

https://www.steakunderwater.com/wesuckl ... php?t=3689

...allerdings sind die fast genauso krank wie eine firmenpolitik, die solch idiotischen umwege erzwingt. :(

benutzer der freien version sind aber ohnehin davon verschont, weil die ja bekanntlich noch immer keine vernünftige vollbildausgabe ohne zusätzliche BMD-hardware nutzen dürfen.



Antwort von pillepalle:

Das ich hier über den P3 Farbraum und einen Workflow damit diskutiere ist doch nur ein Beispiel für viele. Das gilt genauso für BT2020 oder die Darstellung eines HDR Bildes im SDR Modus ect... Heutzutage arbeiten viele Kreative nicht nur mit unterschiedlichen Materialien für unterschiedliche Anwendungen, sondern auch in ganz unterschiedlichen Bereichen, wie z.B. Foto und Video, oder Design. An einem Tag arbeite ich am Layout eines Buches und brauche eine Proof-Ansicht für einen Druck. Am nächsten grade ich vielleicht einen Video. Jetzt kann man sich natürlich für jede Aufgabe einen eigenen Monitor/System hinstellen, oder einen Monitor jedes Mal neu kalibrieren, aber das ist beides recht umständlich. Einen Monitor zu haben der vielen Aufgaben gewachsen ist und den ich mal schnell von z.B. AdobeRGB mit Gamma 2.2 auf REC709/BT1886 mit Gamma 2.4 umstellen kann ist einfach praktisch.

Dazu muss man sich aber mit dem jeweiligen Workflow und Farbmanagement auseinandersetzen. Und was z.B. bei Photoshop gut funktioniert und über Jahre etabliert ist, ist in anderen Bereichen mit anderer Software offensichtlich nicht so einfach, bzw. ganz anders. Das gilt es einfach zu verstehen wenn man konsitente Ergebnisse haben möchte. Deshalb hole ich mir ja jetzt für's Graden mit Resolve auch eine Decklink-Karte. Nichtsdestotrotz möchte ich die Vorgänge dabei verstehen und schauen was in der Praxis gut funktioniert und was weniger. Und das geht nur mit Erfahrung und durch ausprobieren. Ich vergleiche auch einen Softproof (eine Proof-Ansicht am Monitor) mit einem Proof, warum soll ich eine P3 Darstellung am Monitor dann nicht auch mal mit einer P3 Projektion vergleichen, wenn sich die Gelegenheit bietet? Das ist einfach mein eigner Anspruch die Dinge so gut zu machen wie ich kann und zu wissen/verstehen was ich da gerade mache. Dass das Thema nicht besonders sexy ist und es nicht super viel Spaß macht sich mit Normen und Standards auseinander zu setzen, ist mir selber schon klar :)

VG



Antwort von Frank Glencairn:

roki100 hat geschrieben:

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... Ja, aber YT erwartet 709 (wenn wir HDR jetzt mal außen vor lassen - das ist noch ne ganz andere Diskussion), um das dann wahlweise auf einem sRGB(Computer), TV oder Oled(Handy) Panel abzuspielen, bei letzerem dreht der Helligkeitssensor, und irgendwelche Blaufilter an der Farbe, bei TVs irgendwelche Verschlimmbesserungsprofile, und was der durchschnittliche Homeoffice Computer ausspuckt möchte ich gar nicht wissen. Verschiedene Player (managed und unmanaged), Betriebssysteme, und Browser/Apps tun ein Übriges, um das Bild jedesmal anders aussehen zu lassen.

Selbst wenn der geneigte YT-Profi nur auf seine Scopes achtet, und daß die halbwegs in einem plausiblen Bereich sind, langt das für alle. Sämtliche Nuancen die da drüber hinaus gehen, werden von den unterschiedlichen Endgeräten sowieso vernichtet.

Deshalb sagte ich, daß es wurscht ist. Für TV etwas weniger wurscht, und nur für Kino spielt es wirklich ne Rolle, weil Kino quasi das einzig einigermaßen kontrollierte Endgerät ist. Aber selbst da ist alles gut, wenn das Bild aussieht wie rec709 am heimischen Monitor - man muß nicht zwingend das letzte Fitzelchen des Farbraumes total ausschöpfen.

Hat man also ein einigermaßen stabil kalibriertes 709 System, dann kümmert sich Resolve (oder andere) quasi automatisch darum, daß es dann auch im DCP passt, ohe daß man irgendwo dran drehen muß.



Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:

für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht. Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest.
Irgendeine generische Umrechnug, starr auf einen nicht referenzierten Monitor anzuwenden ist das Gegenteil von flexibel.

Die einzige Frage ist eher, hab ich die LUT im Monitor (wenn er das überhaupt kann), und wie gut ist da die Umsetzung, sprich wir da aus dem Cube vielleicht nur ne 2D LUT draus, ist die Interpolation da Tetrahedal oder Trilinear etc. oder lass ich das lieber mein CC Programm machen, oder vielleicht sogar ne externe LUT Box?

Wer Zeit zum lesen hat, dem kann ich das hier empfehlen, ich denke da werden viele Fragen beantwortet:
https://nick-shaw.github.io/cinematicco ... enges.html



Antwort von rdcl:

"Frank Glencairn" hat geschrieben:
mash_gh4 hat geschrieben:

für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht. Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest.
Irgendeine generische Umrechnug, starr auf einen nicht referenzierten Monitor anzuwenden ist das Gegenteil von flexibel.

Die einzige Frage ist eher, hab ich die LUT im Monitor (wenn er das überhaupt kann), und wie gut ist da die Umsetzung, sprich wir da aus dem Cube vielleicht nur ne 2D LUT draus, ist die Interpolation da Tetrahedal oder Trilinear etc. oder lass ich das lieber mein CC Programm machen, oder vielleicht sogar ne externe LUT Box?

Wer Zeit zum lesen hat, dem kann ich das hier empfehlen, ich denke da werden viele Fragen beantwortet:
https://nick-shaw.github.io/cinematicco ... enges.html Meine Rede. Ich weiß auch noch immer nicht welche "meisten" Programme dass jetzt großartig besser machen.



Antwort von klusterdegenerierung:

rdcl hat geschrieben:
"Frank Glencairn" hat geschrieben:


Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest.
Irgendeine generische Umrechnug, starr auf einen nicht referenzierten Monitor anzuwenden ist das Gegenteil von flexibel.

Die einzige Frage ist eher, hab ich die LUT im Monitor (wenn er das überhaupt kann), und wie gut ist da die Umsetzung, sprich wir da aus dem Cube vielleicht nur ne 2D LUT draus, ist die Interpolation da Tetrahedal oder Trilinear etc. oder lass ich das lieber mein CC Programm machen, oder vielleicht sogar ne externe LUT Box?

Wer Zeit zum lesen hat, dem kann ich das hier empfehlen, ich denke da werden viele Fragen beantwortet:
https://nick-shaw.github.io/cinematicco ... enges.html Meine Rede. Ich weiß auch noch immer nicht welche "meisten" Programme dass jetzt großartig besser machen. Und ich weiß garnicht worüber hier eigentlich geredet wird!



Antwort von klusterdegenerierung:

In diesem Zusammenhang stelle ich mal eine banal klingende aber ernst zunehmende Frage, dessen Inhalt und Kosequenz diese ganze Diskussion eigentlich schon obsolet macht, solange man nicht wie ein Profi Farben via Pipette und RGB Parade interpretiert.

Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau?



Antwort von dienstag_01:

mash_gh4 hat geschrieben:
dienstag_01 hat geschrieben:
Genau. Die Preview Lut funktioniert nicht, die für den Viewer schon. Der Clean Video Feed scheint also nochmal was ganz anderes zu sein, was gar keine Konfigurationsmöglichkeiten hat. es gibt workarounds dafür:

https://www.steakunderwater.com/wesuckl ... php?t=3689

...allerdings sind die fast genauso krank wie eine firmenpolitik, die solch idiotischen umwege erzwingt. :(

benutzer der freien version sind aber ohnehin davon verschont, weil die ja bekanntlich noch immer keine vernünftige vollbildausgabe ohne zusätzliche BMD-hardware nutzen dürfen. Interessant.
Vielleicht läuft dir ja auch mal was zum Thema: für nicht-supportete Nvidia GPU (GTX 950) Studiotreiber installieren auf ;)
Würde mich mal interessieren, ob sich 10bit freischalten lassen. Habe dazu leider noch nichts gefunden.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
"mash..."] für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht. Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest. hab ich irgendwo behauptet, dass eine solche kalibrierung der schirme nicht nötig wäre?!

natürlich ist die völlig unerlässlich! -- aber man kann sie eben auf mind. 3 unterschiedliche weisen erreichen:

im professionelleren umfeld sind eher kalibrierung direkt am schirm od. eine zwischengeschaltete LUT-box üblich, so dass man eben einfach nur auf diese übergabestandards abzuzielen muss.

aber selbst dort, wo man entsprechende korrekturen in software am computer zu erledigen versucht -- was ja durchaus auch zu befiedigenden resultaten fürhren kann bzw. oft den entsprechenden fähigkeiten der bildschirme überlegen ist --, kann man entweder eine einzige LUT wählen, die vom internen arbeitsfarbraum direkt auf die darstellungemöglichkeiten am konkreten monitor abzielt, oder eben eine, die nur die korrekturen zw. angezieltem standardfarbraum und konkretem schirm korrigiert.

speziell wenn mehre anzeigedevices gleichzeitig am computer angeschlossen sind, die unterschiedliche anpassungen benötigen, spielt es schon eine wichtige rolle, wie man das am sinnvollsten zu lösen versucht.
[quote="Frank Glencairn" hat geschrieben:
Irgendeine generische Umrechnug, starr auf einen nicht referenzierten Monitor anzuwenden ist das Gegenteil von flexibel. im wörtlichen sinne ist es es natürlich "flexibler", wenn man ganz ohne solche standards und orientierungen auskommt, "praktikabel" ist es dagegen weit weniger.

realistischer weise wird man sich also im regelfall fast immer an derartigen fix vorgegebenen standardfarbräumen orientieren bzw. bestrebt sein, diese ggf. durch zusätzliche korrekturen, die in vielen fällen ausserhalb des programms liegen, auch als solche angezeigt zu bekommen.

in deinem fall -- wo offenbar eh nur rec709 genutzt wird --, ist das natürlich einfacher als an arbeitsplätzen, wo auch andere standards eine rolle spielen oder die computerbildschirme auch für andere arbeiten herhalten müssen,

ich persönlich schätze jedenfalls programme, wo man tatsächlich ganz einfach und ausreichend sauber zw. rec709 und sRGB hin und her schalten kann bzw. ausgegeben bekommt -- nach möglichkeit sogar in einer weise, die dabei ein auseinanderhalten der einstellungen für mehre angeschlossene geräte erlaubt. derartiges empfinde ich tatsächlich als "flexibler" als die weise, wie es im resolve noch immer gehandhabt wird.
"Frank Glencairn" hat geschrieben:
Die einzige Frage ist eher, hab ich die LUT im Monitor (wenn er das überhaupt kann), und wie gut ist da die Umsetzung, sprich wir da aus dem Cube vielleicht nur ne 2D LUT draus, ist die Interpolation da Tetrahedal oder Trilinear etc. oder lass ich das lieber mein CC Programm machen, oder vielleicht sogar ne externe LUT Box? ja -- das problem mit unzureichendem rechenvermögen älterer bildschirme oder erschwinglicheren angeboten, die zwar von den technischen spezifikation her hw-kalibrierung anbieten, sie aber so fragwürdig umsetzten, dass man davon besser keinen gebrauch macht, ist leider hinlänglich bekannt. umgekehrt gibt's natürlich auch computerseitig jede menge lösungsansäte, die völlig indiskutabel sind bzw. im umfeld ernsthafterer anforderungen besser vermieden werden.

darum reden wir hier ja über herangehensweisen, die tatsächlich sinn machen!

und natürlich spielt es dabei auch eine rolle, ob man es mit einem softwarehersteller zu tun hat, der sich gemeinsam mit dem benutzern darum bemüht, hier eine lösung zu finden, und dabei z.b. auch grafikartenhersteller dazu bewegt, die notwendigen voraussetzungen für derartige farbverbindliche ausgaben zugänglich zu machen, oder eben doch, wie im falle von BMD, eigene hardware-verkaufsintressen solchen verbesserungen vielmehr zuwider laufen würden, so dass man es lieber in kauf nimmt, diesen teil des programms völlig zu verkrüppeln.
"Frank Glencairn" hat geschrieben:
Wer Zeit zum lesen hat, dem kann ich das hier empfehlen, ich denke da werden viele Fragen beantwortet:
https://nick-shaw.github.io/cinematicco ... enges.html ich muss zugeben, dass ich ohne weitere angaben nicht klar erkennen kann, was ich diesem link nun genau entnehmen soll? -- vielleicht kannst mir da noch einen hinweis geben? -- ich schätze aber natürlich den konkreten autor und seine fachkenntnis auch ungemein!



Antwort von pillepalle:

klusterdegenerierung hat geschrieben:
In diesem Zusammenhang stelle ich mal eine banal klingende aber ernst zunehmende Frage, dessen Inhalt und Kosequenz diese ganze Diskussion eigentlich schon obsolet macht, solange man nicht wie ein Profi Farben via Pipette und RGB Parade interpretiert.

Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau? Das kommt ganz darauf an, ob sie auf die gleichen Farbräume kalibriert wurden. oder nicht. Wenn Du alle drei mit gleichem Gamma, Weißpunkt und gleicher Helligkeit kalibriert hast, dann schon. Ansonsten eben nicht.

VG



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau? ja! -- sollten sie

auch wenn das bspw. im zusammenhang mit unterschiedlichen techniken der hintergrundbeleuchtung alles andere als eine triviale anforderung ist.

in der praxis erlebe ich allerdings, dass man beim ausmessen der geräte ständig entdeckt, dass die herstellerseitig mitgelieferten profile immer alle viel zu hell sind, weil das offenbar in normalen büro- od. auch grafikarbeitsalltag eher gewünscht sein dürfte. wenn man das einmal korrigiert hat, was ja wirklich sehr leicht zu bewerkstelligen ist, ist man schon deutlich näher an den angestrebten film- u. video-typischen orientierungsstandards dran.



Antwort von rdcl:

klusterdegenerierung hat geschrieben:
In diesem Zusammenhang stelle ich mal eine banal klingende aber ernst zunehmende Frage, dessen Inhalt und Kosequenz diese ganze Diskussion eigentlich schon obsolet macht, solange man nicht wie ein Profi Farben via Pipette und RGB Parade interpretiert.

Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau? Mit einer Kalibrierung eher nicht. Mit einer Kalibrierung & Profilierung schon eher. Hängt aber davon ab, ob sich die korrekte Profilierung, je nach Software, auf alle Monitore korrekt anwenden lässt. Darum dreht sich die ganze Diskussion doch.



Antwort von pillepalle:

Man kann auch unterschiedlich erstellte Profile verschiedenen Monitoren zuweisen. Das Profil dient dazu eigene Settings zu speichern und nicht die vom Betriebssystem. Das weist man dem Monitor in der Regel selber zu. Die Kalibrierung ist bei Hardwarekalibrierbaren Monitoren dann im Monitor selber gespeichert. Bei einer Software-Kalibrierung wird die Kalibrierung im Profil gespeichert und die Grafikkarte muss die Werte quasi dahin verbiegen. Deshalb ist das Ergebnis einer Software Kalibrierung meist auch nicht so gut.

VG



Antwort von rdcl:

pillepalle hat geschrieben:
Man kann auch unterschiedlich erstellte Profile verschiedenen Monitoren zuweisen. Das Profil dient dazu eigene Settings zu speichern und nicht die vom Betriebssystem. Das weist man dem Monitor in der Regel selber zu. Die Kalibrierung ist bei Hardwarekalibrierbaren Monitoren dann im Monitor selber gespeichert. Bei einer Software-Kalibrierung wird die Kalibrierung im Profil gespeichert und die Grafikkarte muss die Werte quasi dahin verbiegen. Deshalb ist das Ergebnis einer Software Kalibrierung meist auch nicht so gut.

VG Aber ein spezifisches Profil für den Monitor per Software ist um längen besser als ein generisches Farbraum-Profil.
Ich hatte bei meinem Monitor bei allen Werten ein Delta < 1. Müsste also zum größten Teil passen könnte man meinen. Aber gerade die kritische Rot- und Cyanwerte sind mit dem Profilierungs-Lut in Resolve nochmal unterschiedlich. Nicht extrem, aber gerade bei Hauttönen eben schon wichtig. Würde ich ohne die Profilierung für den Monitor graden, würden alle Hauttöne anders rauskommen als ich es eigentlich möchte, weil ich keine akkurate Vorschau hätte. Eine Kalibrierung ohne Profilierung reicht da einfach nicht, und ein Farbraumprofil ohne spezifische Korrekturen für den verwendeten Monitor auch nicht.



Antwort von dienstag_01:

rdcl hat geschrieben:
pillepalle hat geschrieben:
Man kann auch unterschiedlich erstellte Profile verschiedenen Monitoren zuweisen. Das Profil dient dazu eigene Settings zu speichern und nicht die vom Betriebssystem. Das weist man dem Monitor in der Regel selber zu. Die Kalibrierung ist bei Hardwarekalibrierbaren Monitoren dann im Monitor selber gespeichert. Bei einer Software-Kalibrierung wird die Kalibrierung im Profil gespeichert und die Grafikkarte muss die Werte quasi dahin verbiegen. Deshalb ist das Ergebnis einer Software Kalibrierung meist auch nicht so gut.

VG Aber ein spezifisches Profil für den Monitor per Software ist um längen besser als ein generisches Farbraum-Profil.
Ich hatte bei meinem Monitor bei allen Werten ein Delta < 1. Müsste also zum größten Teil passen könnte man meinen. Aber gerade die kritische Rot- und Cyanwerte sind mit dem Profilierungs-Lut in Resolve nochmal unterschiedlich. Nicht extrem, aber gerade bei Hauttönen eben schon wichtig. Würde ich ohne die Profilierung für den Monitor graden, würden alle Hauttöne anders rauskommen als ich es eigentlich möchte, weil ich keine akkurate Vorschau hätte. Eine Kalibrierung ohne Profilierung reicht da einfach nicht, und ein Farbraumprofil ohne spezifische Korrekturen für den verwendeten Monitor auch nicht. Was meinst du mit generischem Farbraumprofil?



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Aber ein spezifisches Profil für den Monitor per Software ist um längen besser als ein generisches Farbraum-Profil.
Ich hatte bei meinem Monitor bei allen Werten ein Delta < 1. Müsste also zum größten Teil passen könnte man meinen. Aber gerade die kritische Rot- und Cyanwerte sind mit dem Profilierungs-Lut in Resolve nochmal unterschiedlich. Nicht extrem, aber gerade bei Hauttönen eben schon wichtig. Würde ich ohne die Profilierung für den Monitor graden, würden alle Hauttöne anders rauskommen als ich es eigentlich möchte, weil ich keine akkurate Vorschau hätte. Eine Kalibrierung ohne Profilierung reicht da einfach nicht, und ein Farbraumprofil ohne spezifische Korrekturen für den verwendeten Monitor auch nicht. Was meinst du mit generischem Farbraumprofil? Wenn ich statt dem LUT für den Monitor, dass durch die Profilierung erstellt wurde, einfach nur ein "Standard-Rec709" oder einen anderen Farbraum als Output Color Space angeben würde. Dann würde die Korrektur für den Monitor fehlen.



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

Was meinst du mit generischem Farbraumprofil? Wenn ich statt dem LUT für den Monitor, dass durch die Profilierung erstellt wurde, einfach nur ein "Standard-Rec709" oder einen anderen Farbraum als Output Color Space angeben würde. Dann würde die Korrektur für den Monitor fehlen. Bei einem Monitor, der exakt den Standard trifft, dürfte das nicht so sein.
In der Praxis wohl schon.

Edit: das dürfte schon damit losgehen, dass die Monitore einen größeren Farbraum abdecken, als die normalen Standards (sRGB, 709) vorsehen.



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Wenn ich statt dem LUT für den Monitor, dass durch die Profilierung erstellt wurde, einfach nur ein "Standard-Rec709" oder einen anderen Farbraum als Output Color Space angeben würde. Dann würde die Korrektur für den Monitor fehlen. Bei einem Monitor, der exakt den Standard trifft, dürfte das nicht so sein.
In der Praxis wohl schon.

Edit: das dürfte schon damit losgehen, dass die Monitore einen größeren Farbraum abdecken, als die normalen Standards (sRGB, 709) vorsehen. Meines Wissens nach gibt es keinen Monitor der 0% Abweichung über das gesamte Spektrum hat. Zumindest nicht in dem Umfeld in dem wir über Software-Luts etc sprechen müssen. Zusätzlich verändern sich Monitorwerte ja auch über die Zeit.



Antwort von mash_gh4:

viele der verbreiteten vorurteile gegenüber korrekturen auf seiten des computers -- ich nenn's bewusst lieber nicht sw-kalibrierung -- haben damit zu tun, dass dafür früher einmal sehr einfache methoden herangezogen wurden, einfach nur die intensität der einzelnen farbkanäle mit 1D-LUTs direkt auf der grafikkarte umzumappen, was natürlich in der praxis völlig unzureichend ist.

das ist aber auch etwas ganze anders als es hier zur debatte steht!

was aber tatsächlich ein wenig gegen eine derartige umsetzung spricht, ist das chaos im hinblick auf die saubere verwaltung bzw. die nicht verbindlichen signale auf den übergabekanälen -- sprich: kabeln. in der hinsicht ist natürlich hw-kalibrierung auf seiten der monitore od. per LUT-box vorteilhafter.

trotzdem -- in puncto qualität ist eine solche farbanpasssung am rechner den korrekturfähigkeiten in den monitoren in den meisten fällen überlegen, wenn es sauber umgesetzt wird. wer das für unrealistisch hält, muss konsequenter weise generell bezweifeln, dass man mit software überhaupt farben zielsicher verbiegen kann.

ehrlich gestanden zweifle allerdings auch ich daran, dass man mit erschwinglichen kolorimetern, wie den verbreiteten i1Display Pro, tatsächlich so perfekte messwerte hinbekommen könnte, wie sie rdcl hier beschreibt. ich hab dazu zwar immer wieder herumgesucht, aber kaum wirklich glaubwürdige angaben bzgl. der zu erwartenden messtoleranzen bzw. tatsächlich erreichbaren genauigkeit gefunden.

für meinen teil versuch ich deshalb in diesen dingen eher ein bisserl auf der vorsichtigen seite zu bleiben und es mehr als ein bemühen um eine realistische "annäherung" zu begreifen, statt tatsächlich daran zu glauben, dass man derartiges im rahmen der gewöhnlich zur verfügung stehenden haushaltsmesshilfsmittel und anzeigegeräte tatsächlich ausreichend perfekt hinbekommen könnte.



Antwort von rdcl:

mash_gh4 hat geschrieben:
viele der verbreiteten vorurteile gegenüber korrekturen auf seiten des computers -- ich nenn's bewusst lieber nicht sw-kalibrierung -- haben damit zu tun, dass dafür früher einmal sehr einfache methoden herangezogen wurden, einfach nur die intensität der einzelnen farbkanäle mit 1D-LUTs direkt auf der grafikkarte umzumappen, was natürlich in der praxis völlig unzureichend ist.

das ist aber auch etwas ganze anders als es hier zur debatte steht!

was aber tatsächlich ein wenig gegen eine derartige umsetzung spricht, ist das chaos im hinblick auf die saubere verwaltung bzw. die nicht verbindlichen signale auf den übergabekanälen -- sprich: kabeln.

trotzdem -- in puncto qualität ist es den entsprechenden korrekturfähigkeiten in den monitoren in den meisten fällen überlegen, wenn es sauber umgesetzt wird. wenn das für unrealistisch hält, sollte man wohl auch generell bezweifeln, dass man mit software überhaupt farben zielsicher verbiegen kann.

ehrlich gestanden zweifle allerdings auch ich daran, dass man mit erschwinglichen kolorimetern, wie den verbreiteten i1Display Pro, tatsächlich so perfekte messwerte hinbekommen könnte, wie sie rdcl hier beschreibt. ich hab dazu zwar immer wieder herumgesucht, aber kaum wirklich glaubwürdige angaben bzgl. der zu erwartenden messtoleranzen bzw. tatsächlich erreichbaren genauigkeit gefunden.

für meinen teil versuch ich deshalb in diesen dingen eher ein bisserl auf der vorsichtigen seite zu bleiben und es mehr als ein bemühen um eine realistische "annäherung" zu begreifen, statt tatsächlich daran zu glauben, dass man derartiges im rahmen der gewöhnlich zur verfügung stehenden haushaltsmesshilfsmitteln und anzeigegeräten tatsächlich ausreichend perfekt hinbekommen könnte. Wenn das Budget nicht unbegrenzt ist, muss es natürlich irgendwo ein "close enough" geben. Aber für Grading ist das eben nicht nach der Kalibrierung, sondern frühestens nach der Profilierung. Damit kommt man auch nicht an 100% Genauigkeit, aber zumindest hat man ein Profil sienes Monitors, wahlweise auch mit Umgebungslichtkorrektur, so dass die gröbsten Abweichungen im Monitor korrigiert werden können.



Antwort von mash_gh4:

rdcl hat geschrieben:
Wenn das Budget nicht unbegrenzt ist, muss es natürlich irgendwo ein "close enough" geben. Aber für Grading ist das eben nicht nach der Kalibrierung, sondern frühestens nach der Profilierung. Damit kommt man auch nicht an 100% Genauigkeit, aber zumindest hat man ein Profil sienes Monitors, wahlweise auch mit Umgebungslichtkorrektur, so dass die gröbsten Abweichungen im Monitor korrigiert werden können. ja -- im wesentlichen teile ich diese einschätzung.



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

Bei einem Monitor, der exakt den Standard trifft, dürfte das nicht so sein.
In der Praxis wohl schon.

Edit: das dürfte schon damit losgehen, dass die Monitore einen größeren Farbraum abdecken, als die normalen Standards (sRGB, 709) vorsehen. Meines Wissens nach gibt es keinen Monitor der 0% Abweichung über das gesamte Spektrum hat. Zumindest nicht in dem Umfeld in dem wir über Software-Luts etc sprechen müssen. Zusätzlich verändern sich Monitorwerte ja auch über die Zeit. Wenn man einen hardwarekalibrierbaren Monitor hat, ist man prinzipiell schon sehr nah dran. Und diese Kalibrierung wird auch regelmäßig aufgefrischt.



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Wenn man einen hardwarekalibrierbaren Monitor hat, ist man prinzipiell schon sehr nah dran. Und diese Kalibrierung wird auch regelmäßig aufgefrischt. im high-end breich ist es durchaus nicht unüblich, die entsprechenden korrekturen tatsächlich dem service der monitorhersteller vorzubehalten, weil ein hw-kalibrieren mit gebräuchlichem messinstrumentarium auf seiten des anwenders offenbar unbefriedigender ausfallen würde.

aber natürlich sind das sorgen, die sich im zusammenhang mit jenem einigermaßen erschwinglichen equipment, mit dem sich die meisten von uns hier begnügen müssen, gar nicht erst stellen. ;)



Antwort von klusterdegenerierung:

pillepalle hat geschrieben:
klusterdegenerierung hat geschrieben:
In diesem Zusammenhang stelle ich mal eine banal klingende aber ernst zunehmende Frage, dessen Inhalt und Kosequenz diese ganze Diskussion eigentlich schon obsolet macht, solange man nicht wie ein Profi Farben via Pipette und RGB Parade interpretiert.

Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau? Das kommt ganz darauf an, ob sie auf die gleichen Farbräume kalibriert wurden. oder nicht. Wenn Du alle drei mit gleichem Gamma, Weißpunkt und gleicher Helligkeit kalibriert hast, dann schon. Ansonsten eben nicht.

VG Nein Definitiv!
Da alle einen anderen Panel benutzen!

Ich hatte schon vor Jahren in meinem damaligen Studio ein Expertenteam vor Ort, die meine unterschiedlichen Monitore professionell einmessen sollten, weil wir eine Kooperative mit einer Druckerei hatte und die Druckergebnisse 100% mit dem Produkt übereinstimmen mußten.

Diese Team hat es auch nach Stunden nicht hinbekommen, obwohl alle Messungen korrekt waren.
Von hoch Erfahrenen Experten habe ich dann erfahren das die niemals wird funktionieren, denn es spielen die verbaute Technik, die Panal Art, das Alter, die Laufzeit, die Qualität, der Anschluß, die Oberfläche ob verspiegelt etc. alles eine Rolle und obwohl die Messungen alle exakt den gleichen Wert aufweisen, werden immer Farbabweichungen zu sehen sein.

Und wenn man selbst schon trotz Messung, nicht auf die exakt gleiche Farbei und Intensität kommt, dann ist es bei anderen nicht besser und da kommen wir wieder zu Frank, wenn man sich redlich Mühe gegeben hat und alles sieht realistisch und ordentlich aus, dann ait ab da gut, weiter geht es nicht, es sei denn man befindet sich in einem geschlossenem System mit glaichen Monitoren, Tageslicht Leuchten, gelichen Profilen, gleichen Betriebsystem usw usw und dann ist es richtig teuer!



Antwort von pillepalle:

@ kluster

Das hängt eben auch von der Qualität der Monitore ab. Natürlich wird nicht jedes Display absolut identisch aussehen. Das iMac Display sieht auch nicht aus wie der NEC. Aber der NEC sieht genauso aus wie der EIZO. Genau dafür gibt man eben mehr Geld aus.

Und wie meine Vorredner schon sagten. Auch das Messgerät und Messverfahren spielt eine Rolle. Das ein 300,-€ Colorimeter nicht so genau misst wie ein professionelleres Gerät für mehrere Tausend dürfte auch einleuchten. Die Unterschiede sind aber in der Regel sehr gering.

VG



Antwort von dienstag_01:

Vermutlich ist es bei hardwarekalibrierten Monitoren so: der Monitor wird kalibriert, profiliert und das verwendete Profil im Betriebssystem hinterlegt. Videosoftware, hier Resolve, greift auf diese Profile nicht zu. Deshalb wird extern eine LUT erstellt, für diesen speziellen Farbraum und in der Videosoftware hinterlegt (als Profilersatz).
Dieser Workflow ist an eine Decklink etc. gebunden, da Preview Luts keine Auswirkung auf den Clean Video Feed haben (ein Workaround wurde von mash_gh4 hier allerdings verlinkt).
Oder man nutzt nur den Viewer, da scheint es mit der LUT zu funktionieren (halte ich aber sowieso für unpraktikabel).



Antwort von Frank Glencairn:

klusterdegenerierung hat geschrieben:

Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau? Hab ich noch nie erlebt, daß das 100%ig klappt - nicht mal bei 3 gleichen Monitoren, leichte Unterschiede sind da immer - jedenfalls mit den bei uns hier üblichen budget Messsonden im (Spider/Color Munki etc). Womöglich bringen Sonden die mehr als das Doppelte des Monitors kosten ein genaueres Ergebnis - keine Ahnung.



Antwort von pillepalle:

@ Frank

Bei guten Monitoren sind das wirklich nur Nuancen in denen sie sich unterschieden. Hier ist mal ein Vergleich mit den Asus Pro Art und dem Eizo Vorgängermodell. Und ein Kamerabild ist bei einem Vergleich zweier Monitorbilder nebeneinander super empfindlich, da sieht man wirklich minimalste Unterschiede.



VG



Antwort von cantsin:

pillepalle hat geschrieben:
Bei guten Monitoren sind das wirklich nur Nuancen in denen sie sich unterschieden. Hier ist mal ein Vergleich mit den Asus Pro Art und dem Eizo Vorgängermodell. Und ein Kamerabild ist bei einem Vergleich zweier Monitorbilder nebeneinander super empfindlich, da sieht man wirklich minimalste Unterschiede.

Für mich hat der linke Monitor einen deutlichen Grün- und der rechte einen deutlichen Magentastich...

Die Frage ist wohl hier in der ganzen Diskussion, über welche Nuancen und Toleranzen (bzw. welche persönliche Akzeptanz von Nuancen und Toleranzen) wir genau diskutieren.



Antwort von pillepalle:

@ catsin

Ja, weil die Kamera das viel genauer sieht, als Dein Auge. Vor Ort würdest Du den Unterschied kaum wahrnehmen, weil Dein Auge viel kompensiert. Er geht darauf im Review auch ein. Wenn Du einen Monitor mit noch mehr Magenta neben den Asus stellen würdest, kame der Erste Dir grünlich vor :)

VG



Antwort von dienstag_01:

pillepalle hat geschrieben:
@ catsin

Ja, weil die Kamera das viel genauer sieht, als Dein Auge. Vor Ort würdest Du den Unterschied kaum wahrnehmen, weil Dein Auge viel kompensiert. Er geht darauf im Review auch ein. Wenn Du einen Monitor mit noch mehr Magenta neben den Asus stellen würdest, kame der Erste Dir grünlich vor :)

VG Dein Auge kompensiert da gar nichts, den Unterschied sieht man vor Ort genau so.



Antwort von pillepalle:

Man sieht ihn weniger. Du kannst das leicht überprüfen, wenn Du mal auf eine weiße/graue Wand schaust. Einen Grün/Magenta Stich (Farbkipper) wirst Du dort nicht wahrnehmen. In der Kamera sieht man den sofort.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
Man sieht ihn weniger. Du kannst das leicht überprüfen, wenn Du mal auf eine weiße/graue Wand schaust. Einen Grün/Magenta stich wirst Du dort nicht wahrnehmen. In der Kamera sieht man den sofort. Dein Auge kompensiert für eine Lichtsituation bzw. einen Farbstich. Wenn Du aber eine graue Wand hast, bei der ein Teil mit einer minimal anderen Farbschattierung gestrichen wurde, siehst Du den Unterschied sofort. Genauso, wie eben auch bei zwei nebeneinander stehenden Monitoren, die die gleiche Farbe mit verschiedenen Farbstichen anzeigen.



Antwort von rdcl:

dienstag_01 hat geschrieben:
Vermutlich ist es bei hardwarekalibrierten Monitoren so: der Monitor wird kalibriert, profiliert und das verwendete Profil im Betriebssystem hinterlegt. Videosoftware, hier Resolve, greift auf diese Profile nicht zu. Deshalb wird extern eine LUT erstellt, für diesen speziellen Farbraum und in der Videosoftware hinterlegt (als Profilersatz).
Dieser Workflow ist an eine Decklink etc. gebunden, da Preview Luts keine Auswirkung auf den Clean Video Feed haben (ein Workaround wurde von mash_gh4 hier allerdings verlinkt).
Oder man nutzt nur den Viewer, da scheint es mit der LUT zu funktionieren (halte ich aber sowieso für unpraktikabel). Nein, hardwarekalibrierbare Monitore, z.B. die teureren Eizos, speichern die Profilierung als LUT direkt im Monitor.
Kann man auf der Produktseite auch nachlesen: https://www.eizo.de/coloredge/cg319x/

Sinn davon ist, dass ich den Monitor an einen anderen Rechner anstecken kann und die Profilierung trotzdem noch stimmt, solange sich keine anderen Rahmenbedingungen ändern. Bei den Eizos lassen sich auch selbst erstellte LUTs aus DisplayCal hochladen, was bei den meisten LGS oder Asus etc. nicht der Fall ist. Die unterstützen zwar die LUTs, lassen aber keinen Upgrade zu. Da kann man oft nur über die hauseigene Software profilieren.
Deswegen habe ich bei Slashcam auch mal angemerkt, dass dieses Info, also ob sich selbst erstellte LUTs direkt im Monitor speichern lassen, für viele essentiell wichtig wäre bei den Monitortests. Leider habe ich aber noch keinen Slashcam-Monitortest gesehen, bei dem darauf eingegangen wurde.

Der Vorteil ist klar: Ich habe bei sämtlichen Programmen, vollkommen unabhängig vom OS, Grafikkarte oder Decklink, LUT-Unterstützung in der Software oder nicht, immer eine korrekt profilierte Ausgabe.

Es wäre wirklich toll wenn Slashcam dieses Feature in den Tests berücksichtigen könnte.



Antwort von rdcl:

pillepalle hat geschrieben:
@ Frank

Bei guten Monitoren sind das wirklich nur Nuancen in denen sie sich unterschieden. Hier ist mal ein Vergleich mit den Asus Pro Art und dem Eizo Vorgängermodell. Und ein Kamerabild ist bei einem Vergleich zweier Monitorbilder nebeneinander super empfindlich, da sieht man wirklich minimalste Unterschiede.



VG Das sind aber wirklich keine Nuancen, die Unterschiede sind klar sichtbar.



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:
Vermutlich ist es bei hardwarekalibrierten Monitoren so: der Monitor wird kalibriert, profiliert und das verwendete Profil im Betriebssystem hinterlegt. Videosoftware, hier Resolve, greift auf diese Profile nicht zu. Deshalb wird extern eine LUT erstellt, für diesen speziellen Farbraum und in der Videosoftware hinterlegt (als Profilersatz).
Dieser Workflow ist an eine Decklink etc. gebunden, da Preview Luts keine Auswirkung auf den Clean Video Feed haben (ein Workaround wurde von mash_gh4 hier allerdings verlinkt).
Oder man nutzt nur den Viewer, da scheint es mit der LUT zu funktionieren (halte ich aber sowieso für unpraktikabel). Nein, hardwarekalibrierbare Monitore, z.B. die teureren Eizos, speichern die Profilierung als LUT direkt im Monitor.
Kann man auf der Produktseite auch nachlesen: https://www.eizo.de/coloredge/cg319x/

Sinn davon ist, dass ich den Monitor an einen anderen Rechner anstecken kann und die Profilierung trotzdem noch stimmt, solange sich keine anderen Rahmenbedingungen ändern. Bei den Exzision lassen sich auch selbst erstellte LUTs aus DisplayCal hochladen, was.vei den meisten LGS oder Asus etc. nicht der Fall ist. Da kann man oft nur über die hauseigene Software profilieren.
Deswegen habe ich bei Slashcam auch mal angemerkt, dass dieses Info, also ob sich selbst erdtwllzenÖUTs direkt im Monitor speichern lassen, für viele essentiell wichtig wäre bei den Monitortests. Leider habe ich aber noch keinen Slashcam-Monitortest gesehen, bei dem darauf eingegangen wurde.

Der Vorteil ist klar: Ich habe bei sämtlichen Programmen, vollkommen unabhängig vom OS, Grafikkarte oder Decklink, LUT-Unterstützung in der Software oder nicht, immer eine korrekt profilierte Ausgabe.

Es wäre wirklich toll wenn Slashcam dieses Feature in den Tests berücksichtigen könnte. Nee, das hast du falsch verstanden. Profile werden auch beim Eizo im Betriebssystem hinterlegt, nur die Kalibrierungsdaten werden im Monitor gespeichert.



Antwort von pillepalle:

Ich habe die Erfahrung gemacht, das die Unterschiede in der Kamera größer wirken als in sie einem vorkommen. Sie werden jedenfalls nicht größer sein Vor Ort und man nimmt die Farbe auch immer relativ um Umfeld wahr. Wenn Du einen grüneren Monitor neben den Eizo stellt, erscheint Dir der plötzlich neutral.

VG



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Nein, hardwarekalibrierbare Monitore, z.B. die teureren Eizos, speichern die Profilierung als LUT direkt im Monitor.
Kann man auf der Produktseite auch nachlesen: https://www.eizo.de/coloredge/cg319x/

Sinn davon ist, dass ich den Monitor an einen anderen Rechner anstecken kann und die Profilierung trotzdem noch stimmt, solange sich keine anderen Rahmenbedingungen ändern. Bei den Exzision lassen sich auch selbst erstellte LUTs aus DisplayCal hochladen, was.vei den meisten LGS oder Asus etc. nicht der Fall ist. Da kann man oft nur über die hauseigene Software profilieren.
Deswegen habe ich bei Slashcam auch mal angemerkt, dass dieses Info, also ob sich selbst erdtwllzenÖUTs direkt im Monitor speichern lassen, für viele essentiell wichtig wäre bei den Monitortests. Leider habe ich aber noch keinen Slashcam-Monitortest gesehen, bei dem darauf eingegangen wurde.

Der Vorteil ist klar: Ich habe bei sämtlichen Programmen, vollkommen unabhängig vom OS, Grafikkarte oder Decklink, LUT-Unterstützung in der Software oder nicht, immer eine korrekt profilierte Ausgabe.

Es wäre wirklich toll wenn Slashcam dieses Feature in den Tests berücksichtigen könnte. Nee, das hast du falsch verstanden. Profile werden auch beim Eizo im Betriebssystem hinterlegt, nur die Kalibrierungsdaten werden im Monitor gespeichert. Nein. Woher nimmst du die Info? Über die Eizo-Software lassen sich wie gesagt auch eigene Profilierungs-LUTs hochladen.
Bei den Eizos kann DisplayCal sogar direkt im Monitor speichern, ohne dass man selbst hochladen muss.
Wofür soll der interne LUT-Support denn sonst da sein? Kalibruert wird nicht über LUTs sondern Settings.



Antwort von dienstag_01:

pillepalle hat geschrieben:
Ich habe die Erfahrung gemacht, das die Unterschiede in der Kamera größer wirken als in sie einem vorkommen. Sie werden jedenfalls nicht größer sein Vor Ort und man nimmt die Farbe auch immer relativ um Umfeld wahr. Wenn Du einen grüneren Monitor neben den Eizo stellt, erscheint Dir der plötzlich neutral.

VG Wenn zwei Monitore nebeneinander stehen, sieht man immer eine Differenz. Welchen man davon dann als Neutral definiert (wenn man es nicht vorher gemessen hat), ist eine andere Sache.



Antwort von pillepalle:

Jedenfalls liegt die Toleranz über die wir hier reden in dieser Größenordnung und die werden im wesentlichen durch die Toleranzen der Monitore und Kalibrierungsgenauigkeit des Colorimeters bestimmt.

VG



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

Nee, das hast du falsch verstanden. Profile werden auch beim Eizo im Betriebssystem hinterlegt, nur die Kalibrierungsdaten werden im Monitor gespeichert. Nein. Woher nimmst du die Info? Über die Eizo-Software lassen sich wie gesagt auch eigene Profilierungs-LUTs hochladen.
Bei den Eizos kann DisplayCal sogar direkt im Monitor speichern, ohne dass man selbst hochladen muss.
Wofür soll der interne LUT-Support denn sonst da sein? Kalibruert wird nicht über LUTs sondern Settings. Die Info hab ich von mir und dem Eizo, der hier steht. Und ich rede von Profilen.

Du scheinst jetzt selbst den Fehler zu machen, dass du Kalibrierung und Profilierung durcheinander schmeisst.



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Nein. Woher nimmst du die Info? Über die Eizo-Software lassen sich wie gesagt auch eigene Profilierungs-LUTs hochladen.
Bei den Eizos kann DisplayCal sogar direkt im Monitor speichern, ohne dass man selbst hochladen muss.
Wofür soll der interne LUT-Support denn sonst da sein? Kalibriert wird nicht über LUTs sondern Settings. Die Info hab ich von mir und dem Eizo der hier steht. Und ich rede von Profilen.

Du scheinst jetzt selbst den Fehler zu machen, dass du Kalibrierung und Profilierung durcheinander schmeisst. Welcher Eizo ist das denn? Nicht alle supporten interne LUTs. Hast du meinen Link zum Eizo gesehen? Da ist ein ganzer Absatz der das LUT-Feature bewirbt. Die werden 100% intern gespeichert. Und die sind auch für die Profilierung, nicht für die Kalibrierung an sich. Was meinst du habe ich da verwechselt?

Wenn ich von Kalibrierung, wie z.B. in Display Cal rede, dann meine ich das Anpassen von Helligkeit, Kontrast und Farbkanälen, bis der gewünschte Punkt für den jeweiligen Farbraum erreicht ist. Dann kommt die Profilierung, wo 3000 verschiedenfarbige und unterschiedlich helle Vierecke durchgemessen werden und am Ende ein LUT spezifisch für den Monitor herauskommt. Und bei den Eizos, zumindest CG, werden die im Monitor gespeichert.



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

Die Info hab ich von mir und dem Eizo der hier steht. Und ich rede von Profilen.

Du scheinst jetzt selbst den Fehler zu machen, dass du Kalibrierung und Profilierung durcheinander schmeisst. Welcher Eizo ist das denn? Nicht alle supporten interne LUTs. Hast du meinen Link zum Eizo gesehen? Da ist ein ganzer Absatz der das LUT-Feature bewirbt. Die werden 100% intern gespeichert. Und die sind auch für die Profilierung, nicht für die Kalibrierung an sich. Was meinst du habe ich da verwechselt? Nee, den hab ich nicht. Du?



Antwort von pillepalle:

In dem Zusammenhang übrigens ganz lustig... ich hatte vor Jahren mal auf einem Messestand von Eizo zwei gerahmte Bilder hängen sehen, die absolut identisch aussahen. Erst beim näheren heranschreiten merkte man, das es sich einmal um einen gerahmten Monitor handelte. Das war schon ziemlich beeindruckend :)

VG



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Du scheinst jetzt selbst den Fehler zu machen, dass du Kalibrierung und Profilierung durcheinander schmeisst. ja -- ich fürchte auch, dass das hier vermischt wird...

ist aber nicht weiter tragisch. weil die grenzen hier meines erachtens ohnehine immer mehr verfließen bzw. derart viele varianten der praktischen umsetzung existieren, dass in der beschreibung besser andere "charakteristiken" ;) hervorhebt.

was sie die hardware-zugriffsmöglichkeiten betrifft, finde ich übrigens die professionellen NECs noch besser als die Eizos, Das sind nämlich die einzigen mir bekannten monitore, die wirklich von anfang an auch unter linux sauber unterstützt wurden. im prinzip nutzen aber ohnehin fast alle hersteller DDC um mit den geräten zu kommunzieren bzw. entsprechende einstellungen dort zu hinterlegen, aber die details bzw. dabei genutzten herstellerspezifischen erweiterungen sind leider nur in den allerseltensten fällen offen dokumentiert.



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Welcher Eizo ist das denn? Nicht alle supporten interne LUTs. Hast du meinen Link zum Eizo gesehen? Da ist ein ganzer Absatz der das LUT-Feature bewirbt. Die werden 100% intern gespeichert. Und die sind auch für die Profilierung, nicht für die Kalibrierung an sich. Was meinst du habe ich da verwechselt? Nee, den hab ich nicht. Du? https://www.eizo.de/coloredge/cg319x/
Einfach mal nach unten scrollen.



Antwort von rdcl:

mash_gh4 hat geschrieben:
dienstag_01 hat geschrieben:
Du scheinst jetzt selbst den Fehler zu machen, dass du Kalibrierung und Profilierung durcheinander schmeisst. ja -- ich fürchte auch, dass das hier vermischt wird... Da wird nichts vermischt. Ich habe bei meinem Post nochmal ergänzt was ich unter Kalibrierung und Profilierung verstehe. Vielleicht erklärt ihr mal, was ihr darunter versteht, oder wo hier was genau vermischt
wurde?



Antwort von pillepalle:

@ mash_gh4

Ja, die NECs sind super. Benutze ich auch. Wollte aber mal einen anderen Hersteller ausprobieren und fand die Features beim Eizo ganz cool.

VG



Antwort von mash_gh4:

rdcl hat geschrieben:
Wenn ich von Kalibrierung, wie z.B. in Display Cal rede, dann meine ich das Anpassen von Helligkeit, Kontrast und Farbkanälen, bis der gewünschte Punkt für den jeweiligen Farbraum erreicht ist. Dann kommt die Profilierung, wo 3000 verschiedenfarbige und unterschiedlich helle Vierecke durchgemessen werden und am Ende ein LUT spezifisch für den Monitor herauskommt. Und bei den Eizos, zumindest CG, werden die im Monitor gespeichert. ja -- es gibt viele die sich an dieser begriffsdefinition orientieren.
sie scheint mir im zusammenhang mit alten CRT-schrimen und einer starken betonung der analogtechnik entstanden zu sein.

ich würde jedenfalls diese "profile" direkt auf den monitoren immer als "hw-kalibrierung" ansprechen.

im engeren sinne kann man aber profilierung auch als ein erfassen jene angaben verstehen, die notwendig sind, um saubere übersetzungen zwischen verschiedenen farbräumen für das betreffende gerät vornehmen zu können. das wird mit deiner verwendungsweise nicht wirklich befriedigend abgedeckt.

https://argyllcms.com/doc/calvschar.html
https://ninedegreesbelow.com/photograph ... nfuse.html

einig sind wir uns aber wohl alle, dass kalibrierung etwas einfacheres darunterliegendes ist, und profilierung/charakterisierung einen zweiter darauf aufbauenden schritt darstellt.



Antwort von dienstag_01:

rdcl hat geschrieben:
mash_gh4 hat geschrieben:


ja -- ich fürchte auch, dass das hier vermischt wird... Da wird nichts vermischt. Ich habe bei meinem Post nochmal ergänzt was ich unter Kalibrierung und Profilierung verstehe. Vielleicht erklärt ihr mal, was ihr darunter versteht, oder wo hier was genau vermischt
wurde? https://www.eizoglobal.com/library/mana ... libration/



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Da wird nichts vermischt. Ich habe bei meinem Post nochmal ergänzt was ich unter Kalibrierung und Profilierung verstehe. Vielleicht erklärt ihr mal, was ihr darunter versteht, oder wo hier was genau vermischt
wurde? https://www.eizoglobal.com/library/mana ... libration/ Was soll uns der Link sagen?

Hier ist übrigens die Kalibrierung und Profilierung eines Lut-fähigen Eizos über Lightspace inklusive Lut-Upload beschrieben:
https://www.lightspace.lightillusion.co ... anual.html



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

https://www.eizoglobal.com/library/mana ... libration/ Was soll uns der Link sagen?

Hier ist übrigens die Kalibrierung und Profilierung eines Lut-fähigen Eizos über Lightspace inklusive Lut-Upload beschrieben:
https://www.lightspace.lightillusion.co ... anual.html Das mit den LUTs hat nicht jeder Eizo. Punkt 1. Und man muss bei jedem Umschalten des Farbraums die passende LUT hochladen. Kann man machen, wenn man will.
Ich hatte aber von Hardwarekalibrierung geschrieben, da muss ich nicht zwingend mit einer externen Software LUTs generieren.



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Ich hatte aber von Hardwarekalibrierung geschrieben, da muss ich nicht zwingend mit einer externen Software LUTs generieren. doch! -- es wird nur die verwendung dieser komplexeren konfigurationsangaben direkt am monitor unabhängig von jeder software am rechner ausgeführt -- ganz ähnlich, wie wenn eine LUT-box davor hängen würde.

und natürlich gibt's auch die variante mit den im monitor mit eingebauten messsonden und die original eizo software, was aber alles in puncto qualität nur noch unbefriedigendere nachteile mit sich bringt.

der wesentliche punkt, wo ich mit rdcl anderer meinung bin, ist die frage ob man auch im fall der verwendung derartiger 3D-LUTs innerhalb des monitors von hardware-KALIBRIERUNG sprechen darf, oder ob diese sprechweise nur für die alten (völlig unbrauchbaren!) 1D-LUTs zulässig ist? ;)



Antwort von dienstag_01:

mash_gh4 hat geschrieben:
dienstag_01 hat geschrieben:
Ich hatte aber von Hardwarekalibrierung geschrieben, da muss ich nicht zwingend mit einer externen Software LUTs generieren. doch! -- es wird nur die verwendung dieser komplexeren konfigurationsangaben direkt am monitor unabhängig von jeder software am rechner ausgeführt.

und natürlich gibt's auch die variante mit den im monitor mit eingebauten messsonden und die original eizo software, was aber alles in puncto qualität nur noch unbefriedigendere nachteile mit sich bringt.

der wesentliche punkt, wo ich mit rdcl anderer meinung bin, ist die frage ob man auch im fall der verwendung derartiger 3D-LUTs innerhalb des monitors von hardware-KALIBRIERUNG sprechen darf, oder ob diese sprechweise nur für die alten (völlig unbrauchbaren!) 1D-LUTs zulässig ist? ;) Ich spreche aber von Hardwarekalibrierung, da die (mit der Eizo-Software) generierte Matrix (oder vielleicht ist es auch eine LUT, geht ja prinzipiell beides) direkt auf dem Monitor gespeichert wird. Ja, Eizo-Software, natürlich völlig ungenügend ;)



Antwort von rdcl:

dienstag_01 hat geschrieben:
mash_gh4 hat geschrieben:


doch! -- es wird nur die verwendung dieser komplexeren konfigurationsangaben direkt am monitor unabhängig von jeder software am rechner ausgeführt.

und natürlich gibt's auch die variante mit den im monitor mit eingebauten messsonden und die original eizo software, was aber alles in puncto qualität nur noch unbefriedigendere nachteile mit sich bringt.

der wesentliche punkt, wo ich mit rdcl anderer meinung bin, ist die frage ob man auch im fall der verwendung derartiger 3D-LUTs innerhalb des monitors von hardware-KALIBRIERUNG sprechen darf, oder ob diese sprechweise nur für die alten (völlig unbrauchbaren!) 1D-LUTs zulässig ist? ;) Ich spreche aber von Hardwarekalibrierung, da die (mit der Eizo-Software) generierte Matrix (oder vielleicht ist es auch eine LUT, geht ja prinzipiell beides) direkt auf dem Monitor gespeichert wird. Ja, Eizo-Software, natürlich völlig ungenügend ;) Das ist aber genau der gleiche Prozess. Der Unterschied ist nur, dass das LUT einmal aus der Eizo Software kommt und im Monitor gespeichert wird und einmal über ein externes Programm generiert wird und in den Monitor geladen muss. Viele Leute sagen halt, dass die Eizo Software das nicht so akkurat macht wie z.B. DisplayCal. Da kann man meines Wissens nach auch viel mehr Patterns messen lassen.
Und ich bin mir nicht sicher, aber ich meine, dass man da auch nicht nur ein LUT speichern kann, sondern mehrere für verschiedene Farbräume.



Antwort von dienstag_01:

rdcl hat geschrieben:
dienstag_01 hat geschrieben:

Ich spreche aber von Hardwarekalibrierung, da die (mit der Eizo-Software) generierte Matrix (oder vielleicht ist es auch eine LUT, geht ja prinzipiell beides) direkt auf dem Monitor gespeichert wird. Ja, Eizo-Software, natürlich völlig ungenügend ;) Das ist aber genau der gleiche Prozess. Der Unterschied ist nur, dass das LUT einmal aus der Eizo Software kommt und im Monitor gespeichert wird und einmal über ein externes Programm generiert wird und in den Monitor geladen muss. Viele Leute sagen halt, dass die Eizo Software das nicht so akkurat macht wie z.B. DisplayCal. Da kann man meines Wissens nach auch viel mehr Patterns messen lassen.
Und ich bin mir nicht sicher, aber ich meine, dass man da auch nicht nur ein LUT speichern kann, sondern mehrere für verschiedene Farbräume. Wie ich dich verstehe, sind das auch nur theoretische Erwägungen.
Wenn man mehrere LUTs hochladen kann, dann muss ja in irgendeiner Weise die passende für den aktiven Farbraum ausgewählt werden.
In dem von dir verlinkten Guide steht dazu:
In this way, many different LUTs can be held within LightSpace CMS and quickly and easily uploaded into the Eizo display as needed, perfect for Look Management as well as accurate calibration to different standards.
Klingt für mich nicht nach, lade alle der Reihe nach hoch und lass den Monitor würfeln, welche gerade passt ;)

Müsste mal jemand was dazu sagen, der LightSpace benutzt.



Antwort von rdcl:

dienstag_01 hat geschrieben:
rdcl hat geschrieben:


Das ist aber genau der gleiche Prozess. Der Unterschied ist nur, dass das LUT einmal aus der Eizo Software kommt und im Monitor gespeichert wird und einmal über ein externes Programm generiert wird und in den Monitor geladen muss. Viele Leute sagen halt, dass die Eizo Software das nicht so akkurat macht wie z.B. DisplayCal. Da kann man meines Wissens nach auch viel mehr Patterns messen lassen.
Und ich bin mir nicht sicher, aber ich meine, dass man da auch nicht nur ein LUT speichern kann, sondern mehrere für verschiedene Farbräume. Wie ich dich verstehe, sind das auch nur theoretische Erwägungen.
Wenn man mehrere LUTs hochladen kann, dann muss ja in irgendeiner Weise die passende für den aktiven Farbraum ausgewählt werden.
In dem von dir verlinkten Guide steht dazu:
In this way, many different LUTs can be held within LightSpace CMS and quickly and easily uploaded into the Eizo display as needed, perfect for Look Management as well as accurate calibration to different standards.
Klingt für mich nicht nach, lade alle der Reihe nach hoch und lass den Monitor würfeln, welche gerade passt ;)

Müsste mal jemand was dazu sagen, der LightSpace benutzt. Kann ich auch nicht beantworten, weil ich selber keinen Eizo nutze. Ich hätte gedacht, dass man quasi jedes Preset des Eizos (also alle Profile die vorangelegt sind) überschreiben kann. Somit könnte man einige Farbräume mit eigenen Luts überschreiben. Aber wie gesagt, das ist nur meine Vermutung.



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Wenn man mehrere LUTs hochladen kann, dann muss ja in irgendeiner Weise die passende für den aktiven Farbraum ausgewählt werden.
In dem von dir verlinkten Guide steht dazu:
In this way, many different LUTs can be held within LightSpace CMS and quickly and easily uploaded into the Eizo display as needed, perfect for Look Management as well as accurate calibration to different standards.
Klingt für mich nicht nach, lade alle der Reihe nach hoch und lass den Monitor würfeln, welche gerade passt ;)
Müsste mal jemand was dazu sagen, der LightSpace benutzt. in einem CalMan-handbuch (eine weitere bekannte farbkalibrierungssoftware, der wir u.a. dieses tolle fernsteuer-feature für die pattern-darstellung verdanken, wie man es auch für LUT-generierung aus dem resolve heraus nutzt), steht dazu:

Note: Because the EIZO monitors have only one 3D LUT per input, there are no selections available in the 3D LUT Memory drop down, on the LUT Device Setup page.

Also, on the Display Control tab, select the Display Mode that corresponds to the monitor input that you are calibrating.

CG232W
Cal – for all inputs
CG246, CG276, CX240, CX270
CAL1 – for DVI
CAL2 – for DisplayPort
CAL3 – for HDMI
CG247, CG247x, CG277
Mode8 (CAL1) – for DVI
Mode9 (CAL2) – for DisplayPort
Mode10 (CAL3) – for HDMI
CX241, CX271
Mode5 (CAL1) – for DVI
Mode6 (CAL2) – for DisplayPort
Mode7(CAL3) – for HDMI
CX248-4K, CX318-4K
CAL1 or CAL2

Note: On some EIZO monitors, there are additional display modes available that are global across all inputs. These additional modes do not support 3D LUT calibration.

was die eizo-interne verarbeitung betrifft, ist übrigens auch noch hier einiges nützliches zu finden:

https://www.eizo.at/praxiswissen/farbma ... birierung/

ich finde es zwar nicht ganz zutreffend, wie man darin Software-Kalibrierung auf etwas sehr simples reduziert, das so ganz und gar nicht mehr der wirklichkeit bspw. im zusammenhang mit 3D-LUTs im resolve entsoricht, aber dafür sieht man wenigstens auch, dass dort auch nur mit wasser gekocht wird und am ende natürlich auch wieder FRC -- also: dithering! -- zum einsatz kommt. ;)


zum Bild




Antwort von Frank Glencairn:

pillepalle hat geschrieben:
@ catsin

Ja, weil die Kamera das viel genauer sieht, als Dein Auge. Vor Ort würdest Du den Unterschied kaum wahrnehmen, weil Dein Auge viel kompensiert. Er geht darauf im Review auch ein. Wenn Du einen Monitor mit noch mehr Magenta neben den Asus stellen würdest, kame der Erste Dir grünlich vor :)

VG Warum kompensiert mein Auge dann nicht die Monitore?



Antwort von klusterdegenerierung:

"Frank Glencairn" hat geschrieben:
klusterdegenerierung hat geschrieben:

Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau? Hab ich noch nie erlebt, daß das 100%ig klappt - nicht mal bei 3 gleichen Monitoren, leichte Unterschiede sind da immer - jedenfalls mit den bei uns hier üblichen budget Messsonden im (Spider/Color Munki etc). Womöglich bringen Sonden die mehr als das Doppelte des Monitors kosten ein genaueres Ergebnis - keine Ahnung. Nachdem damals die halbe Druckerei bei mir aufgeschlagen ist und das alles nix wurde, habe ich Jürgen Groß zu mir bestellt.
Ich hatte dann mit ihm ein Seminar, in dem es dann damals auch den i1 Display, war damals noch GreatgMacbeth, dazu gab.

Jürgen hat mir damals ganz klar zu verstehen gegeben, das aus meinem Vorhaben, 3 unterschiedliche Monitor so zu kalibrieren das sie alle das gleiche Grau haben, verabschieden kann.

https://www.deltae.eu

Dies könne man nicht mal von 3 gleichen Geräten erwarten und das höchste der Gefühle sei, das man den Referenzmoni 100% hat und alle anderen die abweichen, dahin verdreht, das sie sich angleichen, aber das nur dafür interessant, das man sich nicht zu sehr an die nicht matchenden Monitorfarben gewöhnt.

Also man gut nach links und der hat einen Grünstich und man guckt auf den Referenzmoni und dieser hat dadurch kurz auch einen Grünstich usw.
Auch meinte er, wie auch Du, das ich mich davon verabschieden kann, das wenn ich mein Büro verlassen, irgendjemand anderes die gleichen Farben so sieht wie ich.

Und wozu das ganze dann frug ich ihn, er meinte, damit man für sich safe ist und die Druckerei auch das richtige bekommt, was andere an ihren Monis sehen kann ich eh nicht beeinflussen.

Abgefahren in dem Kontext, ich hab damals zu einer Firmengruppe mit einer Pharma Werbeagentur gehört und hab quasi täglich Pharmaverpackungen fotografiert und die Grafikabteilung von denen hatte ganz alte Macs mit ollen Röhrenmonitoren und extrem gelbstichig und dunkel waren.

Ich hätte meinen A darauf verwetten können dass das keiner wird, aber nachdem nach deren Weiterverarbeitung das Proof aus dem Drucker kam, sah es exakt so aus wie bei mir auf dem Monitor!
Ich frug sie wie sie das gemacht hätten mit dieser ollen Gurke und sie meinten, ich schaue daoch nicht auf den Monitor sondern auf meine CMYK Werte die mir meine Pipette anzeigt und ich hatte vorher eine Woche mit Monitor kalibrieren verbracht. Hahaha :-)



Antwort von srone:

einer der gründe, warum ich hier immer wieder dieses hullfish tutorial mit der rgb-parade auspacke...;-)



lg

srone



Antwort von pillepalle:

@ kluster

Natürlich hat man keinen Einfluß auf den Monitor anderer Leute und was die sehen, aber deshalb veranstaltet man den ganzen Zirkus ja. Damit alle halbwegs das gleiche sehen. Und wenn man das vernünftig macht, sind die Unterschiede minimal. So ähnlich wie in dem verlinkten Video. Sich an nichts zu halten, nur weil etwas nicht perfekt ist, kann doch auch nicht die Lösung sein.

Man kann sich auch an RGB Werten orientieren, auch an der Parade, usw... man weiß dann auch ob etwas clippt, oder neutral grau ist, aber man bekommt damit noch keinen Eindruck vom Bild. Und das ist doch alles was mich interessiert. Ich möchte steuern was z.B. in den Schatten noch zu sehen sein soll, oder welchen Farbton die Wand hat und das nicht dem Zufall überlassen. Es geht um möglichst vorhersehbare Ergebnisse.

VG



Antwort von dienstag_01:

mash_gh4 hat geschrieben:
dienstag_01 hat geschrieben:
Wenn man mehrere LUTs hochladen kann, dann muss ja in irgendeiner Weise die passende für den aktiven Farbraum ausgewählt werden.
In dem von dir verlinkten Guide steht dazu:
In this way, many different LUTs can be held within LightSpace CMS and quickly and easily uploaded into the Eizo display as needed, perfect for Look Management as well as accurate calibration to different standards.
Klingt für mich nicht nach, lade alle der Reihe nach hoch und lass den Monitor würfeln, welche gerade passt ;)
Müsste mal jemand was dazu sagen, der LightSpace benutzt. in einem CalMan-handbuch (eine weitere bekannte farbkalibrierungssoftware, der wir u.a. dieses tolle fernsteuer-feature für die pattern-darstellung verdanken, wie man es auch für LUT-generierung aus dem resolve heraus nutzt), steht dazu:

Note: Because the EIZO monitors have only one 3D LUT per input, there are no selections available in the 3D LUT Memory drop down, on the LUT Device Setup page.

Also, on the Display Control tab, select the Display Mode that corresponds to the monitor input that you are calibrating.

CG232W
Cal – for all inputs
CG246, CG276, CX240, CX270
CAL1 – for DVI
CAL2 – for DisplayPort
CAL3 – for HDMI
CG247, CG247x, CG277
Mode8 (CAL1) – for DVI
Mode9 (CAL2) – for DisplayPort
Mode10 (CAL3) – for HDMI
CX241, CX271
Mode5 (CAL1) – for DVI
Mode6 (CAL2) – for DisplayPort
Mode7(CAL3) – for HDMI
CX248-4K, CX318-4K
CAL1 or CAL2

Note: On some EIZO monitors, there are additional display modes available that are global across all inputs. These additional modes do not support 3D LUT calibration.

was die eizo-interne verarbeitung betrifft, ist übrigens auch noch hier einiges nützliches zu finden:

https://www.eizo.at/praxiswissen/farbma ... birierung/

ich finde es zwar nicht ganz zutreffend, wie man darin Software-Kalibrierung auf etwas sehr simples reduziert, das so ganz und gar nicht mehr der wirklichkeit bspw. im zusammenhang mit 3D-LUTs im resolve entsoricht, aber dafür sieht man wenigstens auch, dass dort auch nur mit wasser gekocht wird und am ende natürlich auch wieder FRC -- also: dithering! -- zum einsatz kommt. ;)


zum Bild
Danke. Lauf dem Eizo-Artikel werden die Kalibrierungswerte auch als LUT gespeichert.

Ich denke aber, ich habe mich hier etwas verhakt, eine Preview LUT geht in Resolve sowieso nur mit der Decklink. Und wenn eine Decklink angeschlossen ist, geht auch die Kalibrierung aus Resolve heraus. Ohne Decklink bleibt nur Gottvertrauen ;)



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
Jürgen hat mir damals ganz klar zu verstehen gegeben, das aus meinem Vorhaben, 3 unterschiedliche Monitor so zu kalibrieren das sie alle das gleiche Grau haben, verabschieden kann.

Dies könne man nicht mal von 3 gleichen Geräten erwarten und das höchste der Gefühle sei, das man den Referenzmoni 100% hat und alle anderen die abweichen, dahin verdreht, das sie sich angleichen, aber das nur dafür interessant, das man sich nicht zu sehr an die nicht matchenden Monitorfarben gewöhnt. ich seh das nicht ganz so pessimistisch.

für mich ist das bemühen um vernünftig kalibrierte arbeitsumgebungen fast genauso selbstverständlich wie das korrekte belichten beim aufnehmen.

und natürlich benutze ich dort genauso belichtungsmesser und noch komplizierteres zeug und mach mir auch drüber gedanken, wie man unter den gegebene umständen das beste aus der gegebenen situation mit meiner kamera herausholen könnte?

natürlich ist dann letztlich nie alles ganz perfekt belichtet, aber es bewegt sich zumindest meist in einem rahmen, dass man damit einigermaßen zufrieden sein kann.

warum also mit farbdarstellung auf den monitoren nicht auch ähnlich sorgsam umgehen?

im gegensatz zu anderen vertrau ich dar weniger auf prestigeträchtige marken od. irgendwelche spezialhardware, die ich mir ohnehin nicht leisten kann, sondern versuch eben aus den tatsächlich verfügbaren arbeitsmitteln ein maximum herauszuholen. wenn man sich ein bisserl mit der materie beschäftigt, geht da ohnhin wesentlich mehr als man glaubt, weil viele teure lösungen auch nur komplexität für die benutzer zu reduzieren versuchen, aber auf alternativen wegen oft das selbe mit bescheideneren mitteln erreicht werden kann.

ich hab z.b. unheimlich viel aus den entwicklungsbemühungen rund um das ColorHug projekt gelernt. dieser versuch eine freie farbkalibrierungshardware zu entwicklen, hat zwar letztlich nichts hervorgebracht, das den kommerziellen produkten überlegen gewesen wäre, aber dafür hat man all die praktischen probleme und mängel, die sich im laufe der entwicklung gezeigt bzw in den weg gestellt haben wenigstens ganz offen kommuniziertt. genaue dieses moment fehlt ja im zusammenhang mit den meisten kommerziellen produkten völlig. auch wenn es sich in wahrheit um absoluten schrott handelt, wird es halt hübsch verpackt und trotzdem irgendwie an den mann gebracht. über die technischen probleme, beschränkungen und mängel hört man in der regel kaum etwas fundiertes. das ColorHug projekt dagegen war ein richtig spannender prozess, bei dem ganz viele detailproblem rund die farbmessung und kalibrierung von grafikbildschirmen immer deutlicher zu tage getreten sind. wer das miterlebt hat, schaut seither eben auch produkte von Xrite mit etwas skeptischerem blick an. ;)
klusterdegenerierung hat geschrieben:
Und wozu das ganze dann frug ich ihn, er meinte, damit man für sich safe ist und die Druckerei auch das richtige bekommt, was andere an ihren Monis sehen kann ich eh nicht beeinflussen. naja -- ich kenn durchaus auch aus meinen bekanntenkreis kollegen, die mit druckereien wegen abweichender farben gerichtsprozesse ausfechten mussten, und in weiter folge dann natürlich relativ sensibilisiert für diese fragen waren bzw. immer viel aufwand darum getrieben haben.

mich selber beschäftigt es aber natürlich viel eher, weil das ganze eine verdammt reizvolle und nicht ganz triviale technisch-mathematische herausforderung darstellt. etwas, das sich zum glück noch immer ein klein wenig vom lustigen herumgewackel mit dem handy unterscheidet und an richtiges handwerk bzw. damit verbundenes wissen erinnert. aber vom pragmatisch gestalterischen her, bin ich natürlich auch weiterhin viel eher ein unbelehrbarer s/w-fetischist, der mit farben im grunde eh nichts zu tun haben will! :)



Antwort von srone:

mash hats geschafft, das letzte quäntchen farbe aus diesem thread zu nehmen...;-)))

lg

srone



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Lauf dem Eizo-Artikel werden die Kalibrierungswerte auch als LUT gespeichert. wobei halt die betreffenden LUTs innerhalb von resolve in einer 32bi- pipeline und mit ziemlich vertraunserweckenden interpolierungstechniken verarbeitet werden dürften, und in den monitoren doch deutlich einfachere mittel genutzt werden. trotzdem sollte man das nicht überbewerten, weil sich auch die übertragung selbst als flaschenhals erweisen kann bzw. u.u. mögliche übertragungswerte verschenkt werden, wenn man die LUTs bzw. notwendigen anpassungen am computer prozessiert.
dienstag_01 hat geschrieben:
Ich denke aber, ich habe mich hier etwas verhakt, eine Preview LUT geht in Resolve sowieso nur mit der Decklink. Und wenn eine Decklink angeschlossen ist, geht auch die Kalibrierung aus Resolve heraus. Ohne Decklink bleibt nur Gottvertrauen ;) wie gesagt: die ganze geschichte ist im resolve sicher nicht ganz unabsichtlich in dieser weise bis zur unbrauchbarkeit verkrüppelt worden. technisch würde nichts dagegen sprechen es wesentlich zufriedenstellender abzuwickeln, so wie es ja praktisch alle anderen ernsthaften mastering lösungen erlauben.



Antwort von Darth Schneider:

...Schon beeindruckend was für ein Aufwand da betrieben wird...
Ich für mein Teil habe diesbezüglich gar keine Profi Ansprüche.
Ganz primitiv, am dem iMac einen billigsten kleinen Tv, über hdmi daran gehängt, der gar keine gute Bildqualität anzeigen kann. Wenn mein Material darauf o.k. aussieht. Sieht es auf einem Profi Monitor oder auf einem teuren Tv Gerät, oder auf einem iPad/iPhone, oder einem Computer Monitor auch auch nicht schlechter aus. ;)
Gruss Boris



Antwort von pillepalle:

Der Link von dienstag_01 auf die Eizo Seite erklärt doch schon mal ganz gut wie Eizo damit umgeht (wenn auch nicht bis ins kleinste Detail). Klingt auch recht plausibel, dass man mit dem heimischen Colorimeter kaum genauer messen wird, als mit den Messgeräten die Eizo im Werk verwendet.

Das einzige was mich am Resolve Workflow über die Decklink karte etwas stutzig macht (sofern ich das richtig verstanden habe), ist die Tatsache das man bei einer Kalibrierung über Resolve dann doch praktisch wieder eine Software Kalibrierung macht, oder sehe ich das falsch? Da wird die Kalibrierung dann irgendwo auf dem Computer gespeichert und die Decklink Karte greift darauf zurück. Das wäre ja jetzt eigentlich auch nicht so der Hit. Und welche Kalibrierungssoftware nutzt Resolve dann für's kalibrieren des Monitors?

VG



Antwort von carstenkurz:

Ich habe das nicht vollständig gelesen, aber kann nur vermuten, dass Resolve in jedem Fall die Möglichkeit einer eigenen Monitorkalibrierung vorsehen muss (schon allein über die Farbraumanpassung), für den Fall dass der externe Monitor nicht hardwarekalibrierbar ist. In welchem Umfang diese Softwarekalibrierung dann faktisch eingreifen muss, dürfte sich über das Kalibrierungspotential des Monitors entscheiden.



Antwort von Frank Glencairn:

Is eigentlich ganz einfach und straight forward - mach ich ungefähr ein mal im Monat.
Keine Ahnung, warum das hier kompliziert geredet wird.





Antwort von dienstag_01:

"Frank Glencairn" hat geschrieben:
Is eigentlich ganz einfach und straight forward - mach ich ungefähr ein mal im Monat.
Keine Ahnung, warum das hier kompliziert geredet wird.

Das Kalibrierungsziel hat er vergessen einzugeben. Oder hab ich den Punkt übersehen ;)



Antwort von pillepalle:

Ja, in dem Fall hat er praktisch eine Software-Kalibrierung gemacht, weil sein OLED Display keine Hardware Kalibrierung zuläßt und die Werte sozusagen manuell hingedreht. Und das Profil (die 3DLUT) wird dann praktisch von Resolve als Monitorprofil verwendet.

Die Frage ist jetzt noch, ob man die Kalibrierung dann auch mit DisplayCal machen muss, oder ob man den Monitor dann auch mit z.B. mit der Color Navigator Software von Eizo, oder dem SpectraView Profiler von NEC kalibrieren kann? Am 02.02. soll meine Decklink Karte kommen. Dann kann ich auf jeden Fall mal die Bilder die aus der Decklink Karte kommen mit denen vergleichen, die nicht aus der Karte kommen. Bin gespannt...

VG



Antwort von mash_gh4:

pillepalle hat geschrieben:
Der Link von dienstag_01 auf die Eizo Seite erklärt doch schon mal ganz gut wie Eizo damit umgeht (wenn auch nicht bis ins kleinste Detail). Klingt auch recht plausibel, dass man mit dem heimischen Colorimeter kaum genauer messen wird, als mit den Messgeräten die Eizo im Werk verwendet. ich fürchte, da liegt ein grobes missverständnis vor:

eizo erklärt zwar auf diesen seiten, warum sie im farbkorrekturprozess für manche teilbereiche werteangaben priorisieren bzw. nutzen, die aus konstruktiven eigenheiten heraus genauer bekannt sind als man sie mit gebräuchlichen mitteln nachmessen könnte, trotzdem ist das eher nur ein unbedeutendes detail am rande. für ernsthafteres arbeiten ist es natürlich auch mit eizo-monitoren praktisch unumgänglich, dass die geräte laufend mit tri-stimulus-kolorimetern od. spektrofotometern nachkalibriert werden. genau das unterstützen ihre besseren geräte auch relativ gut bzw. in einigermaßen benutzerfreundlicher weise.

erst in einer preislich weit darüber angesiedelten liga -- also bei flanders scientific (FSI) od. dolby referenz monitoren -- ist es dann tatsächlich üblich, dass diese notwendigen nachjustierungen an den geräten nur mehr vom hersteller selbst in regelmäßigen abständen vorgenommen werden.
pillepalle hat geschrieben:
Das einzige was mich am Resolve Workflow über die Decklink karte etwas stutzig macht (sofern ich das richtig verstanden habe), ist die Tatsache das man bei einer Kalibrierung über Resolve dann doch praktisch wieder eine Software Kalibrierung macht, oder sehe ich das falsch? unter "software-kalibrierung" kann man leider ganz verschiedene sachen verstehen!

es wird sehr gerne mit mit jenen relativ einfachen techniken in verbindung gebracht, bei denen man schon vor zwei jahrzehnten, tabellen auf der grafikkarte aktivieren konnte, mit denen der helligkeitsverlauf bzw. die entsprechende transferfunktion in den einzelnen farbkanälen modifiziert wurde. im wesentlichen deckt sich das mit 1D-LUT korrekturen, wie sie ressolve bei den entsprechenden einstellungen noch immer anbietet. im umfeld von kathodenstrahlröhren und sehr beschänkten eingriffsmöglichkeiten hat das damals auch durchaus sinn gemacht, nur erfüllt es natürlich schon lange nicht mehr jene ansprüche, die man sich heute von derartigen korrekturen erwartet. es ist vielmehr so, dass derartige einfache korrekturtabellen in den grafikkarten, wenn sie im hintergrund aktiv sind, anspruchsvollerem color management ausgesprochen ungut im weg stehen können. das selbe gilt aber leider auch für ähnlich gelagerte korrekturen auf seiten der monitore bzw. deren "hw-kaliberungsfeatures", die ja leider oft kaum weniger unbefriedigend einfach umgesetzt sind.

die entsprechenden 3D-LUT korrekturangaben, wie man sie im resolve zumindest für zwei ausgabeschienen -- die decklink-karte und den viewer in der color-page -- gezielt festlegen kann, nicht aber für all die anderen anzeigevarianten auf den computerbildschirmen od. gar den vollbild-ausgabemodus ("clean feed"), werden aber in völlig anderer weise prozessiert. mit 3D-LUTs lassen sich hier auch komplexere korrekturen vornehmen, die eben nicht nur die intensitätsverlauf der einzelnen farbkanäle isoliert behandeln, vielmehr wird hier immer das zusammenspiel aller kanäle berücksichtigen bzw. von vollständigen ausgangsfarbwerten auf einen zielfarbwert geschlossen. für ein videoverarbeitungsprogramm mit color grading funktionalität ist das ohnehin keine besondere schwierigkeit, weil es ganz ähnlich gelagerte operation auch sonst ständig ausführt. mit GPU-unterstützung geht das heute auch extrem schnell und in einer genauigkeit, die sowohl in der auflösung der verwendeten werte (32bit-fließkomma berechnungsgenauigkeit), der anzahl der zulässigen Gitterstützpunkte und der art der benutzten interpolationsmethoden weit über das hinaus geht, was die entsprechenden lösungen innerhalb der meisten monitore zu leisten im stande sind.

ein derartige umrechnung mit hilfe von 3D-LUTs ist zumindest für die vorschau im videoumfeld recht gebräuchlich. ganz ideal ist sie trotzdem nicht, weil zumindest die umrechnung bzw. anpassung an standardisierte farbräume mit hilfe von matrix-transformationen noch ein wenig genauer durchgeführt werden kann. die vorzüge bzw. argumente für zweiteres, kennt ohnehin jeder hier aus der ganz ähnlich gelagerten aufgabestellung beim import von LOG-footage aus kameras. fast alle professionelleren lösungen erledigen das mittlerweile mit diesen mathematisch saubereren methoden, die auf aktuellen GPUs auch locker in echtzeit angewendet werden können. das war auch eine der ganz wichtigen OpenColorIO v2 verbesserungen, wo man auf druck der filmindustrie und der ACES arbeitsgruppen, mittlerweile auch duchgängig von 3D-LUTs abergerückt ist und statt dessen die betreffenden matrixoptionen direkt auf der GPU rechnet. so gesehen ist eben bspw. die ausgabe eines rec709-projekts an einen P3-DCI monitor mittels einer solchen 3D-LUT umwandlungseinstellung, wie sie im reolve möglich wäre, eben nicht mehr unbedingt als stand der technik anzusehen, auch wenn es natürlich für den hausgebrauch gewiss reichen dürfte.
pillepalle hat geschrieben:
Da wird die Kalibrierung dann irgendwo auf dem Computer gespeichert und die Decklink Karte greift darauf zurück. mit den decklink-karten hat das alles sehr wenig zu tun, weil die ja leider wirklich nur ganz primitive ausgabekarten sind, und im gegensatz zu gebräuchlichen GPUs kaum irgendwelche berechnungen od. umwandlungen direkt auf der karte auszuführen vermögen. die geben wirklich nur unverändert jene werte aus, die ihnen von seiten der software fertig zugreicht werden.

es ist nur der willkürlichen entscheidung seitens der resolve verantwortlichen geschuldet, dass dort praktisch nur die ausgabe über zusätzliche hardware von BMD und das winzige fensterchen in der color-page auf recht umständliche weise zur ausgabe korrekter farben bewegt werden kann, aber prinzipell könnte man das natürlich in völlig gleichartiger weise auf für alle anderen anzeigevarianten vorsehen. bei praktisch allen vergleichbaren programmen ist letzteres ohnehin längst eine selbstverständlichkeit.

pillepalle hat geschrieben:
Das wäre ja jetzt eigentlich auch nicht so der Hit. Und welche Kalibrierungssoftware nutzt Resolve dann für's kalibrieren des Monitors? das geht mit fast jeder gebräuchlichen farbkalibrierungssoftware (CalMan, LightSpace, ArgyllCMS, DisplayCal, ...), weil das verwendete 3D-LUT format recht gebräuchlich ist, und auch die steuerung der farb-patterns während der messung mittlerweile fast überall in gleicher weise abgewickelt wird. unterschiede gibt's hauptsächlich in der bedienbarkeit der programme -- die sehr oft eine mittlere zumutung darstellt! -- und der genauigkeit der berechungen bzw. unterschiedliche strategien bei der durchführung des messverlaufs.



Antwort von pillepalle:

@ mash_gh4

Eigentlich versteht man unter einer Software-Kalibrierung das die Werte eben in einem Profil auf dem Computer gespeichert werden, statt im Monitor selber. Im Falle von Resolve anscheinend in einer 3DLUT die auf dem Rechner gespeichert wird. Wäre dann aber trotzdem eine Software-Kalibrierung. Die Frage ist eben, ob das besser sein kann. Eigentlich nur von der Warte aus, das Resolve sich dabei nicht reinpfuschen läßt, weil es eben über die Decklink Karte läuft. Wieviel da tatsächlich reingepfuscht wird, weiß man aber erst nach einem Vergleich mit und ohne Karte.

VG



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Das Kalibrierungsziel hat er vergessen einzugeben. Oder hab ich den Punkt übersehen ;) naja -- da gibt's ein paar punkte, die im detail ein deutlich sauberer gehandhabt werden sollten -- youtube halt! -- aber natürlich trotzdem ein deut in die richtige richtung!

also -- ganz kurz

* prinzipiell braucht's zumindest zwei derartige durchlaufe, um sowohl fur decklink-ausgabe wie auch den color-vieere zumindest auf einem GUI schirm derartige 3D-LUTs auszumessen und zu kalibieren. (für die anderen ausgabevarinaten -- stichwort "clean feed" bzw. mehre GUI-schirme geht's eben im resolve leider ohnehin nicht)

* OLED ist leider super problematisch und mit normalen probes -- so wie er sie hier verwendet fast nicht vertretbar in den griff zu bekommen

(siehe dazu auch: https://www.chromapure.com/newgear_i1%2 ... curacy.asp )

* das mit dem angepeilten referenzwerten finde ich auch einen ganz entscheidenden punkt, der halt hier nich zu sehen war, weil sich DisplayCal die entsprechenden einstellungen merkt und nicht dauernd wieder danach fragt. jedenfalls würde ich hier für rec709 unbedingt 100 od. 120cd/m² in abgedunkelten artebeitsumgebungen nutzen. das entspricht in etwa jenem wert, in dem die vorgegebene gamma kurven auch tatsächlich sinn machen bzw. zu den erwarteten bildeindrücken führen.



Antwort von pillepalle:

@ mash_gh4

Du meinst umgekehrt, also 100cd/m² in abgedunkelten Räumen und 120cd/m² in helleren. REC709/BT1886 hat ja standartmäßig 100cd/m2, wogegen man bei sRGB normalerweise 120cd/m2 nutzt und auch nicht in dunklen Räumen sitzt.

VG



Antwort von mash_gh4:

pillepalle hat geschrieben:
@ mash_gh4

Eigentlich versteht man unter einer Software-Kalibrierung das die Werte eben in einem Profil auf dem Computer gespeichert werden, statt im Monitor selber. Im Falle von Resolve anscheinend in einer 3DLUT die auf dem Rechner gespeichert wird. nein -- eben leider nicht! -- weil eben die einstellungen dieser traditionellen form der "sw-kalibrierung" od. zumindest dem, was damit landläufig gerne in verbindung gebracht wird, eben auch nicht einfach nur als profil am rechner herumliegen, sondern auch bereits in hardware -- konkret: den vcgt-tables auf der grafikkarte -- prozessiert wurden.

die unterscheidung zw. "rechnerseitig" und "anzeigerätseige" korrektur ist also vermutlich unmissverständlicher.

der wirklich entscheiden punkt ist eben dabei die frage, ob am anschlusskabel tatsächlich auf das entsprechende referenzsignal abzielt od. eben erst die tatsächliche anzeige am schirm relevant ist.

ersteres ist in studio-zusammenhängen natürlich eine völlige unverzichtbare forderung, damit unzählige geräte problemlos zusammenarbeiten können, einfach austauschbar sind und auch zb. scopes od. QA-services die korrektheit der übertragenen werte überprüfen können.
in anderen fällen sind aber all diese punkte weitestegehend irrelevant, dafür will man einfach ein möglichst korrektes bild auf der anzeige. das kann eben z.t. mit entsprechenden korrekturen direkt am rechner ohne ga störende zwischenschritte auf den beteiligten geräten befriedigender umgesetz werden als mit unnötig teuren pseudo-studio gerät.

pillepalle hat geschrieben:
Wäre dann aber trotzdem eine Software-Kalibrierung. Die Frage ist eben, ob das besser sein kann. Eigentlich nur von der Warte aus, das Resolve sich dabei nicht reinpfuschen läßt, weil es eben über die Decklink Karte läuft. Wieviel da tatsächlich reingepfuscht wird, weiß man aber erst nach einem Vergleich mit und ohne Karte. wie gesagt. das problem liegt eher darin, dass dir BMD-software bzw. resolve gar keinen fairen vergleich zulässt, weil die enstprechenden ausgabe- und einstellungsmöglichkeiten von vornherein so eng begrenzt sind.

du kannst aber natürlich andere software heranziehen, die eine saubere ausgabe in beiden ausgabevarianten erlaubt -- also via GPU und decklink -- und dort die werte vergleichen. ich garantiere dir, dass du wirst dabei zumindest in den besseren umsetzungen absolut keinen signifikanten unterschied entdecken!

wie gesagt -- decklink hat ja durchaus in anderen zusammenhängen noch immer eine vernünftige berechtigung -- z.b. wenn man SDI-connectivity braucht --, aber korrekte farbwerte über HDMI od. displayport auszugeben, vermag auch praktisch jede gebräuchliche GPU weise.



Antwort von mash_gh4:

pillepalle hat geschrieben:
Du meinst umgekehrt, also 100cd/m² in abgedunkelten Räumen und 120cd/m² in helleren. REC709/BT1886 hat ja standartmäßig 100cd/m2, wogegen man bei sRGB normalerweise 120cd/m2 nutzt und auch nicht in dunklen Räumen sitzt. ob 100, 120 od. 150 ist fast vernachlässigbare, wenn du mit entsprechenden messgeräten einmal überprüfst, was von div. monitoren in der rec709-hersteller-einstellung als default-helligkeit genutzt wird. das liegt oft um das doppelte drüber, damits für die kunden "hübsch" od. "brillant" ausschaut!

in der praxis hat es eben tatsächlich sehr viel mit den umgebenden lichtverhältnissen zu tun, welche einstellung tatsächlich sinn macht.



Antwort von pillepalle:

@ mash_gh4

Das ist ja das was ich auch vermute. Das es keinen relevanten Unterschied machen wird. Ist aber auch gut möglich, dass ich mich da irre. Deshalb werde ich ja auch beide Varianten miteinander vergleichen. Einmal am real angezeigten Bild und einmal an den jeweiligen Validierungsergebnissen.

Und klar, das Umgebungslicht ist sogar sehr wichtig und wird meist unterschätzt. Nicht nur in der Helligkeit, sondern auch in der Farbe. Um so mehr, wenn man auch noch Abmusterungen vornehmen möchte. Aber für Video ist der Unterschied tatsächlich nicht so riesig. Erst wenn man wirklich für's Kino gradet und in P3 arbeiten möchte, muss es wirklich dunkel sein. Sonst sieht man nichts in den Schatten.

VG



Antwort von domain:

Unglaublich, welcher Aufwand hier betrieben werden kann. Seinerzeit habe ich auf dem Sony 40W2000
zunächst harwaremäßig ein neutrales Grau eingestellt . Ab Werk war das eher in Rosa gehalten. Danach mit dem Bellenuit-Testchart die Bereiche 0-20 und 231-251 über Kontrast und Helligkeit so eingestellt, dass hier noch Unterschiede wahrnehmbar waren.
Jetzt mal mit Resolve auf einem anderen PC überprüft und festgestellt, das es etwas kontrastreicher arbeitet und demnach nachjustiert


zum Bild




Antwort von mash_gh4:

domain hat geschrieben:
Unglaublich, welcher Aufwand hier betrieben werden kann. es ist für mich total o.k., wenn sich kollegen um diese dinge nicht weiter kümmern und dafür halt ihre aufmerksamkeit ganz anderen aspekten widmen... das passt schon!

ärgerlicher finde ich es dagegen, wenn einfach unhaltbare dogmen und kritklosigkeit gepredigt werden od. irgendwelche unausrottbaren pseudo-professionellen herangehensweisen propagiert werden, die zwar den geldbeutel kräftig belasten, aber in wahrheit nicht unbedingt bessere resultate bewirken, so lange man sich mit der sache selbst nicht näher auseinandersetzt und die vorzüge entsprechender spezialwerkzeuge nicht tatsächlich korrekt zu nutzen versteht.



Antwort von carstenkurz:

domain hat geschrieben:
Unglaublich, welcher Aufwand hier betrieben werden kann. Hier geht es um sehr spezielle Fragen. Dass das Thema für die Mehrzahl der Anwender nicht relevant ist, sieht man daran, dass sich kaum jemand über tatsächliche Probleme in dem Bereich beschwert. Wie schon mehrfach geschrieben, solange man sich im Bereich rec.709/sRGB bewegt, hat man nur dann Probleme, wenn man Monitore und Grafikkarten/Verbindungen verwendet, die einfach grundsätzlich daneben (konfiguriert) sind. Zumindest ein bißchen Aufmerksamkeit muss man dem Thema gegenüber schon aufbringen, wenn man Ansprüche formuliert.



Antwort von roki100:

domain hat geschrieben:
Unglaublich, welcher Aufwand hier betrieben werden kann. Seinerzeit habe ich auf dem Sony 40W2000
zunächst harwaremäßig ein neutrales Grau eingestellt . Ab Werk war das eher in Rosa gehalten. Danach mit dem Bellenuit-Testchart die Bereiche 0-20 und 231-251 über Kontrast und Helligkeit so eingestellt, dass hier noch Unterschiede wahrnehmbar waren.
Jetzt mal mit Resolve auf einem anderen PC überprüft und festgestellt, das es etwas kontrastreicher arbeitet und demnach nachjustiert


zum Bild
so easy und leichtverständlich.



Antwort von cantsin:

roki100 hat geschrieben:
domain hat geschrieben:
Unglaublich, welcher Aufwand hier betrieben werden kann. Seinerzeit habe ich auf dem Sony 40W2000
zunächst harwaremäßig ein neutrales Grau eingestellt . Ab Werk war das eher in Rosa gehalten. Danach mit dem Bellenuit-Testchart die Bereiche 0-20 und 231-251 über Kontrast und Helligkeit so eingestellt, dass hier noch Unterschiede wahrnehmbar waren.
Jetzt mal mit Resolve auf einem anderen PC überprüft und festgestellt, das es etwas kontrastreicher arbeitet und demnach nachjustiert


zum Bild
so easy und leichtverständlich. ...wenn man sich noch in der Welt von alten TV-Standards bewegt, und es um nicht mehr geht, als dass ein Nachrichtensprecher nicht aussieht wie eine Tomate.



Antwort von roki100:

cantsin hat geschrieben:
...wenn man sich noch in der Welt von alten TV-Standards bewegt Du meinst wie Du? ;)) Du wolltest doch 4:3 90ger Look (oder etwas ähnlich) mit der sigma fp und ur-pocket etwas machen...einfach an die Empfehlung von domain halten dann passen sich die Farben automatisch an ;)



Antwort von domain:

Der Sony Fernseher ist ja auch an das Kabelnetz angebunden. Und die dort gezeigten Videos und Filme dienten mir im Durchschnitt ihrer Farben und Kontraste als Referenz. Was will man mehr, als dass die eigenen Videos dann dem entsprechen und durchaus herzeigbar sind? :-)



Antwort von Bluboy:

domain hat geschrieben:
Der Sony Fernseher ist ja auch an das Kabelnetz angebunden. Und die dort gezeigten Videos und Filme dienten mir im Durchschnitt ihrer Farben und Kontraste als Referenz. Was will man mehr, als dass die eigenen Videos dann dem entsprechen und durchaus herzeigbar sind? :-) Hier im Forum gilt das nicht ;-)



Antwort von Frank Glencairn:

pillepalle hat geschrieben:

Eigentlich versteht man unter einer Software-Kalibrierung das die Werte eben in einem Profil auf dem Computer gespeichert werden, statt im Monitor selber. Im Falle von Resolve anscheinend in einer 3DLUT die auf dem Rechner gespeichert wird. Wäre dann aber trotzdem eine Software-Kalibrierung. Hardware Kalibrierung ist immer wenn du eine Bildschirm Sonde (Hardware) nimmst. Diese muß natürlich immer mit irgendeiner Software betrieben werden, und das Ergebnis mit entsprechender Korrektur Tabelle irgendwo gespeichert - ob im Monitor oder in Resolve ist eigentlich erstmal egal.

Eine Software Kalibrierung wäre es, wenn du an den Reglern in deinem GPU Control Panel (software) rumdrehst.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Hardware Kalibrierung ist immer wenn du eine Bildschirm Sonde (Hardware) nimmst. ... das ist zumindest eine ausgesprochen originelle deutungsweise, die ich in dieser weise tatsächlich noch nie vernommen hab!:)

kennst du zufälligerweise irgendeine ernstzunehmendere quelle, die den begriff ähnlich nutzt?

ich kenne wirklich nur quellen, wo das ganz anders verwendet wird:

* "hw-kalibrierung" sich also auf ein unabhängies funktionieren am anzeigegerät bezieht.

* und entsprechende externe messinstrumente braucht man dem gebräuchlichen verständnis nach für sw- genauso wie für hw-kalibrierung.

ps: es gibt auch noch den ziemlich windigen begriff der "visual calibration", der vielleicht noch am ehesten mit dem zu tun habe könnte, was dir hier vorschwebt bzw. von domain praktiziert wird.



Antwort von pillepalle:

Ich habe euch mal eine Definition aus dem Prad-Lexikon kopiert:
Bei der Hardware-Kalibrierung werden die Kalibrierungs-Einstellungen via USB-Verbindung direkt in der LUT des Monitor vorgenommen. Daher enthält das anschießend vermessene Profil auch keine Kalibrierungsdaten mehr, die bei einer Software-Kalibration bei jedem Systemstart in die LUT der Grafikkarte geschrieben werden. Eine Hardware-Kalibration ist dagegen grundsätzlich von Computer und Grafikkarte völlig unabhängig.
Das ermöglicht eine deutlich höhere Präzision bei der Kalibration und vermeidet gleichzeitig die unerwünschte Beschneidung von Farbabstufungen. Während bei einer Software-Kalibration die Anzahl möglicher Farbwerte durch die RGB-Anpassung über die RGB-Gain-Regler des OSDs beschnitten wird, bleiben bei einer Handware-Kalibration die maximal möglichen 256 Farbstufen pro Farbkanal voll erhalten. Quelle
https://www.prad.de/lexikon/hardware-ka ... werden.

Ein Colorimeter ist natürlich in beiden Fällen im Spiel.


VG



Antwort von Frank Glencairn:

Ergibt sich ja aus dem oben gesagten. In einem Fall ist messtechnisch keine Hardware im Spiel, im anderen Fall schon.
Nur weil die Software im Monitor sitzt, statt im Rechner, macht es das Ganze noch lange nicht zur Hardware - wir haben solche Monitore früher als "selfcontained" oder "standalone Messung" bezeichnet - also wenn man auch ohne Rechner kalibrieren kann.

Das Problem dabei ist, daß das Signal das der Rechner dann ausgibt völlig ignoriert wird.
Ich persönlich messe lieber meinen kompletten Signalweg - also das was Resolve tatsächlich abliefert plus das was der Monitor draus macht - und nicht nur das Anzeigegerät, aber muß jeder selbst wissen.
pillepalle hat geschrieben:

Während bei einer Software-Kalibration die Anzahl möglicher Farbwerte durch die RGB-Anpassung über die RGB-Gain-Regler des OSDs beschnitten wird, bleiben bei einer Handware-Kalibration die maximal möglichen 256 Farbstufen pro Farbkanal voll erhalten. Das ist ein bisschen Schwindlig. Software Kalibrierung wäre danach angeblich das Drehen an den Reglern im OSD - ja, so kann man es natürlich auch nennen. Was wäre dann wenn man physikalische Drehknöpfe hat? Ist das dann Hard- oder Soft?
Und 256 Stufen - guten Morgen.

Egal - das sind sowieso alles nur Worte - die ändern nix dran wie es funktioniert.
Wie schon gesagt, die oben gezeigte Lösung funktioniert hier seit Jahren bestens, egal für welches Zielmedium.
Sonde aufhängen > Start drücken > Kaffee trinken gehen - und fertig, wieder Ruhe für nen Monat.



Antwort von dienstag_01:

Was für ein Unsinn wieder mal ;)



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Ergibt sich ja aus dem oben gesagten. In einem Fall ist messtechnisch keine Hardware im Spiel, im anderen Fall schon. geh -- bitte verzapf nicht einen derart peinlichen quatsch!

zu dem thema ist wirklich schon sehr sehr viel geschrieben worden...

lies die ersten paar zeilen hier:

http://www.christian-ohlig.de/2015/08/1 ... ibrierung/
("Immer wieder werde ich gefragt, wo denn der Unterschied zwischen einer Hardware- und einer Softwarekalibrierung liegt. Durch die vermeintlich weiterhelfende Benennung geistern viele falsche Erklärungsmuster durch die Fotogemeinde. Die Krux bei der Geschichte: Sowohl für eine Hardware- als auch für eine Softwarekalibrierung braucht man eine Kalibrierungssoftware und eine Hardware in Form eines Kalibrierungssensors. Wo aber liegt dann der Unterschied?")

... und du verstehst, was ich meine!

ich hab auch wirklich kein problem damit, wenn man sich zwischendurch einmal in den begriffen nicht ganz einig ist, und sich im ersten schritt einmal um ein deckungsgleiches gemeinsames verständnis der sache bemühen muss, aber über kurz oder lang sollte man sich dann doch um eine einigermaßen vernünftige und überprüfbare basis der argumentation bemühen.

es gibt wirklich unzählige seiten, die das begriffspar hardware vs. software kalibrierung behandeln. schau dich einfach um, bevor du hier derartigen unsinn vertrittst.



Antwort von pillepalle:

@ Frank

Die physischen Drehknöpfe haben damit, soweit ich weiß, eigentlich nichts zu tun. In der Regel benutzt man die aber nur bei einer Software-Kalibration, so z.B. wie in dem Video das Du verlinkt hattest. Im Falle von Resolve ist es ja sowieso anders, weil es ja eben nicht über das Betriebssystem, sondern über die Karte läuft. Das könnte also ähnlich präzise sein wie eine Hardwarekalibration. Am einfachsten ist ausprobieren.

VG



Antwort von roki100:

Alles Gut. Es geht nur um Bildschirm Kalibrierung. Dieser Thread wird hoffentlich nicht länger als "Was schaust Du gerade?" .LOL ;))



Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:
[
geh -- bitte verzapf nicht einen derart peinlichen quatsch!

... und du verstehst was ich meine!

.. schau dich einfach um, bevor du hier derartigen unsinn vertrittst.
Charmant wie immer.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
mash_gh4 hat geschrieben:
[
geh -- bitte verzapf nicht einen derart peinlichen quatsch!

... und du verstehst was ich meine!

.. schau dich einfach um, bevor du hier derartigen unsinn vertrittst. Charmant wie immer. sorry -- aber in dem fall kann man wohl wirklich kaum mehr nur ganz höflich auf mögliche wissenslücken od. verständigungsprobleme hinweisen...

was du hier betreibst, scheint mir mehr mit dem begriff der "demagogie" zu tun zu haben.



Antwort von roki100:

sind meine Tiere bei euch cinematisch (also so wie in modern Western Movies) oder muss eurer Bildschirm hardware-oder softwareseitig kalibriert werden?
Bildschirmfoto 2021-01-28 um 19.37.57.png Bildschirmfoto 2021-01-28 um 19.40.12.png



Antwort von srone:

wie immer, ein wenig dark roki...;-)

lg

srone



Antwort von roki100:

Dann musst Du nur dein Bildschirm ein bisschen heller stellen. Mehr Kalibrierung ist nicht erforderlich.



Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:

sorry -- aber in dem fall kann man wohl wirklich kaum mehr nur ganz höflich auf mögliche wissenslücken od. verständigungsprobleme hinweisen...

was du hier betreibst, scheint mir mehr mit dem begriff der "demagogie" zu tun zu haben. Hahaha - das wird ja immer besser :D

Was steigerst du dich da eigentlich so rein?

Kannst du mir mal verraten was an meinem Ansatz unlogisch ist?

Bei der "Erklärung" die du heran ziehst, ist in beiden Fällen eine Messonde und eine Software im Spiel - richtig?
Der Unterschied zwischen Hard-und Software Kalibrierung besteht in deiner Welt darin, wo die Software läuft - auf der Hardware des Rechners oder auf der Hardware des Monitors.
In beiden Fällen läuft eine Software, auf einer Hardware um die Sonde zu steuern.
Wie man daraus jetzt den Unterschied konstruieren kann, daß bei einer Software Kalibrierung eine Software auf einer Hardware läuft, im anderen Fall auch, aber mann nennt es dann andres, macht rein logisch keinen Sinn, und die Begründung ist: Sagt man halt so.

Aber es gibt ja auch Leute die einen Quantensprung für einen großen Schritt nach vorne halten, nur weil es die anderen auch so sagen.



Antwort von Bluboy:

DCI-P3 ICC Profile gibts Hier

http://color.support/iccprofiles.html



Antwort von mash_gh4:

Bluboy hat geschrieben:
DCI-P3 ICC Profile gibts Hier
http://color.support/iccprofiles.html das kann zwar evtl. nützlich sein, um in den umgebenden programmen und der systemkonfiguration mit diesem farbraum klarzukommen, aber in film- und videobearbungssoftware nutzt man in der regel OCIO statt ICC-basierende lösungen für derartige zwecke.



Antwort von roki100:

OpenColorIO Bachelorarbeit: https://www.hdm-stuttgart.de/vfx/alumni ... s/pdf_016/



Antwort von Bluboy:

In der Regel ?

Abgesehen davon dass Windows DCI-P3 .ICC an Bord hat, freut es mich wenn ich höre dass es Leute gibt, die irgedwas mit Open... unterstützen



Antwort von carstenkurz:

Du hast schon verstanden wozu diese Profile gut sind? Die haben mit einer Systemkalibrierung nichts zu tun...



Antwort von Bluboy:

carstenkurz hat geschrieben:
Du hast schon verstanden wozu diese Profile gut sind? Die haben mit einer Systemkalibrierung nichts zu tun... Ich hoffe Du meinst nicht mich, denn ich meine schon dass alles was über die Systemsteuerung eingestell wird, Systemtreiber sind.
nicht zu verwechseln mit den ICC die im Adobe Comon Ordner sind.



Antwort von mash_gh4:

Bluboy hat geschrieben:
In der Regel ? ja, normalerweise wird das heute zumindest in den meisten videoFX und color grading programmen genauso selbstverständlich genutzt bzw. unterstützt wie OpenFX-plugins.

obwohl das ganze tatsächlich in geradezu vorbildlicher weise als open source projekt entwickelt wurde, war es von anfang an, als es von sony picture entertainment entwickelt wurde, eher als herstellerübergreifernder industriestandard gedacht.

als solcher hat es mittlerweile in form des ACES-workflows, mit dem es eng in verbindung steht, eine ziemlich zentrale rolle in color managment für film- und videoproduktion eingenommen.

anfänglich hat es in den betreffenden tools noch ein eigenes werkzeug (ociobakelut) gegeben, um für bildverarbeitungsprogramme, die nur nur mit ICC profilen umzugehen verstehen, kompatible umwandlungstabellen zu generieren. mittlerweile unterstützen aber auch sehr viele bildverarbeitungslösungen (photoshop, affinity, etc.) direkt OCIO.

dass im resolve die unterstützung dafür noch immer ein wenig stiefmütterlich wirkt, hat vermutlich auch mit dem ganz grundsätzlichen design der dortigen verabeitungspipeline zu tun:

resolve orientiert sich noch immer sehr stark an traditionellen workflows, bei denen sich alles um den realtiv begrenzten farbraum der abschließenden ausgabe dreht, auch wenn die tatsächlichen berechnungen im hintergrund mittweile natürlich auch in YRGB RCM mit linearem licht operieren und diese komplexeren abläufe nur vor den benutzern weitestgehend fern gehalten werden. deshalb auch diese verarbeitungskette, wo das monitoring immer erst auf das tatächliche output-format angewendet wird:





in ACES-workflows und den moderneren zugängen des film- und videospezifischen color managements stehen dagegen die ausgedehnten arbeitsfarbräume im mittelpunkt und werden gar nicht erst in den hintergrund gerückt od. ausgeblendet. dementsprechend erfolgt dort auch das monitoring normalerweise vielmehr parallel zur abschließenden ausgabeumwandlung bzw. unabhängig davon:
ACES.png
zum Bild


auf diese weise können auch mehre ausgabevarianten (bspw. HDR und klass. rec709 od. eben DCI-P3) befriedigend produziert od. als übersetzte preview angezeigt werden, so wie das auch im hinblick auf die unterschiedlichen anforderung der farbaufbereitung für druck und web-publikation im grafik-umfeld schon lange üblich ist.

ist hier natürlich alles nur sehr verkürzt beschrieben bzw. grob angedeutet...



Antwort von Bluboy:

@mash_gh4
Danke für die Erklärung



Antwort von carstenkurz:

Bluboy hat geschrieben:
carstenkurz hat geschrieben:
Du hast schon verstanden wozu diese Profile gut sind? Die haben mit einer Systemkalibrierung nichts zu tun... Ich hoffe Du meinst nicht mich, denn ich meine schon dass alles was über die Systemsteuerung eingestell wird, Systemtreiber sind.
nicht zu verwechseln mit den ICC die im Adobe Comon Ordner sind. Warum Du sinnloserweise 'Systemtreiber' oder 'Systemsteuerung' erwähnst, weiss ich nicht. Auf der von dir verlinkten Seite tauchen diese Begriffe jedenfalls nicht auf. Statt dessen steht da:

'You can use the profiles to tag RGB images that have been created and viewed on a reference display or on a digital projector.'

Hast Du mal versucht zu verstehen, was das bedeutet?



Antwort von Bluboy:

Wenn Du mit einem Link nichts anfangen kannst dann lass es doch und konzentrier Dich drauf wie der TO und Andere im DCI-P3 Modus arbeiten können.



Antwort von mash_gh4:

carstenkurz hat geschrieben:
Warum Du sinnloserweise 'Systemtreiber' oder 'Systemsteuerung' erwähnst, weiss ich nicht. weil wir gerade von systemtreibern reden:

mich hat die ganze debatte wiedereinmal daran erinnert, mich umzuschauen, was aus dem ColorHug-Projekt -- diesem bereits erwähneten OpenSoft- und Hardware Farbkalibierungssensor -- geworden ist. dabei bin ich auf eine ganz tollen treiber-source-code gestoßen, den offenbar ein mitarbeiter einer bekannten bayrischen kamera-bastelbude kürzlich zum linux-kernel beigetragen hat:

"This series adds support for the AMS AS73211 digital XYZ sensor."
https://lkml.org/lkml/2020/7/28/153

dabei handelt es sich um einen I²C-treiber für einen recht interessanten farbsensor:

https://ams.com/as73211
https://www.all-electronics.de/xyz-farbsensor-ams/
https://www.mikroe.com/color-6-click

der bietet zwar leider auch nicht ganz die nötige sensel-anzahl, um iasi-kriterien abzudecken, aber zumindest auf den vieren, die er besitzt, liefert er jeweils 24bit-farbtiefe und eine ganze erstaunliche dynamik-abdeckung. im übrigen wird er direkt ab werk kalibriert ausgeliefert, ist verhältnismäßig einfach anzuschließen und kostet auch in kleinen stückzahlen gerade einmal ein paar euro. von der genauigkeit her dürfte er aberdurchaus mit den besseren fertig erhältlichen kolorimetern für den hausgebrauch mithalten können.

würde BMD so etwas mit einem USB-stecker versehen und es in ein billiges plastikgehäuse für den konsum durch die breiten masse packen, würden sie vermutlich den resolve benutzern od. zumindest deren kunden, die nicht ganz farbenblind sind, etwas deutlich nützlicheres andrehen als uns weiterhin mit dem zwang zur nutzung überflüssiger legacy ausgabekarten zu beglücken.

so werden halt offenbar studenten damit gequält, erste erfahrungen in puncto soft- und hardware-entwicklung anhand derartiger basteleien zu sammeln:

https://www.youtube.com/watch?v=xGjZrMEE2uk

aber o.k. -- das hat jetzt wirklich nichts mehr sonderlich viel mit dem hiesigen thema zu tun, aber vielleicht nutzten ja doch einige hier neben der kamera manchmal auch den lötkolben. ;)



Antwort von pillepalle:

Wie so oft, kommt immer alles auf einmal :) Nicht nur das heute das Spektrometer angekommen war, auch die Decklink ist angekommen. Karte Treiber und Software installiert. Scheint soweit alles soweit zu funktionieren. DisplayCal hat allerdings fast eine Stunde für die Kalibrierung gebraucht um seine 1519 Patches durchzumessen... Hab' auch erstmal REC709 als Target angegeben. Es gibt noch ein paar Dinge die ich noch nicht heraus bekommen habe, bzw. noch ausprobieren muss. Unter anderem wie ich die Ausgabe verändern kann :) Momentan kommt die nur 1:1 aus der Karte, egal was ich in der Mini-Monitor Software einstelle. So wird ein Hochformatvideo für Instagram auf dem Monitor oben und unten abgeschnitten, statt herunterskaliert. Vielleicht versuche ich das später noch mal über das Monitormenu selber zu ändern (Bilddrehung), um auch Hochformate darzustellen zu können. Den Monitor selber, kann ich ja auch ins Hochformat drehen.

Farbraumabdeckung sagt mir ja noch was, aber was es mit dem Farbraumvolumen auf sich hat, das die DisplayCal Software angibt, ist mir noch nicht so ganz klar. Vermutlich wieviel Farbe das Display über den jeweiligen Farbraum hinaus darstellen kann... wofür auch immer das nützlich sein soll. Da hatte die erste Kalibrierung für den Eizo folgende Werte ergeben:

Farbraumabdeckung
sRGB 99.8%
AdobeRGB 99.2%
DCI P3 95.3%

Farbraumvolumen
sRGB 174.4%
AdobeRGB 120.2%
DCI P3 123.6%

Werde die Tage jedenfalls nochmal ein paar Dinge mit der Karte ausprobieren und vielleicht auch mal eine P3 Kalibrierung testen. Mein erster Eindruck ist, verglichen mit den Hardwareprofilen des Monitors, das die Schatten minimal dunkeler sind. Ansonsten sieht das Bild dem aus der Grafikkarte sehr ähnlich. Das Monitorprofil das man mit Resolve erstellt, wird dem Monitor praktisch übergestülpt. Auf die internen Monitorprofile hat es jedenfalls keinen Einfluß. Muss morgen aber erstmal den Sekonic ausprobieren und hab' die Woche sogar ein wenig zu tun :) Kann also ein paar Tage dauern bis ich alles ausprobiert habe.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
Software einstelle. So wird ein Hochformatvideo für Instagram auf dem Monitor oben und unten abgeschnitten, statt herunterskaliert. Vielleicht versuche ich das später noch mal über das Monitormenu selber zu ändern, um auch Hochformate darzustellen zu können. Viel Glück... Was mich am meisten an der Decklink-Lösung nervte, ist, dass die hardwaremäßig ausgebbare (und vom Monitor ebenfalls hardwaremäßig) unterstützte Framerate automatisch auch die Abspielframerate des aktuellen Schnittprojekts ist.

Wenn man also z.B. eine 24p-Timeline hat und der an die Decklink angeschlossene Monitor nur 25p unterstützt, kann man im Schnitt nur 25p abspielen, dann mit Verschnellung der Timeline und Frequenzverschiebung der Audiowiedergabe.

Aber mit einem Eizo dürften das ja weniger ein Problem sein.



Antwort von pillepalle:

Danke für die Info. Hatte ich noch gar nicht drauf geachtet. Mit dem Monitor konnte ich jedenfalls unterschiedliche Frameraten darstellen. Genauso wie RGB oder YCrCb was die Karte ausgeben kann.

Ja, eigentlich ist das Arbeiten über die Karte eher ein Nachteil für mich. Auch was die Bedienung angeht. Deshalb will ich damit auch verschiedene Einstellungen durchspielen und ausprobieren um zu sehen wie groß die Unterschiede tatsächlich sind.

VG



Antwort von rdcl:

cantsin hat geschrieben:
pillepalle hat geschrieben:
Software einstelle. So wird ein Hochformatvideo für Instagram auf dem Monitor oben und unten abgeschnitten, statt herunterskaliert. Vielleicht versuche ich das später noch mal über das Monitormenu selber zu ändern, um auch Hochformate darzustellen zu können. Viel Glück... Was mich am meisten an der Decklink-Lösung nervte, ist, dass die hardwaremäßig ausgebbare (und vom Monitor ebenfalls hardwaremäßig) unterstützte Framerate automatisch auch die Abspielframerate des aktuellen Schnittprojekts ist.

Wenn man also z.B. eine 24p-Timeline hat und der an die Decklink angeschlossene Monitor nur 25p unterstützt, kann man im Schnitt nur 25p abspielen, dann mit Verschnellung der Timeline und Frequenzverschiebung der Audiowiedergabe.

Aber mit einem Eizo dürften das ja weniger ein Problem sein. Das klingt aber nicht nach normalem Verhalten von Resolve. Habe ich auch noch nie so von jemandem gehört. Was ist denn wenn du dann das FSP deaktivierst, wird die Timeline dann wieder in 24p abgespielt?



Antwort von mash_gh4:

pillepalle hat geschrieben:
Wie so oft, kommt immer alles auf einmal :) Nicht nur das heute das Spektrometer angekommen war, auch die Decklink ist angekommen. Karte Treiber und Software installiert. Scheint soweit alles soweit zu funktionieren. das klingt ja super!

wäre wirklich dein, wenn du uns ein bisserl was über deine auseinandersetzung damit berichten könntest, weil ja leider viel zu wenig wirklich gute infos über diese geschichten ausgetauscht werden.

ich persönlich beschäftige mich mit diesen sachen ja meist auch nur intensiver, wenn es wirklich wieder neues equipment einzurichten und auszutesten gilt, vergiss es dann aber auch schnell wieder und hab natürlich sonst auch immer hundert andere dinge zu tun, die dafür nicht genug aufmerksamkeit über lassen...
pillepalle hat geschrieben:
DisplayCal hat allerdings fast eine Stunde für die Kalibrierung gebraucht um seine 1519 Patches durchzumessen... das dauert oft noch deutlich länger, wenn man gute resultate mit wenig rauschen in den dunklen bereichen, also langem samplen, erhalten will. m besten mann lässt es einfach in der nacht im dunklen raum duchlaufen.
pillepalle hat geschrieben:
Es gibt noch ein paar Dinge die ich noch nicht heraus bekommen habe, bzw. noch ausprobieren muss. Unter anderem wie ich die Ausgabe verändern kann :) Momentan kommt die nur 1:1 aus der Karte, egal was ich in der Mini-Monitor Software einstelle. So wird ein Hochformatvideo für Instagram auf dem Monitor oben und unten abgeschnitten, statt herunterskaliert. ja -- leider! -- besonders flexibel ist diese art der ausgabe leider wirklich nicht...
pillepalle hat geschrieben:
Farbraumabdeckung sagt mir ja noch was, aber was es mit dem Farbraumvolumen auf sich hat, das die DisplayCal Software angibt, ist mir noch nicht so ganz klar. Vermutlich wieviel Farbe das Display über den jeweiligen Farbraum hinaus darstellen kann... wofür auch immer das nützlich sein soll. Da hatte die erste Kalibrierung für den Eizo folgende Werte ergeben:

Farbraumabdeckung
sRGB 99.8%
AdobeRGB 99.2%
DCI P3 95.3%

Farbraumvolumen
sRGB 174.4%
AdobeRGB 120.2%
DCI P3 123.6% ich hoff, ich plapper da jetzt keinen blödsinn, aber ich denke, es hat tatsächlich mit dem "volumen" der abgedeckten farbwerte zu tun.

wir sind es zwar alle gewohnt, bei farmesswerten sofort an diese zweidimensionale CIE diagramme, die eingezeichneten dreiecke für die primaries u.ä. zu denken, aber in wahrheit sind das nur vereinfachende darstellunmgen, die den unterschiedlichen verlauf über die helligkeit hinweg ausklammern. wenn man ein korrekteres bild der abdeckung bzw. der darstellungsmöglichkeiten erhalten will, muss man das zumindests in einer räumliche gestalt visualisieren bzw. beschreiben.
pillepalle hat geschrieben:
Werde die Tage jedenfalls nochmal ein paar Dinge mit der Karte ausprobieren und vielleicht auch mal eine P3 Kalibrierung testen. Mein erster Eindruck ist, verglichen mit den Hardwareprofilen des Monitors, das die Schatten minimal dunkeler sind. Ansonsten sieht das Bild dem aus der Grafikkarte sehr ähnlich. besitzt dein monitor so etwas ähnliches wie bei den flanders, wo man tatsächlich messungen bzw. pixelwerte, so wie sie der monitor empfängt, einblenden und überprüfen kann?

ich besitze leider auch keine luxusapparate, die das können, aber eigentlich wäre das die vernünftigste vergleichsmethode, um tatsächlich ein gewissenhaftes urteil in dieser frage zu fällen.
pillepalle hat geschrieben:
Das Monitorprofil das man mit Resolve erstellt, wird dem Monitor praktisch übergestülpt. Auf die internen Monitorprofile hat es jedenfalls keinen Einfluß. Muss morgen aber erstmal den Sekonic ausprobieren und hab' die Woche sogar ein wenig zu tun :) Kann also ein paar Tage dauern bis ich alles ausprobiert habe. wie gesagt -- ich würde mich sehr freuen, wenn du uns an deinem forschungs- und perfektionierungsdrang teilhaben lassen könntest. :)



Antwort von pillepalle:

@ mash_gh4

Der Monitor zeigt über das Monitormenu an, was für Signale er gerade in welcher Farbtiefe (Color Subsampling) über welchen Eingang empfängt und in welcher Frequenz. Teilweise sind das aber bei den Frequenzen recht krumme Werte (also z.B. keine 24Hz glatt). Da ist mir noch nicht klar ob das am Monitor liegt, oder von der Karte kommt.

Klar werde ich darüber berichten. Ist für mich ja auch ein wenig 'Jugend forscht' :) Am meisten freue ich mich aber auf das Treffen mit Carsten um mal eine Referenz zu einer echten Kinoprojektion zu bekommen. Da bin ich schon gespannt wie ein Flitzebogen... vorher will ich aber noch ein paar Dinge testen, Profile speichern und passendes Footage raussuchen oder drehen.

VG



Antwort von mash_gh4:

cantsin hat geschrieben:
Viel Glück... Was mich am meisten an der Decklink-Lösung nervte, ist, dass die hardwaremäßig ausgebbare (und vom Monitor ebenfalls hardwaremäßig) unterstützte Framerate automatisch auch die Abspielframerate des aktuellen Schnittprojekts ist.

Wenn man also z.B. eine 24p-Timeline hat und der an die Decklink angeschlossene Monitor nur 25p unterstützt, kann man im Schnitt nur 25p abspielen, dann mit Verschnellung der Timeline und Frequenzverschiebung der Audiowiedergabe. das klingt zwar natürlich auf den ersten blick ganz wirld, aber im grunde gibt's dieses problem im zusammenhang mit der videodarstellung dauernd. selbst in einfacheren playern wird oft die zeitbasis der audioausgabe herangezogen, um das bild synchron auszugeben.

und von den diesbezüglichen eigenheiten in den wirklich wilden tradionellen workstation-lösungen, wie dem autodesk flame, wo mit beim konfigurien und starten eines projkets gleich die ganze Xorg-konfiguration umgestellt wird -- das stammt halt noch aus zeiten vor KMS/DRM --, hab ich ja ohnehin bereits erzählt.

zum glück ist vieles davon mittlerweile wirklich wesentlich einfacher geworden, obwohl das natürlich auch nicht unbedingt immer zu hochwertigerer qualität od. erfüllung professioneller qualitätsansprüche und -vorstellungen harmoniert.



Antwort von mash_gh4:

pillepalle hat geschrieben:
Der Monitor zeigt über das Monitormenu an, was für Signale er gerade in welcher Farbtiefe (Color Subsampling) über welchen Eingang empfängt und in welcher Frequenz. Teilweise sind das aber bei den Frequenzen recht krumme Werte (also z.B. keine 24Hz glatt). Da ist mir noch nicht klar ob das am Monitor liegt, oder von der Karte kommt. nein -- das bekommen ich natürlich auf meinen schirmen auch angezeigt, aber die bessere studio-geräte bieten in dieser hinsicht auch noch jede menge zusätzliche monitoring features...

bspw. bei FSI geräten:

Measurement (8 & 10bit):

zum Bild


CIE Measurement:

zum Bild


Video Data Analyzer:

zum Bild


das geht sogar so weit, dass du die messwerte aus dem monitor übers netz vom technik-laptop aus auslesen und analysieren kannst:

https://flandersscientific.com/news/ind ... cle=062617

zum Bild



hätte ich natürlich auch alles gern! -- aber dafür sind meine schirme halt auch ein bisserl günstiger. ;)



Antwort von pillepalle:

@ mash_gh4

Nee, so genau zeigt der das leider nicht an. Ein Flanders ist natürlich nochmal was anderes. Mir reicht es schon, wenn das was ich sehe halbwegs stimmt :)

VG



Antwort von mash_gh4:

pillepalle hat geschrieben:
Mir reicht es schon, wenn das was ich sehe halbwegs stimmt :) versteh ich gut! -- damit begnüge ich mich natürlich auch...



Antwort von cantsin:

rdcl hat geschrieben:
cantsin hat geschrieben:


Viel Glück... Was mich am meisten an der Decklink-Lösung nervte, ist, dass die hardwaremäßig ausgebbare (und vom Monitor ebenfalls hardwaremäßig) unterstützte Framerate automatisch auch die Abspielframerate des aktuellen Schnittprojekts ist.

Wenn man also z.B. eine 24p-Timeline hat und der an die Decklink angeschlossene Monitor nur 25p unterstützt, kann man im Schnitt nur 25p abspielen, dann mit Verschnellung der Timeline und Frequenzverschiebung der Audiowiedergabe.

Aber mit einem Eizo dürften das ja weniger ein Problem sein. Das klingt aber nicht nach normalem Verhalten von Resolve. Habe ich auch noch nie so von jemandem gehört. Was ist denn wenn du dann das FSP deaktivierst, wird die Timeline dann wieder in 24p abgespielt? Die Decklink gibt an den externen Monitor genau die Framerate 'raus, die in Resolves Projekteinstellungen als "Playback Framerate" eingestellt ist - im Gegensatz zu einer klassischen PC-Grafikkarte, die natürlich unabhängig von den Videoprojekteinstellungen i.d.R. ein 60Hz-Signal an den Computermonitor schickt.

Eigentlich ist dieses Verhalten der Decklink ja auch ein Feature, und kein Bug. Probleme gibt es eben nur, wenn man einen Monitor an die Decklink 'dranhängt (wie z.B. den preiswerten BenQ mit eingebauter Rec709-Kalibrierung, mit dem ich es versucht habe), der die Playback-Framerate hardwaremäßig nicht unterstützt, sondern z.B. nur 50 und 60Hz - aber nicht 23.97 oder 24p, und 25p nur als 50i.

Wenn man in Resolve die Playback-Framerate ändert, wirkt sich das in der Tat auf die gesamte Schnittvorschau aus, und ein 24p-Projekt wird dann eben immer in 25p abgespielt - oder, falls man auf 30p geht - sogar auf 125% beschleunigt...



Antwort von mash_gh4:

cantsin hat geschrieben:
Die Decklink gibt an den externen Monitor genau die Framerate 'raus, die in Resolves Projekteinstellungen als "Playback Framerate" eingestellt ist - im Gegensatz zu einer klassischen PC-Grafikkarte, die natürlich unabhängig von den Videoprojekteinstellungen i.d.R. ein 60Hz-Signal an den Computermonitor schickt.

Eigentlich ist dieses Verhalten der Decklink ja auch ein Feature, und kein Bug. Probleme gibt es eben nur, wenn man einen Monitor an die Decklink 'dranhängt (wie z.B. den preiswerten BenQ mit eingebauter Rec709-Kalibrierung, mit dem ich es versucht habe), der die Playback-Framerate hardwaremäßig nicht unterstützt, sondern z.B. nur 25, 30, 50 und 60Hz, und nicht 23.97 oder 24p. ich könnte mir auch gut vorstellen, dass dieses verhalten auch mit der sehr eingeschränkten DDC unterstützung der decklink-karten zu tun hat.

normale viedeokarten setzte ja heute nicht einfach ihre einstellungen ohne rücksicht auf die fähigkeiten des angeschlossenen monitors durch, sondern handeln in bidirektionaler weise die geeignetste übertragungseinstellung aus. im studio-umfeld bzw. dem ursprünglichen einsatzgebeit derartiger ausgabekarten macht das aber natürlich wenig sinn. deshalb ist diese funktionalität bei den decklinks auch nur in sehr spärlichem maße verfügbar.



Antwort von carstenkurz:

Nee, das ist doch gerade der Witz bei den Decklinks, dass man die Bildrate der Ausgabe auf die Projektbildrate zwingen kann.


Wer das anders will, nimmt halt den Grafikkartenausgang.



Antwort von klusterdegenerierung:

Cantsin, mal blöd gefragt, aber das 10 Bit Bild aus einer Intensity Pro sieht auf einem 8Bit Moni genauso aus wie aus einer Geforce, oder?



Antwort von mash_gh4:

naja -- "erzwingen" kann man viel, aber in vielen fällen ist es durchaus wünschenswert, wenn die lösungen den praktischen gegebenheiten möglichst gut gerecht werden und eben auch tatsächlich funktionieren bzw. nicht jene probleme zeigen, die cantsin beschrieben hat.

ganz einfach ist das nicht -- ich würde sogar behaupten: es ist eine wesentlich anspruchsvoller aufgabe, als nur korrekte farben bzw. die richtigen werte auszugeben --, aber es gibt durchaus auch dafür einigermaßen brauchbare lösungen, um zumindest ein einigermaßen passables arbeiten zu ermöglichen.

https://github.com/mpv-player/mpv/wiki/ ... ronization
https://github.com/mpv-player/mpv/wiki/Interpolation

die grafikkarten und übertrageungsprotokolle bieten ohnehin auch in dieser hinsicht ständig neue möglichkeiten, feinheiten der tatsächlichen ausgabe noch ein wenig bisserl komplizierter od. eben anspruchsvoller zu gestalten.

erst heute ist z.b. linuxseitig die unterstützung für die ausgabe mit flexiblen frameraten auf AMD GPUs eingebracht worden -- etwas was mit nvidia-hardware schon länger möglich ist.

versuch so etwas -- auch wenn wir hoffentlich alle noch länger von variablen frameraten im ernsthafteren videoproduktionsalltag verschont bleiben mögem und derartiges höchstens in ausnahmefällen zur kompensation von sync-problemen und verzögerungen in den renderprozessen für unsere zwecke tatsächlich sinn machen könnte -- einmal einer decklink-karte beizubringen. ;)



Antwort von mash_gh4:

klusterdegenerierung hat geschrieben:
Cantsin, mal blöd gefragt, aber das 10 Bit Bild aus einer Intensity Pro sieht auf einem 8Bit Moni genauso aus wie aus einer Geforce, oder? das ist seltsamerweise einer der wenigen fälle, wo das bild im falle der nvidia-karte tatsächlich spürbar besser ausfallen "könnte" als mit der decklink-karte.

die nvidia-karte ist nämlich in der lage, wenn via OpenGL ein 10bit texture zur ausgabe übergeben wird, aber nur ein 8bit monitor dran hängt, die anzeige zu dithern. d.h. man sieht auch in der faktischen 8bit darstellung nicht mehr banding als auf einem 10bit monitor bzw. gleich viele feine farbabstufungen. umgekehrt will man ja genau diese feißaufgaben der karte in manchen fällen bewusst abschalten, um die darstellung besser kontrollieren zu können bzw. dadurch verursachte änderungen generell zu verhindern -- deshalb unterbleibt dieses dithering auch im oben bereits verlinkten "color accuracy mode".

trotzdem kann man hier ohnehin nur von einem "könnte" sprechen, weil ja BMD nicht im traum daran denkt, 10bit ausgabe unter windows od linux über die grafikkarten zuzulassen. das ist meines wissens nach weiterhin nur am mac möglich.



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
Cantsin, mal blöd gefragt, aber das 10 Bit Bild aus einer Intensity Pro sieht auf einem 8Bit Moni genauso aus wie aus einer Geforce, oder? Der BenQ, den ich an die Decklink angeschlossen hatte, ist zwar preiswert, aber immerhin ein Pseudo-10bit (8bit+FRC)-Monitor.



Antwort von rdcl:

cantsin hat geschrieben:
rdcl hat geschrieben:


Das klingt aber nicht nach normalem Verhalten von Resolve. Habe ich auch noch nie so von jemandem gehört. Was ist denn wenn du dann das FSP deaktivierst, wird die Timeline dann wieder in 24p abgespielt? Die Decklink gibt an den externen Monitor genau die Framerate 'raus, die in Resolves Projekteinstellungen als "Playback Framerate" eingestellt ist - im Gegensatz zu einer klassischen PC-Grafikkarte, die natürlich unabhängig von den Videoprojekteinstellungen i.d.R. ein 60Hz-Signal an den Computermonitor schickt.

Eigentlich ist dieses Verhalten der Decklink ja auch ein Feature, und kein Bug. Probleme gibt es eben nur, wenn man einen Monitor an die Decklink 'dranhängt (wie z.B. den preiswerten BenQ mit eingebauter Rec709-Kalibrierung, mit dem ich es versucht habe), der die Playback-Framerate hardwaremäßig nicht unterstützt, sondern z.B. nur 50 und 60Hz - aber nicht 23.97 oder 24p, und 25p nur als 50i.

Wenn man in Resolve die Playback-Framerate ändert, wirkt sich das in der Tat auf die gesamte Schnittvorschau aus, und ein 24p-Projekt wird dann eben immer in 25p abgespielt - oder, falls man auf 30p geht - sogar auf 125% beschleunigt... Ja, das hab ich schon verstanden. Mein Monitor hängt ja auch an einer Intensität. Ich dachte aber, dass bei nicht supporteten Frameraten oder Auflösungen einfach gar kein Bild ausgegeben wird. Für Auflösungen ist das bei der Intensity meine ich auch so, bei Frameraten kann ich es nicht sagen. Mein LG unterstützt auch 24fps
Es erscheint mir auch recht sinnfrei. Was wäre denn bei einer 60fps Timeline wenn der Monitor das nicht unterstützt? Läuft das dann auch einfach in 25p? Wie soll man so denn arbeiten?
Oder hast du das manuell auf 25p umgestellt?



Antwort von cantsin:

rdcl hat geschrieben:
Ja, das hab ich schon verstanden. Mein Monitor hängt ja auch an einer Intensität. Ich dachte aber, dass bei nicht supporteten Frameraten oder Auflösungen einfach gar kein Bild ausgegeben wird. Ja, und wenn man in diese Lage kommt, muss man sich eben mit Workarounds helfen, wie z.B. ein 24p-Projekt via Decklink auf dem externen Monitor in 50i ausgeben, bei 25p Playback.

Es gibt in Resolve keine Möglichkeit, die Decklink-Karte so anzusteuern wie die normale Grafikkarte, also z.B. ein 24p-Projekt via Decklink an den Monitor in 60p auszugeben (ohne die Playbackgeschwindigkeit zu verändern).

Das sollte nur jedem klar sein, der mit der Decklink-Lösung liebäugelt. Die funktioniert nur gut im Monitoren, die die benötigten Frameraten hardwareseitig unterstützen.



Antwort von klusterdegenerierung:

cantsin hat geschrieben:
klusterdegenerierung hat geschrieben:
Cantsin, mal blöd gefragt, aber das 10 Bit Bild aus einer Intensity Pro sieht auf einem 8Bit Moni genauso aus wie aus einer Geforce, oder? Der BenQ, den ich an die Decklink angeschlossen hatte, ist zwar preiswert, aber immerhin ein Pseudo-10bit (8bit+FRC)-Monitor. Ist zwar nett zu wissen, aber keine Antwort auf meine Frage. ;-)



Antwort von cantsin:

klusterdegenerierung hat geschrieben:
cantsin hat geschrieben:


Der BenQ, den ich an die Decklink angeschlossen hatte, ist zwar preiswert, aber immerhin ein Pseudo-10bit (8bit+FRC)-Monitor. Ist zwar nett zu wissen, aber keine Antwort auf meine Frage. ;-) Naja, der Benq ist kein reiner 8bit-Monitor, durch die FRC-10bit gibt's zumindest keine Dithering-Nachteile ggü. einem 8bit-Monitor an einer Decklink.

Ansonsten: Der BenQ im Rec709-Modus lieferte klar ein anderes Bild/andere Farben als an der regulären Grafikkarte (RTX1080i) in sRGB, wobei das Bild/die Farben an der Decklink - wie zu erwarten - eher mit dem Bild übereinkam, das ich beim Abspielen auf meinem Flatscreen-TV erhielt, während das RTX-sRGB-Bild sich mit dem von Online-Video im Webbrowser deckte.

Bin mittlerweile dabei gelandet, dass Webvideo mein primäres Zielvideo ist und ein mit DisplayCal kalibrierter sRGB-Monitor daher meinen Ansprüchen genügt. Zumal ich so in der Resolve-GUI-Ansicht, beim Abspielen der rausgerenderten Videos mit mpv sowie beim letztlichen Abspielen der Videos von Vimeo und YouTube im Webbrowser zufriedenstellend konsistente Farben kriege.

(Während das in früheren Zeiten, mit dem alten FCP7 und seinem Gamma-Shift, {b} den Problemen, die diverse NLEs mit den Full-/Legal- und Halb-Full-Halb-Legal-RGB-Werten hatten, sowie den früheren Resolve-Versionen beinahe ein Heulkrampf war.)



Antwort von klusterdegenerierung:

Hm, ok, trifft auch nicht meine Frage, weil ich nicht von Deinem 8+ Moni sprach, sondern generell von 8Bit Monitoren.
Bei mir sieht übrigens das Bild der Intensity genauso aus wie das der GTX, zumal man bei der BMD ja auch keinen Unterschied zu Rec oder RGB machen kann und wenn ich am Moni ein Rec Profil laden würde, sähe das natürlich anders zu RGB aus, aber auch da dann gleich wie bei der Intensity.



Antwort von rdcl:

cantsin hat geschrieben:
rdcl hat geschrieben:
Ja, das hab ich schon verstanden. Mein Monitor hängt ja auch an einer Intensität. Ich dachte aber, dass bei nicht supporteten Frameraten oder Auflösungen einfach gar kein Bild ausgegeben wird. Ja, und wenn man in diese Lage kommt, muss man sich eben mit Workarounds helfen, wie z.B. ein 24p-Projekt via Decklink auf dem externen Monitor in 50i ausgeben, bei 25p Playback.

Es gibt in Resolve keine Möglichkeit, die Decklink-Karte so anzusteuern wie die normale Grafikkarte, also z.B. ein 24p-Projekt via Decklink an den Monitor in 60p auszugeben (ohne die Playbackgeschwindigkeit zu verändern).

Das sollte nur jedem klar sein, der mit der Decklink-Lösung liebäugelt. Die funktioniert nur gut im Monitoren, die die benötigten Frameraten hardwareseitig unterstützen. Also hast du das Playback dann manuell auf 25p umgestellt?

Ich hatte das anfangs so verstanden, als hätte Resolve dann automatisch auf 25p gewechselt, und das hätte mich gewundert.
Das war wohl das Missverständnis.



Antwort von cantsin:

rdcl hat geschrieben:
Also hast du das Playback dann manuell auf 25p umgestellt? Ja.

(Das kann man auch in den Resolve-Projekteinstellungen machen und trotzdem die Timeline auf 24p lassen. Dann wird zwar innerhalb von Resolve das Material auf 104% beschleunigt und gepitcht abgespielt, aber intern als 24p gerechnet und auch als 24p ohne Beschleunigung rausgerendert.)



Antwort von carstenkurz:

cantsin hat geschrieben:
Das sollte nur jedem klar sein, der mit der Decklink-Lösung liebäugelt. Die funktioniert nur gut im Monitoren, die die benötigten Frameraten hardwareseitig unterstützen. Das ist doch eine komplett verquere Argumentation.

Warum sollte man eine Decklink überhaupt in Betracht ziehen, wenn man keinen Monitor hat, der die benötigten Bildraten unterstützt (was ja nun heutzutage ohnehin kein wirkliches Problem mehr ist)?

Wem es egal ist, ob die Projekt-/Timelinebildrate mit der Bildrate der Ausgabekarte übereinstimmt, dem geht eine Decklink was den Anspruch an formatkonforme Wiedergabe angeht doch grade am Arsch vorbei. Der findet an seiner GPU-Karte gleich mehrere Anschlüsse, die seine nicht vorhandenen Ansprüche besser erfüllen.



Antwort von cantsin:

carstenkurz hat geschrieben:
cantsin hat geschrieben:
Das sollte nur jedem klar sein, der mit der Decklink-Lösung liebäugelt. Die funktioniert nur gut im Monitoren, die die benötigten Frameraten hardwareseitig unterstützen. Das ist doch eine komplett verquere Argumentation. Na, warum gleich in die Luft gehen...

Weil man bei preiswerteren Monitoren wie den BenQs leider erst beim Ausprobieren feststellt, dass sie nur 50 und 60Hz unterstützen (und das nirgendwo dokumentiert ist, obwohl die Monitore mit von Dolby kalibriertem Rec709-Modus ausgeliefert werden).

Dann zieht man halt die A*schkarte. Unterhalb der Preis-/Leistungsklasse Eizo ist die Decklink-Lösung daher nicht zu empfehlen.



Antwort von mash_gh4:

carstenkurz hat geschrieben:
cantsin hat geschrieben:
Das sollte nur jedem klar sein, der mit der Decklink-Lösung liebäugelt. Die funktioniert nur gut im Monitoren, die die benötigten Frameraten hardwareseitig unterstützen. Das ist doch eine komplett verquere Argumentation.
ich finde die betreffenden anmerkungen vom cantsin keineswegs verquert, sondern vielmehr ausgesprochen realistisch und wichtig. ich fürchte, dass er damit recht gut zum ausdruck bringt, wie es dem großteil der heutigen resolve-nutzer ergeht.
carstenkurz hat geschrieben:
Wem es egal ist, ob die Projekt-/Timelinebildrate mit der Bildrate der Ausgabekarte übereinstimmt, dem geht eine Decklink was den Anspruch an formatkonforme Wiedergabe angeht doch grade am Arsch vorbei. Der findet an seiner GPU-Karte gleich mehrere Anschlüsse, die seine nicht vorhandenen Ansprüche besser erfüllen. im prinzip würde ich dir da natürlich zustimmen, gäbe es nicht das problem, dass einem diese entscheidung durch die gegenständliche software nicht unbedingt leicht gemacht wird.

ein "clean feed" über die GPU, der praktisch gar keine vernünftigen anpassungen zulässt, und auch sonst in seinen features ausgesprochen unbefreidigend und stiefmütterlich behandelt wirkt, ist zum heutigen zeitpunkt wirklich nur mehr als zumutung zu begreifen.

für einen großteil der gegenwärtigen und zukünftigen resolve-nutzer würden diesbezügliche verbesserungen vermutlich mehr bringen als die anschaffung von spezialhardware, die sich nicht ohne weiters in einen gebräuchlichen computer- und desktop-video-arbeitsplatz fügt.

das es daneben natürlich auch weiterhin anwendungsszenarien und anforderungen gibt, wo sich das völlig anders darstellt, ist uns ohnehin allen klar.



Antwort von mash_gh4:

cantsin hat geschrieben:
Weil man bei preiswerteren Monitoren wie den BenQs leider erst beim Ausprobieren feststellt, dass sie nur 50 und 60Hz unterstützen (und das nirgendwo dokumentiert ist, obwohl die Monitore mit von Dolby kalibriertem Rec709-Modus ausgeliefert werden). ich hab im letzten jahr im büro auch auf einem derartigen BenQ gearbeite, der zwar erstaunlich gute farben angezeigt hat, aber in puncto frequenzanpassung und tearing leider wirklich ein extrem problematisches verhalten an den tag gelegt hat, wie ich es ursprünglich auch nicht erwartet hätte.

ansonsten arbeite ich ziemlich viel mit dell-monitoren, die fast genauso günstig sind, aber sich zumindest bisher in diesem punkt immer als deutlich gutmütiger und empfehlenswerter erwiesen haben.

ein eizo steht übrigens auch noch hier am tisch, weil ihn mir vor kurzem ein befreundeter grafiker geschenkt hat, nachdem er damit überhaupt nicht klar gekommen ist und mit den händler monate lange gestritten hat, bis er das ding wirklich nicht mehr sehen konnte.
ja -- ist natürlich nett, so etwas nun auch wieder am schreibtisch stehen zu haben, aber so aufregend gut, wie man das gerne mit dieser marke verbindet, ist er dann leider in wahrheit auch wieder nicht...



Antwort von carstenkurz:

cantsin hat geschrieben:
Weil man bei preiswerteren Monitoren wie den BenQs leider erst beim Ausprobieren feststellt, dass sie nur 50 und 60Hz unterstützen (und das nirgendwo dokumentiert ist, obwohl die Monitore mit von Dolby kalibriertem Rec709-Modus ausgeliefert werden).
Wieso hängt man einen 'preiswerten' Monitor an eine Decklink? rec.709 Monitore, die 24/23,98 unterstützen gibt es mittlerweile wie Sand am mehr. Warum sollte sich jemand für eine Decklink entscheiden, der über diesen Aspekt nicht Bescheid weiss? Es gibt im Übrigen massenweise Anwendungen innerhalb und ausserhalb von Resolve, bei denen ein preiswerter 'Monitor' am Ausgang gar keine Rolle spielt. Live-Grading, Keying, HDR-Workflows, formatkonformes Liveplayout. Von den Varianten mit Capture-Optionen ganz zu schweigen. Wer sich damit beschäftigt wird wohl die 150-250€ übrig haben. Wer nicht, halt nicht. Ohne solche von Resolve unterstützten Karten ist Resolve im professionellen Bereich garnicht verkäuflich, da ist HDMI oder DP gar keine Größe.



Antwort von pillepalle:

Was ich bisher festgestellt habe, ist das die eingestellte Monitor LUT auch die gleiche ist die auf die Timeline-Ansicht und die Fullscreen Ansicht (P) in Resolve angewendet wird. Ich hatte vorhin mal als dritten Monitor (den ich dann quasi als Video-Monitor über die Decklink verwendet habe) einen smallHD Focus angeschlossen. Den bekommt man zwar recht gut kalibriert, aber bezüglich der Farbraumabdeckung kann er nicht so ganz mithalten (78%sRGB und 54.6%AdobeRGB). Der hat natürlich als Kameramonitor auch ursprünglich einen anderen Zweck, war aber zumindest mal einen Versuch Wert ihn ausprobiert zu haben.

Und klar, die Decklink-Karte gibt immer die Bildwiederholfrequenz der Timeline aus. Man kann an der Decklink-Karte eben nur wenig einstellen. Einmal die Auflösung (HD, 1080, oder UHD) und die Bildwiederholrate. Wobei ich letztere Einstelloption nicht so ganz verstehe, denn am Ende ist egal was ich in der Decklink-Software einstelle, der Monitor läuft ohnehin immer nach der Framerate der Timeline. Also auch wenn ich den HDMI Ausgang mit 1080 und 50Hz Einstelle, ist das Signal was ausgegeben wird 23.98Hz, wenn ich z.B. 24fps in der Timeline eingestellt habe. Warum die Frequenzen so krum sind, habe ich auch noch nicht verstanden. Lag vielleicht am verwendeten Material, das ursprünglich mit 25fps gedreht wurde und ich in die Timeline gezogen habe. Bin mir auch gar nicht sicher, ob meine Kamera überhaupt wirklich 24fps machen kann, oder nicht mit 23.98fps filmt. Muss ich nochmal im Handbuch nachlesen ob das geht :)

VG

PS: Tatsächlich :) In 25,50 und 100 fps filmt sie glatte Werte. In 24,30,60 und 120 fps krumme.



Antwort von rdcl:

pillepalle hat geschrieben:
Was ich bisher festgestellt habe, ist das die eingestellte Monitor LUT auch die gleiche ist die auf die Timeline-Ansicht und die Fullscreen Ansicht (P) in Resolve angewendet wird. Standardmäßig wird das Video Monitor LUT auch auf den Color Viewer angewendet. Man kann in den Settings aber auch verschiedene LUTs dafür auswählen, oder wahlweise auch gar kein LUT für jeden Viewer separat auswählen. Ein Bild von den Settings hatte ich hier im Thread schonmal gepostet.



Antwort von rdcl:

Dann zieht man halt die A*schkarte. Unterhalb der Preis-/Leistungsklasse Eizo ist die Decklink-Lösung daher nicht zu empfehlen. Das kann man so jetzt nicht sagen. Einen LG der 24p unterstützt bekommt man in UHD für um die 1.000€, während der 4K Eizo fast 4.500€ kostet.

Und ich weiß nicht welchen BenQ du hast, aber die Serie für Videoanwendungen ist die PV-Serie. Die unterstützt laut BenQ auch 24p, aber kein 23.97. Offiziell unterstützen die auch keine 25p sondern nur 50i. Damit dürfte 25p aber trotzdem abgespielt werden.
Keine Ahnung was sich BenQ dabei gedacht hat. Hier ist ein kurzer Post dazu, allerdings auch schon 5 Jahre alt:
https://www.google.com/amp/s/www.provid ... -benq/amp/



Antwort von dienstag_01:

Bei Avid ist es mit Monitoring Card übrigens genau so, wenn die Bildfrequenz nicht unterstützt wird, kommt da kein Bild raus. Das handelt die Hardware (Monitoring Card - Monitor) unter sich aus.

Ansonsten müsste die Decklink das Signal ja irgendwie normwandeln.



Antwort von pillepalle:

@ rdcl

OMG... Der Tipp war super! :) Ich dachte mir: 'Was meint der mit einer Color Viewer LUT?", bis mir auffiel das damit die Timeline-Ansicht auf der Color Page gemeint ist und auch die des Cinema Viewers (P). Auf allen anderen Seiten (Edit, Render, ect), wird diese LUT nicht angewand. Man hat also auf der Color Page die Option eine individuelle Bildschirm-Ansicht für die Timeline einzustellen. Bisher hatte ich die Einstellung so:


zum Bild


und jedesmal wenn ich die Video Monitor-LUT geändert habe, hat sich nicht nur die Ansicht des Preview-Monitors über die Karte geändert, sondern auch die der Timeline und im Cinema Viewer. Wenn ich dem Color Viewer eine eigene LUT zuordne, dann habe ich zumindest auf der Color Page eine andere Ansicht. D.h. aber doch, wenn ich auf den Color Viewer keine LUT anwende, dann verwendet er das Hardware-Profil des Monitors auf der Color-Page.

VG



Antwort von AndySeeon:

Ich habe seit ca. 10 Jahren den i1Display Pro und habe den auch regelmäßig für meine Monitorkalibration verwendet. Leider ist die damals dafür von BasicColor gelieferte Software etwas in die Jahre gekommen und so ist die Kalibrierung und Profilierung die letzten 2 Jahre etwas hinten runter gefallen.

Deshalb habe ich den Tipp mit DisplayCal hier aus dem Thread mit großem Interesse aufgenommen und die Software installiert. Dazu habe ich noch eine super Anleitung in Deutsch gefunden:

https://roha-arts.de/2020/02/04/monitor ... -argyllcms

An dieser Stelle möchte ich allen einen Dank für ihre Tipps und Informationen zu diesem Thema sagen!

Gruß, Andreas



Antwort von cantsin:

AndySeeon hat geschrieben:
Ich habe seit ca. 10 Jahren den i1Display Pro Dann musst Du allerdings auch berücksichtigen, dass das Messgerät gealtert ist bzw. nicht mehr zuverlässig misst. Normalerweise wird empfohlen, es nach drei Jahren zu ersetzen - wobei für den i1 sieben Jahre spezifiziert werden:

https://imagescience.com.au/knowledge/m ... -longevity



Antwort von carstenkurz:

Von 'spezifiziert' ist da nirgendwo die Rede:

'The way we normally explain it is that dichroic filters are really more like glass prisms - the light filtering behaviour does not effectively change over time like printed organic (gel) filters used in other calibrators. This means you can take measurements with the oldest i1Display Pro (from circa 2012!) - and compare them to measurements from one made today (2019 at time of writing) - and they will behave effectively identically. If you do the same with any Spyder across a three year period, you will find significant measurable difference.

For this reason alone, the i1 Display Pro is a game changer and has a much longer effective life span... at least 7 years and counting. And this is one of the main reasons it is our primary recommended calibrator - it will simply help you achieve accuracy for a much longer period than anything other commonly available colorimeter.'

'at least 7 years and counting'. Das heisst, dass die zum Zeitpunkt der Abfassung des Artikels 7 Jahre nach Kauf noch keine signifikante Abweichung beim I1 Display Pro feststellen konnten (da er eben sehr stabile dichroitische Filter verwendet, die nicht/kaum altern). Nach 10 Jahren könnte es aber zumindest mal interessant sein, eine direkte Vergleichsmessung mit einem neuen durchzuführen.

- Carsten



Antwort von mash_gh4:

ja -- zu den jenoptics bzw. ams farb- und spektralsensoren wird in den datenblättern auch durchwegs erklärt, dass die sensoren bzw. ihre filter nicht altern und die herstellerseitge callibrierung lebenslänglich gegeben sei:

"All products feature CMOS interference filters and benefit from innovative factory calibration to deliver precise spectral characteristics over their lifetime."



Antwort von klusterdegenerierung:

Kann ich mal gerade ein Zwischenfrage stellen, warum das Bild meiner Intensity Pro 4K einen delay von mehr als einer Sec. zur GPU hat?
Danke! :-)



Antwort von Frank Glencairn:

pillepalle hat geschrieben:

Und klar, die Decklink-Karte gibt immer die Bildwiederholfrequenz der Timeline aus. Man kann an der Decklink-Karte eben nur wenig einstellen. Doch das geht, aber nicht in dem Decklink Kontrollpanel, sondern in den Voreinstellungen (Zahnrad) in Resolve, da kannst du die Monitor Framerate unabhängig vom Projekt einstellen, wenn dein Monitor das nativ nicht kann.



Antwort von AndySeeon:

Hallo Profis, kann jemand von euch eine gute Grundlagenlektüre empfehlen, wo das Thema Farbraum kompakt und auf für nichtprofessionelle Anwender verständliche Art beschrieben wird? So zum Beispiel:

welche grundsätzlichen Farbräume gibt es und wie unterscheiden sie sich?

was ist REC.709, REC.2020, ACES ... und wann und wie wende ich es an?

welchen Einfluss hat der gewählte Farbraum auf meinen Film bzw. wie wähle ich den richtigen Farbraum aus?

was brauche ich für HDR bzw. welchen Farbraum muss ich hier verwenden?

...

Bitte keine Videos, ich habe lieber Geschriebenes oder auch Gedrucktes, wo ich die Lesegeschwindigkeit dem Fortschritt meines Verstehens anpassen kann.

Und noch eine Frage zu Resolve: wann muss ich einen Clip "HDR" aktivieren? Oder andersrum: Was muss ich alles einstellen, wenn ich aus Resolve einen HDR- Film ausspielen möchte?

Dankbare Grüße,
Andreas



Antwort von Bruno Peter:

AndySeeon hat geschrieben:
Hallo Profis, kann jemand von euch eine gute Grundlagenlektüre empfehlen, wo das Thema Farbraum kompakt und auf für nichtprofessionelle Anwender verständliche Art beschrieben wird? So zum Beispiel:

welche grundsätzlichen Farbräume gibt es und wie unterscheiden sie sich?

was ist REC.709, REC.2020, ACES ... und wann und wie wende ich es an?

welchen Einfluss hat der gewählte Farbraum auf meinen Film bzw. wie wähle ich den richtigen Farbraum aus?

was brauche ich für HDR bzw. welchen Farbraum muss ich hier verwenden?

...

Bitte keine Videos, ich habe lieber Geschriebenes oder auch Gedrucktes, wo ich die Lesegeschwindigkeit dem Fortschritt meines Verstehens anpassen kann.

Und noch eine Frage zu Resolve: wann muss ich einen Clip "HDR" aktivieren? Oder andersrum: Was muss ich alles einstellen, wenn ich aus Resolve einen HDR- Film ausspielen möchte?

Dankbare Grüße,
Andreas Alle Deine Fragen kann Google beantworten, wieso soll da jemand hier Dir die Zeit dafür abnehmen?



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
pillepalle hat geschrieben:

Und klar, die Decklink-Karte gibt immer die Bildwiederholfrequenz der Timeline aus. Man kann an der Decklink-Karte eben nur wenig einstellen. Doch das geht, aber nicht in dem Decklink Kontrollpanel, sondern in den Voreinstellungen (Zahnrad) in Resolve, da kannst du die Monitor Framerate unabhängig vom Projekt einstellen, wenn dein Monitor das nativ nicht kann. Ja, aber dann wird trotzdem Dein Projekt auf der Monitorframerate abgespielt (d.h. beschleunigt oder verlangsamt).



Antwort von Frank Glencairn:

Natürlich bringt das einen Monitor nicht dazu, Frameraten darzustellen, die er hardwaremäßig gar nicht darstellen kann.
Aber wenn es der Monitor kann, dann funktioniert das einwandfrei.



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
Natürlich bringt das einen Monitor nicht dazu, Frameraten darzustellen, die er hardwaremäßig gar nicht darstellen kann.
Aber wenn es der Monitor kann, dann funktioniert das einwandfrei. Nein, ich meine etwas anderes. Wenn Du z.B. eine 24p-Timeline hast und 30p als Monitor-Framerate einstellst, wird Deine Timeline mit 125% Geschwindigkeit/Zeitraffer abgespielt.



Antwort von dienstag_01:

cantsin hat geschrieben:
"Frank Glencairn" hat geschrieben:
Natürlich bringt das einen Monitor nicht dazu, Frameraten darzustellen, die er hardwaremäßig gar nicht darstellen kann.
Aber wenn es der Monitor kann, dann funktioniert das einwandfrei. Nein, ich meine etwas anderes. Wenn Du z.B. eine 24p-Timeline hast und 30p als Monitor-Framerate einstellst, wird Deine Timeline mit 125% Geschwindigkeit/Zeitraffer abgespielt. Daran kann man deutlich sehen, wo Resolve eigentlich *her kommt* - von der Farbkorrektur. Die braucht als Minimalvoraussetzung echte Farben, aber keine Echtzeit. Zur Not also Photoshop ;)



Antwort von Frank Glencairn:

cantsin hat geschrieben:

Nein, ich meine etwas anderes. Wenn Du z.B. eine 24p-Timeline hast und 30p als Monitor-Framerate einstellst, wird Deine Timeline mit 125% Geschwindigkeit/Zeitraffer abgespielt. Ja sicher, wie soll denn sonst die Diskrepanz zwischen MaterialFPS/TimelineFPS und Monitor Frequenz dargestellt werden?
Irgendwelcher Zwischenbild/DropFrame Voodoo ist fürs Monitoring inakzeptabel, da kannst du dir das mit der I/O Karte auch gleich schenken, und über die GPU raus gehen.



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
Irgendwelcher Zwischenbild/DropFrame Voodoo ist fürs Monitoring inakzeptabel, da kannst du dir das mit der I/O Karte auch gleich schenken, und über die GPU raus gehen. Naja, es wäre ja kein Problem, da mit ganzzahligen Teilern 'rauszugehen - also z.B. 30p auf einem 60p-Monitor ohne 200% Beschleunigung auszugeben.

Und wie gesagt, man sollte sich dieser Einschränkungen bewusst sein, wenn man Monitore kauft, die Bildfrequenzen wie 23.98/24p, 25p, 29.97/30p nicht nativ unterstützen. Gefühlt 90% der Slashcam-Nachrichtenmeldungen über neue günstige Monitore, die P3 abdecken, geht über Monitore, die deshalb eigentlich nicht für Resolve taugen.

Schreibe das hier übrigens auch nicht als Beschwerde, sondern als freundliche Warnung an Mitforisten, die die Decklink + Refernzmonitorlösung erwägen.



Antwort von Frank Glencairn:

cantsin hat geschrieben:

Und wie gesagt, man sollte sich dieser Einschränkungen bewusst sein, wenn man Monitore kauft, die Bildfrequenzen wie 23.98/24p, 25p, 29.97/30p nicht nativ unterstützen. Gefühlt 90% der Slashcam-Nachrichtenmeldungen über neue günstige Monitore, die P3 abdecken, geht über Monitore, die deshalb eigentlich nicht für Resolve taugen.
Zunächst mal gibt es keinen vernünftigen Grund in 23.98 oder 29.97 zu drehen, und ja, natürlich hast du Recht, daß man sich klar sein muß, daß ein Vorschaumonitor wenigstens 24 und 25 FPS können muß.

Die meisten Monitore die hier vorgestellt werden sind ja auch keine Videomonitore sondern Computermonitore mit entrechend eingeschränkten Bildfrequenzen, die hauptsächlich für UIs gedacht sind und (was die Farben betrifft) für Photoshop/Bildbearbeitung, aber nicht für Video.



Antwort von pillepalle:

"Frank Glencairn" hat geschrieben:
Zunächst mal gibt es keinen vernünftigen Grund in 23.98 oder 29.97 zu drehen Außer im Fall das sich die Kamera nicht von PAL auf NTSC umstellen läßt... War mir bisher nie aufgefallen, weil ich immer in 25 oder 50fps drehe. Ist aber schon beknackt das nicht jede Fotoknipse diese Option bietet und man mit dann mit 23.98 drehen muss. Zum Glück läuft mein Monitor auch auf den krummen Frequenzen.

VG



Antwort von carstenkurz:

cantsin hat geschrieben:

Naja, es wäre ja kein Problem, da mit ganzzahligen Teilern 'rauszugehen - also z.B. 30p auf einem 60p-Monitor ohne 200% Beschleunigung auszugeben. Dafür nimmt man die GPU-Karte, die macht das automatisch. Es ist doch gerade der Witz an der Benutzung solcher Video-Out Karten, dass die Ausgabe absolut normidentisch erfolgt, und nicht 'irgendwie so ähnlich'.



Antwort von cantsin:

carstenkurz hat geschrieben:
cantsin hat geschrieben:

Naja, es wäre ja kein Problem, da mit ganzzahligen Teilern 'rauszugehen - also z.B. 30p auf einem 60p-Monitor ohne 200% Beschleunigung auszugeben. Dafür nimmt man die GPU-Karte, die macht das automatisch. Es ist doch gerade der Witz an der Benutzung solcher Video-Out Karten, dass die Ausgabe absolut normidentisch erfolgt, und nicht 'irgendwie so ähnlich'. Irgendwie kriegst Du meine Beiträge in den falschen Hals. Wie gesagt, es geht mir nicht um persönliche Beschwerden, sondern um Klarstellung (für Mitlesende) im Rahmen dieses Threads und seiner Ausgangsfrage, wie man mit Resolve sowohl Color Management, als auch die Anzeige weiterer Farbräume als sRGB hinkriegt.

Und da lautet die Antwort, dass es zwei Wege gibt:

- Ausgabe über GPU: geht (verlässlich) nur in sRGB, auch mit Monitoren, die mit einer anderen Framerate als das Projekt laufen.
- Augabe über Decklink: geht (verlässlich) in allen Farbräumen, dann aber nur sinnvoll mit Monitoren, die alle Projekt-/Timeline-Frameraten nativ (hardwaremäßig) unterstützen.

(Was auch heisst, dass Computermonitore mit erweiterten Farbräumen wie P3, aber ohne Video-typische Bildwiederholraten weder im ersten, noch im zweiten Szenario optimal laufen.)

Die ganze Diskussion fing mit @pillepalle an, der von der Fotografie kommt und erst nicht glauben wollte, dass in Resolve (und anderen Videoprogrammen) das nicht funktioniert, was in Photoshop (offenbar) möglich ist, nämlich dass man da einfach im Programm die Bildschirmausgabe auf P3 stellt und dann P3 am Computermonitor einstellt, um eine Vorschau in P3 zu erhalten.



Antwort von Frank Glencairn:

Wobei mich interessiert, was Pille mit P3 überhaupt will?



Antwort von pillepalle:

@ Frank

Ich will verschiedene Workflows und das Color Management ganz allgemein bei Film besser verstehen. Also alles was vom Quellfarbraum meiner Datei, über den Arbeitsfarbraum meiner Software, dem Farbraum der Wiedergabegeräte und dem Zielfarbraum genau passiert. Das ist im Detail bei unterschiedlicher Software zwar immer etwas anders, aber wenn man einmal das grundlegende Prinzip verstanden hat, verliert das Ganze seinen Schrecken. Man findet eben auch überall nur Stückwerk zu dem Thema, oder soll irgendwelche Bezahl-Workshops dafür belegen um an Informationen zu kommen, dessen Wert man vorher auch nicht kennt. Dabei sind das eigentlich ganz grundsätzliche und meiner Meinung auch nicht ganz unwichtige Dinge.

Je tiefer man nachfragt, desto diffuser werden die Antworten. Ist ja auch kein ganz einfaches Thema und es liegt sicher auch daran, das 90% der Filmer ihr ganzes Leben lang nicht mehr als REC709/BT1886 brauchen. Und wenn sie etwas anderes brauchen, gehen sie zum Dienstleister, weil nur der weiß wie es geht. Das ist schon etwas skuril. Als ob es sich dabei um Voodoo handeln würde :)

Wie gesagt, ich brauche es nicht unbedingt, aber ich möchte das einfach wissen und bin neugierig. Zur Zeit arbeite ich mich nicht gerade tot und habe Zeit für Dinge, zu denen ich sonst nie komme. Und dank Carsten habe ich die Gelegenheit das Monitorbild mit einer Kinoprojektion zu vergleichen und zu schauen, wie nahe die Einstellung der Projektion kommen und auf was man achten muss. Das sind für mich wertvolle praktische Erfahungen. Die Option des einfacheren Weges (alles in REC709 zu machen) habe ich immer. Die läuft nicht weg :)

VG



Antwort von dienstag_01:

pillepalle hat geschrieben:
@ Frank

Ich will verschiedene Workflows und das Color Management ganz allgemein bei Film besser verstehen. Also alles was vom Quellfarbraum meiner Datei, über den Arbeitsfarbraum meiner Software, dem Farbraum der Wiedergabegeräte und dem Zielfarbraum genau passiert. Das ist im Detail bei unterschiedlicher Software zwar immer etwas anders, aber wenn man einmal das grundlegende Prinzip verstanden hat, verliert das Ganze seinen Schrecken. Man findet eben auch überall nur Stückwerk zu dem Thema, oder soll irgendwelche Bezahl-Workshops dafür belegen um an Informationen zu kommen, dessen Wert man vorher auch nicht kennt. Dabei sind das eigentlich ganz grundsätzliche und meiner Meinung auch nicht ganz unwichtige Dinge.

Je tiefer man nachfragt, desto diffuser werden die Antworten. Ist ja auch kein ganz einfaches Thema und es liegt sicher auch daran, das 90% der Filmer ihr ganzes Leben lang nicht mehr als REC709/BT1886 brauchen. Und wenn sie etwas anderes brauchen, gehen sie zum Dienstleister, weil nur der weiß wie es geht. Das ist schon etwas skuril. Als ob es sich dabei um Voodoo handeln würde :)

Wie gesagt, ich brauche es nicht unbedingt, aber ich möchte das einfach wissen und bin neugierig. Zur Zeit arbeite ich mich nicht gerade tot und habe Zeit für Dinge, zu denen ich sonst nie komme. Und dank Carsten habe ich die Gelegenheit das Monitorbild mit einer Kinoprojektion zu vergleichen und zu schauen, wie nahe die Einstellung der Projektion kommen und auf was man achten muss. Das sind für mich wertvolle praktische Erfahungen. Die Option des einfacheren Weges (alles in REC709 zu machen) habe ich immer. Die läuft nicht weg :)

VG Arbeitest du denn im Fotobereich mit kalibrierten Kameras?



Antwort von pillepalle:

@ Dienstag

Wir arbeiten mit speziellen Kameraprofilen, weil mein Kollege im Kunstbereich arbeitet. Da geht es nur um genaue Farben. Für mich als 'Modefuzzi' ist das selten wirklich wichtig. Da geht's oft eher um eine schöne Atmosphäre. Wie die Dinge wirklich aussehen interessiert nur in Lookbooks oder Katalogen, machmal in der Werbung, aber auch da eher selten.

VG



Antwort von carstenkurz:

Wir haben ja außerdem seit Jahren die ständige Weiterentwicklung von Kameras hin zu weiteren Kontrastumfängen, RAW, etc. Und parallel dazu eben P3 im Kino und HDR/UHD. Natürlich kann man im Grading viel auf rec.709 unterbringen, aber, es geht nunmal weiter, und dafür braucht man irgendwann eine Monitoringlösung, die das darstellen kann. Selbst wenn man 'nur' rec.709 macht, muss und will man halt auch bewusst sicherstellen, dass das Monitoring korrekt ist. Das Verständnis von Farbmanagement und Farbräumen ist für den Einsteiger wirklich nicht einfach. Wir nehmen Farben von klein auf ganz natürlich wahr, ohne jede technisch-wissenschaftliche Auseinandersetzung damit. Jeder glaubt erstmal, das was er sieht sei 'die Wahrheit'.
Es ist vor dem Hintergrund dieser Selbstverständlichkeit nicht einfach, die eigene Wahrnehmung einer absoluten technischen Beurteilung zu unterwerfen.



Antwort von dienstag_01:

Farbmanagment beim Wort genommen heißt, über den gesamten Workflow nur mit kalibrierten und profilierten Geräten zu arbeiten.
Im Film gibts sowas schon mal gar nicht, ich kenne niemanden, der seine Kamera kalibriert. Im Fotobereich schon eher, aber praktisch eher weniger - siehe auch Aussage von pillepalle.

Aber irgendwann, wenn man den Film/das Foto nicht nur allein auf seinem Monitor anschauen will, muss man reproduzierbare Ergebnisse abliefern können, diese Stufe liegt allgemein bei der Ausgabe aus der Farbkorrektur. Also sollte es ab hier irgendwie *klappen*. Und dafür braucht es nicht nur einen kalibrierten/profilierten Monitor, sondern auch die Kommunikation von Anwendersoftware und Monitor. Dafür gibt es unter Windows monitorspezifische, *gemessene* Profile (werden von Videosoftware nicht verwendet) oder eben *gemessene* LUTs. Beide enthalten Korrekturdaten für den jeweiligen Monitor.

Einfach einen Monitor hinten ran hängen und denken, das ist jetzt Farbmanagment - das funktioniert vielleicht mit einem perfekten Monitor. Also nur theoretisch.

Ob man es im Einzelfall so genau braucht, steht auf einem anderen Blatt.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
cantsin hat geschrieben:

Nein, ich meine etwas anderes. Wenn Du z.B. eine 24p-Timeline hast und 30p als Monitor-Framerate einstellst, wird Deine Timeline mit 125% Geschwindigkeit/Zeitraffer abgespielt. Ja sicher, wie soll denn sonst die Diskrepanz zwischen MaterialFPS/TimelineFPS und Monitor Frequenz dargestellt werden?
Irgendwelcher Zwischenbild/DropFrame Voodoo ist fürs Monitoring inakzeptabel, da kannst du dir das mit der I/O Karte auch gleich schenken, und über die GPU raus gehen. nur weil ein monitor einen relativ großen bereich ein framerates akzeptiert, heißt das leider noch lange lange nicht, dass sie dann auch tatsächlich in einer weise wiedergegeben werden, die etwas mit dieser übergabe der daten zu tun hat!

im gegenteil -- fast immer werdann dann dort wieder anpassungen an eine möglichst befriedigende und flimmerfreie darstellung vorgenommen, über die man in der regel noch weniger kontrolle hat als auf seiten des computers bzw. der GPU!

normalerweise sollte man allerdings mit monitoren, die zumindest den bereich von 50-60 Hz od. wenigstens genau diese beiden optionen sauber unterstützen, mit hilfe von ein bisserl intelligenter bildaufbereitung bzw. den bekannten anpassungen alle üblichen film-/videobildraten einigermaßen erträglich ausgeben können.

neuere bildschirme und grafikkarten unterstützen sehr oft viel flexiblere refresh-möglichkeiten, die hauptsachlich im gaming-umfeld genutzt werden, aber prinzipiell natürlich auch wesentlich flexiblere bildwiederholraten bei der filmwiedergabe erlauben würden. allerdings sind diese features, die mittlerweile sogar tlw. eingang in die consumer videoübertragungsstandards gefunden haben, relativ kompliziert, und würden daher eine decklink-karte heillos überfordern.



Antwort von mash_gh4:

cantsin hat geschrieben:
[es geht mir nicht um persönliche Beschwerden, sondern um Klarstellung (für Mitlesende) im Rahmen dieses Threads und seiner Ausgangsfrage, wie man mit Resolve sowohl Color Management, als auch die Anzeige weiterer Farbräume als sRGB hinkriegt. ja -- diese eingrezung der fragestellung macht grundsätzlich sinn, trotzdem würde ich dir in dem zusammenang auch gerne wiedereinmal die ohnehin bereits mehrfach geäußerte warnung mit auf den weg geben, dass ein wide gamut screen, der zwar den ganzen P3-farbraum wiederzugeben vermag, in de den meisten fällen eine schlechtere bzw. weniger detailiert abgestufte sRGB-wiedergabe zeigen wird als ein verhältnismäßig billiger normaler schirm!

dass ist ähnlich wie bei den kameras, wo es ja bekanntlich auch immer mit nachteilen verbunden ist, wenn man zu flache bildprofile verwendet. bei monitoren kommt noch dazu, dass sie unabhängig von der ubertragungsbittiefe normalerweise immer panels verwenden, kaum mehr als 8bit helligkeitsstufen tatsächlich sauber bzw. unterscheidbar wiedergeben können. d.h. man einen großen teil dieses werteumfangs nicht nutzen kann, weil man sonst den geforderten farbraum überschreiten würde, wirkt sich das leider äußerst nachteilig auf die tatsächliche wiedergabequalität aus.

farbmanagement ist zwar tatsächlich sinnvoll und spätestens auf wide gamut monitoren ohnehin fast unerlässlich, um wenigstens diese grenzen zu beachten bzw. entsprechende anpassungen vorzunehmen, trotzdem gehen damit natürlich auch wieder ein paar andere probleme einher, die sich u.u. auch wieder in eher unerfreulicher weise bemerkbar machen können.



Antwort von mash_gh4:

dienstag_01 hat geschrieben:
Im Film gibts sowas schon mal gar nicht, ich kenne niemanden, der seine Kamera kalibriert. also bitte! -- die ganzen ACES bestrebungen sind doch nichts anderes, als all die vielfältigen ansätze, die dazu bereits länger in der filmindustrie gang und gäbe sind, endlich in sauber nachvollziehbare und untereinander austauschbare formen zu bringen. das derartiges in der praxis nicht genützt od. benötigt würde, stimmt leider ganz und gar nicht, vielmehr gibt's leider viel zu viel wildwuchs und proprietäe lösungen, die man nun langsam ein wenig zu entflechten, zu ordnen und zu vereinheitlichen versucht.



wenn man sich für die damit verbundenen problematiken interessiert, ist das wirklich extrem ermutigend, weil all die altlasten und kompromisse, die im laufe der zeit eingang in die klassischen videostandards gefunden haben, fürchterliche probleme im zuge jeder anspruchsvolleren nachbearbeitung mit sich bringen.



Antwort von Paralkar:

dienstag_01 hat geschrieben:
Farbmanagment beim Wort genommen heißt, über den gesamten Workflow nur mit kalibrierten und profilierten Geräten zu arbeiten.
Im Film gibts sowas schon mal gar nicht, ich kenne niemanden, der seine Kamera kalibriert. Im Fotobereich schon eher, aber praktisch eher weniger - siehe auch Aussage von pillepalle.

Aber irgendwann, wenn man den Film/das Foto nicht nur allein auf seinem Monitor anschauen will, muss man reproduzierbare Ergebnisse abliefern können, diese Stufe liegt allgemein bei der Ausgabe aus der Farbkorrektur. Also sollte es ab hier irgendwie *klappen*. Und dafür braucht es nicht nur einen kalibrierten/profilierten Monitor, sondern auch die Kommunikation von Anwendersoftware und Monitor. Dafür gibt es unter Windows monitorspezifische, *gemessene* Profile (werden von Videosoftware nicht verwendet) oder eben *gemessene* LUTs. Beide enthalten Korrekturdaten für den jeweiligen Monitor.

Einfach einen Monitor hinten ran hängen und denken, das ist jetzt Farbmanagment - das funktioniert vielleicht mit einem perfekten Monitor. Also nur theoretisch.

Ob man es im Einzelfall so genau braucht, steht auf einem anderen Blatt. Also die meisten Rentals geben Ihre Kameras einmal im Jahr zu Arri fürs neu kalibrieren.
Der Sensor wird dabei ja auch immer auf gleicher Temperatur gehalten, um die gleichen Ergebnisse zu erhalten, verglichen mit Blackshading von Red und Sony.

Unabhängig davon wäre ja hier noch kein Problem, das Kameramaterial bleibt ja das selbe mit dem gearbeitet wird, egal ob VFX oder Grading, und da springt ja ACES ein, somit kann der VFXler an seinem srgb Monitor arbeiten und der Colorist an nem P3 DCI Projektor.



Antwort von pillepalle:

Ja, mit ACES habe ich mich noch gar nicht wirklich beschäftigt, scheint aber wirklich mal ein sinnvoller Standart zu sein. Im Grunde ist es aber auch nur ein großer einheitlicher Farbraum mit einheitlichem Workflow für alle. Was z.B. bei Assimilate wirklich gut ist, das sie den Workflow recht genau erklären. Also nicht nur was die IDTs und ODTs betrifft, sondern auch die RRTs erwähnen, die für den Nutzer gar nicht sichtbar sind. Hier am Beispiel von ProRes RAW zu ACES Workflow am Anfang des Videos recht gut erklärt.



In einem älteren Video geht er sogar mit Beispielen etwas genauer auf die Gründe ein, warum man in ACES z.B. lieber in log als in linear arbeitet, oder wie man verschiedene Monitoren verschiedene ODTs zuweist. So kann man das gleiche Bild einmal auf seinem Computermonitor sehen und gleichzeitig auf dem angeschlossenen Referenz-Monitor. In dem Beispiel ein P3 Projektor.

https://www.youtube.com/watch?v=YCqt6QlbNnc&t=4m25s

So verständlich erklärt würde man sich das bei anderer Software auch gerne wünschen.

VG

PS: Was mir noch gar nicht so richtig klar war wie cool das Monitoring bei Scratch gelöst ist. Ich kann neben meinem 'normalen' Monitor (den ich über Interface einstelle) auch noch meinen Eizo als Dual Head über DisplayPort und Grafikkarte nutzen, oder alternativ über die Decklink über HDMI (dann natürlich auch zusätzlich mit der richtigen Bildwiederholrate). Wenn ich jetzt noch einen P3 Projektor anschließen würde, könnte ich den auch als Referenzmonitor nutzen :) Das ist wirklich vorbildlich und verständlich gelöst.


zum Bild




Antwort von dienstag_01:

Paralkar hat geschrieben:
dienstag_01 hat geschrieben:
Farbmanagment beim Wort genommen heißt, über den gesamten Workflow nur mit kalibrierten und profilierten Geräten zu arbeiten.
Im Film gibts sowas schon mal gar nicht, ich kenne niemanden, der seine Kamera kalibriert. Im Fotobereich schon eher, aber praktisch eher weniger - siehe auch Aussage von pillepalle.

Aber irgendwann, wenn man den Film/das Foto nicht nur allein auf seinem Monitor anschauen will, muss man reproduzierbare Ergebnisse abliefern können, diese Stufe liegt allgemein bei der Ausgabe aus der Farbkorrektur. Also sollte es ab hier irgendwie *klappen*. Und dafür braucht es nicht nur einen kalibrierten/profilierten Monitor, sondern auch die Kommunikation von Anwendersoftware und Monitor. Dafür gibt es unter Windows monitorspezifische, *gemessene* Profile (werden von Videosoftware nicht verwendet) oder eben *gemessene* LUTs. Beide enthalten Korrekturdaten für den jeweiligen Monitor.

Einfach einen Monitor hinten ran hängen und denken, das ist jetzt Farbmanagment - das funktioniert vielleicht mit einem perfekten Monitor. Also nur theoretisch.

Ob man es im Einzelfall so genau braucht, steht auf einem anderen Blatt. Also die meisten Rentals geben Ihre Kameras einmal im Jahr zu Arri fürs neu kalibrieren.
Der Sensor wird dabei ja auch immer auf gleicher Temperatur gehalten, um die gleichen Ergebnisse zu erhalten, verglichen mit Blackshading von Red und Sony.

Unabhängig davon wäre ja hier noch kein Problem, das Kameramaterial bleibt ja das selbe mit dem gearbeitet wird, egal ob VFX oder Grading, und da springt ja ACES ein, somit kann der VFXler an seinem srgb Monitor arbeiten und der Colorist an nem P3 DCI Projektor. Ja, mit Arris kenne ich mich nicht aus, da kann man hier nur von deinem Wissen profitieren.
Und klar, wenn man den Farbraum nicht wechselt (oder den größten vorhandenen wählt), kann es zu keinen Problemen durch Umwandlungen kommen. Deshalb kann man ja für Web auch ziemlich gut ohne Color Managment in Resolve arbeiten.
Eine Frage hätte ich ja: Wenn ihr mit ArriRAW arbeitet, erstellt ihr dann Profile? Da wird ja - um mal bei meinen mehr theoretischen Überlegungen zu bleiben - sozusagen aus Sensor und Bearbeitungssoftware eine profilierte und kalibrierte Kamera.



Antwort von Frank Glencairn:

dienstag_01 hat geschrieben:
Wenn ihr mit ArriRAW arbeitet, erstellt ihr dann Profile? Da wird ja - um mal bei meinen mehr theoretischen Überlegungen zu bleiben - sozusagen aus Sensor und Bearbeitungssoftware eine profilierte und kalibrierte Kamera. Nein, das Debayering von ARRI-RAW zu ARRI-C (LOG-C) ist ja bereits normiert, und die Transformation für's Monitoring, bzw. zu den jeweiligen Ausgabeformaten (Farbräumen etc.) ebenfalls.

Wenn du das dann unter ACES machst, oder unter dem neuen BM Wide Gamut, der ja noch viel größer als ACES ist, gibt's da nicht mehr viel zu profilieren.
Wenn du da mit nem Profil irgendwie dazwischen pfuschen würdest, würfelt das alles durcheinander, zumal ja gerade ne Alexa kein Farbmessgerät ist, sondern ganz bewußt einen eigenen Charakter eingebaut hat, der die Farben eben nicht 1:1 identisch darstellt, sondern quasi "gefällig" - so wie gute HiFi Boxen das ja auch machen, anstelle den Ton völlig transparent und unverändert durchzureichen, wie Nahfeld-Studiomonitore.

Ich glaube du machst dir da insgesamt zu viel einen Kopf.

Am Ende des Tages muß dein Bild (und die Farbe) eine bestimmte Stimmung transportieren, um die Story zu unterstützen. Diese "Stimmung" is vor der Kamera so gut wie nie vorhanden, und muß deshalb fast immer in der Post hergestellt werden. Das wichtigste dabei ist, daß der Zuseher auf seinem Endgerät so ziemlich da selbe sieht wie du in der Post.

Ob eine System einen Farbton von der Aufnahme (Sensor) bis zur Betrachtung (Kino/TV etc) durch irgendwelche Kalibrier-Ketten 1:1 durchreichen kann, ist nicht nur unnötig, sondern auch - wegen mangelnder Kontrolle über die Endgeräte - illusorische.



Antwort von pillepalle:

Da hat Frank völlig Recht. Eine Arri, wie übrigens fast alle Kameras, respektive ihre Profile, soll die Wirklichkeit nicht möglichst exakt wiedergeben, sondern möglichst schön. Das ist eben die individuelle 'color science'. Das Profilieren der Kamera macht man eigentlich nur, wenn man auf ein bestimmtes Ergebnis (z.B. möglichst realistische Darstellung) hin arbeitet und so weniger Arbeit in der Post haben möchte, als wenn man alles vom bonbon-bunt des Kamerahersteller-Profils erstmal wieder normalisieren muss.

Interessant ist aber die Möglichkeit bereits vorab den Look mithilfe von LUTs festzulegen. Damit kann man nicht nur bereits am Set einen Eindruck bekommen, sondern dadurch bekommt später der Color-Grader auch schon einen Eindruck davon wie es aussehen soll. Wie das genau im Detail geht, damit muss man sich dann aber auch erstmal wieder vorher beschäftigen :)

VG



Antwort von Paralkar:

Ich arbeite nicht für Arri, dementsprechend kann ich dir nicht wirklich was über die Kalibrierung des Sensors sagen, aber vom der Praxiserfahrung bei Filmproduktionen und der Zusammenarbeit mit den Rentals, weiß ich das diese hin und wieder ihre Alexas/ Amiras einschicken um neu Kalibrieren zu lassen, und bei nem Dreh kam es schon mal vor, das die Kamera repariert & neu kalibriert werden musste, weil das Fixed Pattern Noise massiv zugenommen hatte.

Wie oben schon erwähnt, dadurch das Arri den Sensor auf konstanter Temperatur hält (vorausgesetzt es ist nicht über 45 oder unter -20 Grad), also nicht nur kühlt, sondern auch beheizt, wenn es notwendig ist, bleibt das Ergebnis länger konstant.

Daraus resultiert auch, dass die IDT dann das selbe tut und zu selben Ergebnissen führt, praxisbezogen gibt es da aber auch noch Korrekturen die Kamera spezifisch gemacht werden muss. Bsp.: Die alten klassischen Alexas haben ein stärkeren Grünstich im Vergleich zu den Minis/ Aminra/ LF & Mini LFs, hinzukommt natürlich Filtrierung, auch da sind die internen Filter der Mini deutlich deutlich sauberer. Man müsste in so einem Fall ja wirklich pro Filter in Kombination mit Kamera unterschiedliche Profile angelegen, das wäre bei Mehrkamera Produktionen nichtmehr sinnvoll umsetzbar.

Als Bespiel aus der Praxis, wir haben oft ne Alexa Mini als A-Cam und ne Alexa Classic als B-Cam an nem klassischen Fernsehfilm/ Serien Set. Die Alexa Mini hat sehr saubere interne NDs, die selbst bei 2,1 ND keine Farbstiche aufzeigen, aber auch hier muss man gegebenenfalls ein 0,3 ND oder 0,6 ND vorne ins Kompendium klatschen, da sie nur 3 interne ND Filter hat (0,6; 1,2; 2,1), dementsprechend brauche ich bei nem 0,9 ND noch ein Filter vorne dran.
Die Classic hingegen hat keine internen, und je nachdem welche NDs man nutzt Tiffen/ Schneider etc. kann es ab 0,9 ND aufwärts zu stärkeren Grünstichen kommen, je stärker der ND oder mehrere NDs zusammen wird das teilweise ordentlich grünstichig. Das ganze kann man mittels WB halbwegs am Set ausgleichen, muss diese pro FIlter oder Filterkombi aber erstmal testen und rausfinden und dann pro Wechsel auch ändern.

Optiken können sich übrigens auch massiv unterscheiden, wenn ich an die alten S2/3 Panchro denke, die eine kalt, die andere warm....

All das ist aber auch nicht so schlimm, weil es problemlos im Grading korrigiert wird und gegebenenfalls nutzt man ein Color Chart am Set



Antwort von roki100:

Paralkar hat geschrieben:
Wie oben schon erwähnt, dadurch das Arri den Sensor auf konstanter Temperatur hält (vorausgesetzt es ist nicht über 45 oder unter -20 Grad), also nicht nur kühlt, sondern auch beheizt, wenn es notwendig ist, bleibt das Ergebnis länger konstant. Wahrscheinlich wird für die konstante Temperatur "Peltier-Element" benutzt:
"Ein Peltier-Element ist ein elektrothermischer Wandler, der basierend auf dem Peltier-Effekt bei Stromdurchfluss eine Temperaturdifferenz oder bei Temperaturdifferenz einen Stromfluss erzeugt. Peltier-Elemente können sowohl zur Kühlung als auch – bei Stromrichtungsumkehr – zum Heizen verwendet werden."
https://de.wikipedia.org/wiki/Peltier-Element



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
dienstag_01 hat geschrieben:
Wenn ihr mit ArriRAW arbeitet, erstellt ihr dann Profile? Da wird ja - um mal bei meinen mehr theoretischen Überlegungen zu bleiben - sozusagen aus Sensor und Bearbeitungssoftware eine profilierte und kalibrierte Kamera. Nein, das Debayering von ARRI-RAW zu ARRI-C (LOG-C) ist ja bereits normiert, und die Transformation für's Monitoring, bzw. zu den jeweiligen Ausgabeformaten (Farbräumen etc.) ebenfalls. ich glaub sogar, dass im falle der ARRIs auch sehr viele details jenseits dieser äußeren normvorgaben, wie etwa das exakte spektrale sensitivitätsverhalten der benutzten sensoren etc., sehr genau bekannt sind und für berechnungen bei der RAW-entwicklung und postproduktion herangezogen werden können.

darin unterscheiden sich diese professionellen geräte recht deutlich vom consumerkram für normalsterbliche, wo man derartiges kaum findet bzw. höchstens in bescheidenen ansätzen selber erstellen kann.
"Frank Glencairn" hat geschrieben:
Wenn du da mit nem Profil irgendwie dazwischen pfuschen würdest, würfelt das alles durcheinander, zumal ja gerade ne Alexa kein Farbmessgerät ist, sondern ganz bewußt einen eigenen Charakter eingebaut hat, der die Farben eben nicht 1:1 identisch darstellt, sondern quasi "gefällig" - so wie gute HiFi Boxen das ja auch machen, anstelle den Ton völlig transparent und unverändert durchzureichen, wie Nahfeld-Studiomonitore. das mit dem kameraspezifischen "charakter" od, "stil" mag evtl. stimmen, wenn man fertige aufbereitete bilder diekt aus der kamera bspw. in ProRes erhalten will, aber für einen sauberen RAW- bzw. ACES workflow, wäre das ausgesprochen unbefriedigend.

dort versucht man vielmehr eine möglichst saubere und neutrale ausgangsbasis zu schaffen, um darauf ggf. verschiede "looks" bzw. bildstile od. (scheinbare) kamera-charakteristiken anzuwenden. so gesehen, hat das zumindest in diesem ersten und ganz fundamentalen schritt tatsächlich mehr mit "farbmessung" als "gefälliger" wiedergabe zu tun.

z.t. werden im professionellen umfeld kameras tatsächlich auch einzeln ausgemessen und profiliert, weil es, wie bei allen hardwarekomponenten, streuungen in der produktion bzw. geringfüge abweichungen zw. den individuellen geräten gibt. es gibt in dieser hinsicht kameraleute, die das für genauso unverzichtbar und selbstverständlich halten wie das kalibrieren der monitore im studio, aber eben auch andere, die darüber nur den kopf schütteln.



Antwort von Frank Glencairn:

Weil's gerad hier rein passt: Netflix hat die Liste der empfohlenen Vorschaumonitore aktualisiert.
Recommended SDR Displays - Calibrated for Rec.709/BT.1886 at 100-nits

Most of the modern professional and consumer displays are able to meet the standards of SDR color grading.
Below are some common displays used for SDR grading/viewing.

SDR (only) Reference Options
Sony PVM-A250
Sony BVM-F250
Dolby PRM-4220
Flanders FSI DM250

SDR Consumer Options
LG OLED C8/C9 (2018-2019 Model)
LG OLED CX (2020 Model)
*Sony OLED A9F/A9G
*Panasonic OLED GZ1000/GZ2000
Apple iPad Pro
Apple Pro Display XDR
EIZO CG319X
HP Dreamcolor z27x, z32x


Recommended HDR Displays - Calibrated for SMPTE 2084 PQ / P3-D65*

HDR Reference Options
Must meet Dolby Vision grading requirements

HDR Consumer Options
These HDR Consumer options are for review purposes or pre-grading only, and not to be used for final color grading work.

LG OLED C8/C9 (2018-2019 Model)
LG OLED CX (2020 Model)
*Sony OLED A9F/A9G
*Panasonic OLED GZ1000/GZ2000
Apple iPad Pro (2nd generation or higher)
Apple Pro Display XDR
* Certain scenarios that use HDR10 signals may require calibration to PQ / Rec. 2020

Calibration and Working/Viewing Environment

We understand that having the proper working or viewing environment at home can be difficult to achieve on such short notice. If proper viewing environment guidelines can not be met (Color Grading & Calibration Guidelines) then please make sure the working and viewing environments are not completely dark or extremely bright. A dimly lit environment with neutral (6500K) color temperature is the best guidance we can give.



Recommended Bias Lighting for Home Setups

MediaLight 6500K Bias Lighting Systems
Direct from MediaLight
From reseller: Flanders Scientific Inc.


Recommended Calibration Probes for Home Setups

Portrait Displays C6 HDR2000 (Probe Only)
Portrait Displays C6 HDR2000 & VideoForge PRO (Probe and Signal Generator)
X-Rite i1 Display Pro Plus (Probe)
Note: The Portrait Displays C6 HDR2000 is only compatible with Calman 2019 R2 and future software releases.



Recommended Calibration Software

Portrait Displays CalMan Software
How-To Calibrate SDR for LG OLED C9
Light Illusion LightSpace
Free 3-Day LightSpace licenses for the duration of the lock-down. Please use their website Contact Form to request a free 3-Day LightSpace license.



Antwort von pillepalle:

Gut zu wissen... da bin ich für Netflix immerhin mit Consumergeräten tauglich :) Aber Netflix ist natürlich Fernsehn/Web (REC709/BT1886), kein Kino.

Mit Ausnahme des ersten günstigen 25" Zöllers von Sony (für 7.000,-€) liegen die professionellen Monitore für SDR bei denen alle zwischen 25.000,- und 35.000,-€. Ich glaube da müssen selbst die meisten professionellen Coloristen schlucken, denn so ein Ding hält ja wirklich nur ein paar Jahre.

VG



Antwort von Darth Schneider:

Warum hält das teure Ding nur ein paar Jahre ?
Zu Tode gegraded....;)))
Was macht eigentlich das iPad Pro auf der Netflix Monitor Empfehlungs Liste ?
Ist wenigstens nicht so teuer wie ein neues Auto..;)
Gruss Boris



Antwort von pillepalle:

@ Darth

Weil sich jeder Monitor über die Jahre verbraucht und wenn er zu alt wird, kann er die empfohlenen Parameter nicht mehr einhalten. Das hängt davon ab wieviel man ihn nutzt. Die besseren Monitore haben alle einen Stundenzähler drinnen.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
Gut zu wissen... da bin ich für Netflix immerhin mit Consumergeräten tauglich :) Aber Netflix ist natürlich Fernsehn/Web (REC709/BT1886), kein Kino. Nicht zwingend, da Netflix auch in HDR sendet: Dolby Vision und HDR10, beide Rec2020 = größere Farbräume als P3.



Antwort von pillepalle:

@ castin

Ich hab' ja auch von den Vorgaben für SDR Produktionen gesprochen ;) Bei BT 2020 hab' ich natürlich nur noch eine Farbraumabdeckung von 88%. HDR Material kann ich natürlich auch nur im SDR Modus wiedergeben (mit HLG oder PQ Gamma Kurve und respektiven 300nits), weil der Monitor für echtes HDR nicht hell genug ist. Gibt einem aber zumindest die Möglichkeit HDR Material zu graden, aber logischerweise ist ein echter HDR Monitor dafür besser geeignet. Wer das nötige Kleingeld dafür hat, der Kauft sich eben einen Bildschrim für 20.000,-€ :)

VG



Antwort von Frank Glencairn:

Ich denke der Sweetspot sind die beiden LG OLEDs. Gut genug für alles was wir hier so machen, und die kommen auch mit einem erträglichen Preisaufkleber.

Und wie Pille schon sagt, wer tatsächlich Bedarf für mehr hat, hat auch das entsprechende Budget.



Antwort von dienstag_01:

"Frank Glencairn" hat geschrieben:
Weil's gerad hier rein passt: Netflix hat die Liste der empfohlenen Vorschaumonitore aktualisiert.
Recommended SDR Displays - Calibrated for Rec.709/BT.1886 at 100-nits

Most of the modern professional and consumer displays are able to meet the standards of SDR color grading.
Below are some common displays used for SDR grading/viewing.

SDR (only) Reference Options
Sony PVM-A250
Sony BVM-F250
Dolby PRM-4220
Flanders FSI DM250

SDR Consumer Options
LG OLED C8/C9 (2018-2019 Model)
LG OLED CX (2020 Model)
*Sony OLED A9F/A9G
*Panasonic OLED GZ1000/GZ2000
Apple iPad Pro
Apple Pro Display XDR
EIZO CG319X
HP Dreamcolor z27x, z32x


Recommended HDR Displays - Calibrated for SMPTE 2084 PQ / P3-D65*

HDR Reference Options
Must meet Dolby Vision grading requirements

HDR Consumer Options
These HDR Consumer options are for review purposes or pre-grading only, and not to be used for final color grading work.

LG OLED C8/C9 (2018-2019 Model)
LG OLED CX (2020 Model)
*Sony OLED A9F/A9G
*Panasonic OLED GZ1000/GZ2000
Apple iPad Pro (2nd generation or higher)
Apple Pro Display XDR
* Certain scenarios that use HDR10 signals may require calibration to PQ / Rec. 2020

Calibration and Working/Viewing Environment

We understand that having the proper working or viewing environment at home can be difficult to achieve on such short notice. If proper viewing environment guidelines can not be met (Color Grading & Calibration Guidelines) then please make sure the working and viewing environments are not completely dark or extremely bright. A dimly lit environment with neutral (6500K) color temperature is the best guidance we can give.



Recommended Bias Lighting for Home Setups

MediaLight 6500K Bias Lighting Systems
Direct from MediaLight
From reseller: Flanders Scientific Inc.


Recommended Calibration Probes for Home Setups

Portrait Displays C6 HDR2000 (Probe Only)
Portrait Displays C6 HDR2000 & VideoForge PRO (Probe and Signal Generator)
X-Rite i1 Display Pro Plus (Probe)
Note: The Portrait Displays C6 HDR2000 is only compatible with Calman 2019 R2 and future software releases.



Recommended Calibration Software

Portrait Displays CalMan Software
How-To Calibrate SDR for LG OLED C9
Light Illusion LightSpace
Free 3-Day LightSpace licenses for the duration of the lock-down. Please use their website Contact Form to request a free 3-Day LightSpace license. Monitore empfehlen kann man natürlich, das sollte aber in keinem Fall mit einer Zertifizierung o.ä. verwechselt werden.
Messgerät muss man trotzdem verwenden ;)



Antwort von carstenkurz:

Ich hab's noch nicht komplett gelesen, aber bevor ich vergesse es zu verlinken:



https://www.thepostprocess.com/2020/07/ ... time-tags/

https://www.thepostprocess.com/2020/03/ ... -displays/



Antwort von cantsin:

carstenkurz hat geschrieben:
Ich hab's noch nicht komplett gelesen, aber bevor ich vergesse es zu verlinken:



https://www.thepostprocess.com/2020/07/ ... time-tags/ Danke - das raubt einem gleich alle Illusionen, dass das Problem unter MacOS besser gelöst sein könnte...

Kurzzusammenfassung: MacOS hat zwar systemweite Unterstützung für P3, nur ist Apples P3 nicht standardkonform, sondern ein selbstgestricktes "Display P3" mit sRGB-Gamma und D65-Weißpunkt (ggü. Gamma 2.6 und nativen, näher bei D63 liegenden Weißpunkt von DCI-P3).

Und das wiederum führt dazu, dass es Color Shifts zwischen Resolve und Quicktime X gibt, bzw. dass P3-Projekte in Resolve nur mit Color Shifts oder komplexen Klimmzügen auf Mac OS-Systemdisplays betrachtet werden können...

Oder noch kürzer zusammengefasst: Quicktime gamma shift 2.0.



Antwort von carstenkurz:

Das beschriebene Problem hat mit P3 überhaupt nichts zu tun sondern beschreibt lediglich einen Weg, von Resolve exportierte Quicktimes so zu taggen, dass Apple konforme Software sie durch Auswertung der Tags so darstellt wie der Resolve Viewer.