Beiträge von FoLLgoTT

    Mit Colourscape kann man ja auch ein 1DLut jetzt machen (laut madshi) Kann mir bitte jemand sagen was der unterschied/vorteil zwischen 1DLut und 3D Lut ist ?

    LUT steht für Lookup-Tabelle. Das bedeutet, dass einem oder mehrere Eingangswerte einen oder mehrere Ausgangswerte zugiewesen werden. Die LUT ist dabei statisch. Das heißt, sie besteht fest auf Wertetupeln.


    1D-LUTs

    Das 1D bezieht sich auf die Anzahl der Eingangswerte. Eine 1D-LUT setzt also exakt einen Wert auf exakt einen anderen Wert um. Damit werden bei Grafikkarten die Stufen der drei Grundfarben korrigiert, also Gamma und ggf. Schwarz- und Weißpunkt (ersterer besser nicht). Man kann damit also den Gammaverlauf und das Mischungsverhältnis der Grundfarben für jede Helligkeitsstufe verändern, aber nicht den Gamut. Das ist ganz wichtig zu verstehen!


    pasted-from-clipboard.png


    Jede Grafikkarte besitzt 3 x 1D LUTs für RGB. Ich hatte vor Jahren mal einen VideoEqualizer geschrieben. Lange bevor jedermann messen konnte. Damit konnte man die Verläufe der drei Grundfarben beliebig verändert und die Grafikkarte hat das automatisch Umgesetzt. Häufig besitzt eine 1D-LUT 256 (8 Bit) Eingangsstufen und setzt diese auf 1024 (10 Bit) Ausgangsstufen um, damit kein Banding entsteht.

    pasted-from-clipboard.png


    1D-LUTs reichen für die Kalibrierung aus, wenn der Gamut bereits passend ist. Bei JVC korrigieren wir in der Regel nur die drei 1D-LUTs mit AutoCal, weil für die Gamutkonvertierung bereits fertige Profile im Projektor vorliegen.



    3D-LUT

    Ein 3D-LUT dagegen besitzt drei Eingangswerte und setzt sie auf drei Ausgangswerte um. Damit spannt so eine LUT einen Raum auf (quasi einen Würfel).


    pasted-from-clipboard.png


    Es kann also jeder beliebige Punkt im nativen Farbraum auf einen anderen beliebigen Punkt umgesetzt werden. Damit kann eine 3D-LUT alles in einem Rutsch korrigieren. Wenn der Zielfarbraum größer ist als der Quellfarbraum, gibt es quasi keinen Verlust. Wenn der Zielfarbraum kleiner ist, können zumindest die Töne innerhalb dieses Farbraums korrekt abgebildet werden und alles Außerhalb wird auf den Rand gelegt (Clipping). Je nach Rendering Intent gibt es da verschiedene Methoden, das zu tun bzw. welcher Parameter möglichst gut erhalten bleiben soll (z.B. Luminanz, Sättigung oder Erscheinungsbild).

    Eine 3D-LUT kann also sowohl die Graustufen, das Mischungsverhältnis als auch den Gamut verändern. Das ist in einer 3D-LUT auch nicht getrennt, sondern alles in einer einzigen Zuweisung "vermischt".


    1D-LUTs + Matrix

    Dann gibt es noch die Möglichkeit, drei 1D-LUTs und eine 3x3-Matrix zu mischen. Man kann also eine Matrix erzeugen, die nur den Gamut verändert (Farbort und Sättigung). Das tut sie dann für alle Helligkeitsstufen auf gleiche Weise. Dazu kommen die drei 1D-LUTs, die nur Gamma und das Mischverhältnis anpassen, also quasi den Rest korrigieren. ICC-Profile funktionieren häufig so.


    pasted-from-clipboard.png + pasted-from-clipboard.png


    Das klappt gut, solange sich das Anzeigegerät in seinem nativen Farbraum bezüglich der Mischung der Primärfarben linear verhält. Normalerweise ist es so, dass ein Anzeigegerät, dass alle seine Töne durch die Mischung von drei Grundfarben erzeugt, sich wie erwartet verhält und damit komplett korrigiert werden kann. Sobald aber eine Nichtlinearität vorhanden ist (z.B. bei 1-Chip-DLPs, OLEDs und Plasmas) klappt das nicht mehr komplett. Auch wenn bereits ein CMS im Anzeigegerät aktiv ist, dass Korrekturen vornimmt, können Nichtlinearitäten entstehen.

    Im Gegensatz zu der Variante 1D-LUTs + Matrix kann eine vollständige 3D-LUT diese Nichtlinearitäten (theoretisch) komplett korrigieren. Natürlich nur, solange der Wertebereich ausreicht und kein Banding auftritt.

    Ich nutze ja für das Seitenverhältnis auch Metadaten am Film, die ich manuell pflege und somit 100%ig sicher bin. Es gibt allerdings ganz selten mal gewollte Formatwechsel, für die ich gerne in Echtzeit zumindest den Zoom anpassen würde. Die letzten beiden Staffel von "The Expanse" sind so ein Beispiel. Hat das mal jemand geschafft?


    Nachtrag: im schlimmsten Fall könnte man es ggf. auch mit einer Metadatendatei lösen, indem man die Zeitmarken und Seitenverhältnisse auflistet und dann per Script anwendet. Aber dafür muss man einmal manuell durch den Stream fräsen...

    Übrigens kann man sich mit "mpv --show-profile=gpu-hq" anzeigen lassen, was das Profil "gpu-hq" eigentlich enthält. Das sind folgende Optionen:


    Wenn man diese Optionen ohnehin alle einzeln setzt, kann man sich das Profil auch sparen. :zwinker2:

    In der Theorie, ja.

    Praktisch habe ich da noch nie eine Wert zurück bekommen. Weder für "video-params/gamma", noch für "video-params/primaries"

    Es kommt darauf an, wann man sie abruft. Im Event "file-loaded" bekomme ich nur die primaries, gamma ist dagegen nil. Im Event "pause" geht beides. Die sind beim Laden des Videos anscheinend noch nicht alle gesetzt.

    Mein Ansatz war nun, dass ich den HDR "target-peak" Parameter anpasse. Ich habe einen JVC N5 Projektor und werde so ca. 50-70 Nits auf meiner akustisch Transparenter Leinwand haben. Daher war mein Ansatz, den Wert mal etwas zu ändern. Wenn ich aber unter 100 gehe, überstrahlen die hellen Details und auch die Farben passen nicht mehr ohne das es in dunklen Szenen merklich heller wird. Alles wird farblich übersättigt. Auf der anderen Seite, wenn ich deutlich höhere Werte über 150 eingebe, wird das Bild dunkler. Was ich ja so auch erwarten würde.

    Ja, das entspricht auch dem, was ich festgestellt habe. Es gibt noch den folgenden Parameter, mit dem du etwas rumspielen kannst: tone-mapping-max-boost. Der verändert auch die Gesamthelligkeit des Bildes. Grundsätzlich bleibt es aber dabei, dass beim Tone Mapping von madVR die Grundhelligkeit über alle Szenen noch etwas stimmiger ist und in den Highlights Details stärker erhalten bleiben. Ich habe jedenfalls keine Kombination in MPV gefunden, die das exakt so hinbekommt. Wer aber nicht direkt vergleicht, wird nur selten etwas vermissen.


    Übrigens wird das neue Tone Mapping gerade in MPV überführt. Mal schauen, wie das dann so ist. Allerdings läuft das dann bisher nur ohne Hardwaredekodierung ("gpu-next").


    Pull Request

    Jetzt hast du so oft editiert, dass ich gar nicht mehr weiß, was ich schreiben wollte. :zwinker2:

    Verstehe ich, darf ich dann noch Anfängerfragen hier stellen oder eher nicht mehr?

    Ich habe nichts dagegen. Es ist aber auch nicht mein Thread. Vielleicht müssen wir spezielle Themen einfach eher in eigene Threads abspalten. Häufig überlagern sich die Themen leider.


    Nach ((( atom )))s Weggang kann den ersten Beitrag keiner mehr editieren, also wird dieser Thread in einem chaotischen Sammelsurium vor sich hinvegetieren, in dem einfach jeder etwas reinknallt und beliebige Fragen stellt (so wie der madVR-Thread). Die Übersichtlichkeit ist ja jetzt schon dahin. Falls jemand weiter an einer Anfänger-Konfiguration oder einem Image arbeitet, wäre ein neuer Thread sicherlich keine schlechte Idee. Olombo ?

    Hier noch mal eine Version, die auch die Skalierung von MPV bezüglich der Krümmung unterstützt, also wenn man für CIH z.B. das 16:9-Bild kleiner macht. Dummerweise muss man die Zielauflösung direkt in das Script eintragen. Der Vorteil ist, dass man die Skalierung/Entzerrung von MPV durchführen lassen und zur Laufzeit ändern kann. Das erleichtert die Handhabung deutlich.


    Weiterhin hänge ich mich jetzt nach der Skalierung ein. Die Qualität ist somit höher, die Rechenlast allerdings auch. Bikubisch reicht nach meinen vergleichen vollkommen aus. Daher ist das hier aktiviert.


    Code
    siehe ersten Beitrag

    hier weiß man als Anfänger z.B. auch nicht, was man dafür vom vorhandenen script löschen muss. Wo das hinkommt ist klar, aber was kann dafür weg und welche anderen Einträge werden dadurch beeinflusst?

    Naja, ich stelle das hier nicht für Anfänger rein, sondern für Fortgeschrittene. An einem Tutorial für Anfänger bin ich persönlich nicht interessiert. Das können andere machen, wenn sie Lust dazu haben. Meine Spezialität sind die weit fortgeschrittenen Dinge/Optimierungen, die ich diskutieren möchte, und ich möchte mich nicht mit Grundlagen aufhalten. Das ist wirklich nicht böse gemeint, aber nicht jeder muss immer alles für Anfänger vorgekaut bereitstellen. :)


    Dieser Thread ist sehr allgemein gehalten. Da können Spezialitäten diskutiert werden oder es kann auch eine allgemeine Konfiguration für Anfänger dabei abfallen.

    Naja, du musst in die Profile auch die Parameter setzen, die du ändern willst (in deiner Konfiguration sind sie leer). Hier ein Beispiel, das zwischen lanczos und ewa_lanczossharp hin- und herschaltet, wenn man Tasten darauf konfiguriert.


    Code
    [an]
    profile-desc="an"
    scale=ewa_lanczossharp
    
    [aus]
    profile-desc="aus"
    scale=lanczos

    Du kannst in die Profile die Parameter reintun, die du möchtest und dann mit den beiden Tasten zur Laufzeit hin- und herschalten. Mehr steckt nicht dahinter.

    Wie genau stell ich das denn jetzt in der Config ein, also das der eine aus und der andere eingeschaltet ist?

    Naja, du ersetzt scale=ewa_lanczossharp durch scale=lanczos. Für dscale oder cscale kannst du das auch machen, wenn du möchtest.


    Nimm es mir nicht übel, aber ein bisschen muss man sich schon selbst mit MPV beschäftigen. So Grundlagen, wie ich einen Parameter in der Konfiguration setze, möchte ich hier eigentlich nicht besprechen. :)


    Nachtrag nach nochmaligem Lesen: du meinst das Hin- und Herschalten, richtig? Wie das geht, habe ich ein paar Beiträge vorher geschrieben.

    Und hier noch ein abgespecktes Profil für alle Bildraten > 50, das mit einer GeForce 1050 TI ruckelfrei läuft. Die Qualität wird damit kaum beeinflusst, da Lanczos sehr gut skaliert und Debanding ohnehin nur geringe Auswirkungen hat.


    Code
    [50fps]
    profile-cond=get("estimated-vf-fps", -math.huge)>=50
    profile-restore=copy
    cscale=bicubic_fast
    scale=lanczos
    dscale=lanczos
    deband=no

    Hier noch ein Tipp: lanczos ist signifikant schneller (ca. Faktor 1,6 bei mir) als ewa_lanczossharp, ergibt aber im Direktvergleich keinen relevanten Unterschied. Ich habe mehrfach mit diversen Test- und Realbildern hin- und hergeschaltet und der Unterschied ist so gering, dass er die deutlich höhere Rechenlast nicht rechtfertigt. :)

    Kleiner Tipp: um genau herauszufinden, wie welcher Parameter wirkt, legt euch zwei Profile auf die Tastatur. Damit könnt ihr bei Testbildern oder Realfilmen direkt hin- und herschalten. Die Lernkurve ist damit extrem steil. :)


    input.conf:

    Code
    m apply-profile "an"
    n apply-profile "aus"


    mpv.conf:

    Code
    [an]
    profile-desc="an"
    #irgendeinen parameter einschalten
    
    [aus]
    profile-desc="aus"
    #irgendeinen parameter ausschalten

    fbo-format=auto

    Ja, 32 Bit Float haut extrem rein, was die Performance angeht (ca. Faktor 2 bei mir). Da würde ich bei 16 Bit Float bleiben. Ansonsten deaktiviere doch mal den Copy-Modus beim Dekodieren. Wofür hast du den drin?


    Ansonsten halte ich folgende Parameter für überflüssig, solange man nicht UHD auf HD runterskaliert (also beim Runterskalieren große Faktoren benutzt):

    Code
    correct-downscaling=yes
    linear-downscaling=yes
    sigmoid-upscaling=yes
    scale-antiring=0.6 # luma upscale deringing
    dscale-antiring=0.6 # luma downscale deringing
    cscale-antiring=0.5 # chroma upscale deringing

    Es kam ja die Frage nach der GPU-Dimensionierung auf. Ich habe in meinem Arbeits-PC einen Core i5 und eine Geforce 1050 TI. Also nichts Besonderes. Damit sieht die Auslastung wie folgt aus.


    Grundeinstellungen:

    • Hardwaredekodierung
    • Zielauflösung ist immer 3840x2160
    • Debanding aktiv
    • Dithering aktiv ("fruit")



    UHD / HDR / 60 FPS

    Ohne Skalierung:

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 9 ms


    Runterskaliert auf 2,35:1 für 2,4:1-Leinwand (CIH)

    ew_lanczos_sharp:

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 15 ms (reicht nicht mehr ganz aus)


    mitchell:

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 10 ms



    UHD / HDR / 23,976 FPS

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 10 ms


    Runterskaliert auf 2,35:1 für 2,4:1-Leinwand (CIH)

    ew_lanczos_sharp:

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 19 ms


    HD / SDR / 23,976 FPS

    ew_lanczos_sharp:

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 11 ms


    FSRCNNX_x2_8-0-4-1.glsl:

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 18 ms



    Und zu guter Letzt anamorphe Vorverzerrung, runterskaliert auf 2,35:1 (CIH), Warping für gekrümmte Leinwände, FSRCNNX 8, SSimDownscaler und ew_lanczos_sharp:

    pasted-from-clipboard.png

    Renderzeit pro Bild: ca. 30 ms



    Wie man sieht kommt es sehr darauf an, was wie skaliert wird und wie oft. Man kann da mit Profilen viel optimieren. Z.B. kann man gewisse Dinge bei 60 FPS einfach abschalten, wenn nötig. Solche Filme gibt es ohnehin kaum. Zur Not kann man auch noch die Dekodierung der CPU überlassen, aber viel bringt das nicht. Grundsätzlich kann man jedenfalls sagen, dass man mit mittelmäßiger Hardware hervorragend Filme schauen kann und sich nicht relevant einschränken muss.



    Und hier noch mal ein Beispiel, wie gut FSRCNNX_x2_8-0-4-1 funktioniert. Die 1080p-Version des bekannten Bildes wurde auf 2160p hochskaliert. FSRCNNX verdoppelt übrigens immer die Auflösung. Alle nicht ganzzahligen Skalierungsfaktoren werden automatisch durch den in mpv.conf eingestellten SKalierungsalgorithmus korrigiert. Daher kommt doch noch mal Rechenzeit dazu, wenn man für CIH runterskaliert.


    ew_lanczos_sharp:

    pasted-from-clipboard.png


    FSRCNNX_x2_8-0-4-1:

    pasted-from-clipboard.png

    Und? Lohnt es sich Deiner Meinung nach?

    Tja, da ich die Abweichung meines Exemplars zu einer Referenz nicht kenne, kann ich das nicht wirklich beantworten. Es gibt bei meinem beiden Sensoren jedenfalls Unterschiede in den RGB-Werten und in den Koordinaten von Grün und Rot.



    Da nicht Mule sondern Du auch den X7900 hast, hättest Du vielleicht mal das CIE Diagramm, wenn Du Rec709 Testbilder manuell bei einer Messung zuspielst und 3DLut bei madVR bzgl. SDR hinterlegt und aktiv ist?

    Würde mich mal interessieren, ob diese dann im Rec709 CIE Bereich liegt oder wegen der Nutzung des DCI Filters des X7900, außerhalb sprich etwas erweitert als Rec709.

    Ich nutze den DCI-Filter aktuell nicht. Aber die Koordinaten mit einer durch DisplayCAL erstellten 3D-LUT passten bei BT.709 immer ziemlich gut. Eine Messung habe ich nicht gespeichert. Müsste ich nachreichen.


    Darf ich fragen wie Du das machst? :think:

    Mit CalMAN kann man den TPG direkt ansteuern und dieser kann dann auch die hinterlegte LUT benutzen. Man kann somit den Zielfarbraum umschalten beim Messen. Für DisplayCAL ist das egal. Das profiliert ja nur das Anzeigegerät und erzeugt aus diesem Profil am Ende eine 3D-LUT für den Quellfarbraum, also BT.709 oder DCI-P3.

    Weil @((( atom ))) die Option --video-sync in dem anderen Thread erwähnt hat und bereits Capture-Karten ins Spiel kamen, möchte noch mal etwas zu der Audio/Video-Synchronisation im Allgemeinen erzählen.



    Das Problem ist seit Anbeginn der Zeit dasselbe. Es gibt verschiedene Taktgeber in einem PC und diese Optionen gehen verschieden damit um.


    Bei reiner Wiedergabe gibt es zwei Takte, einen für das Bild und einen für den Ton. Die sind leider nicht synchron und diese Asynchronität variiert auch noch mit den Bildparametern (Pixeltakt usw.). DirectShow unter Windows (und auch MPV) geben standardmäßig Audio den Vorzug, das heißt Bilder werden entsprechend wiederholt oder weggelassen, um die Synchronität beizubehalten. Weil Miniruckler nervig sind, wurde damals ReClock entwickelt, das das Ganze umdreht und dem Bild den Vorzug gibt. ReClock konnte bei analoger Tonausgabe entweder Resampling durchführen oder bei S/PDIF einzelne Samples wiederholen/auslassen. Letzteres war hörbar. Genau diese Optionen bietet MPV auch.


    Die Möglichkeiten zusammengefasst:

    • Ton ist führend, Bild wird korrigiert (Frames wiederholen/weglassen)
      • (es gab unter Windows mal eine Variante, die den Pixeltakt zur Laufzeit korrigiert hat. Das hatte aber selbst bei Röhrenprojektoren ein kurzes Nachsynchronisieren zur Folge und funktionierte daher nicht gut)
    • Bild ist führend, Ton wird korrigiert (Resampling oder Samples weglassen/wiederholen)
    • Bild und Ton laufen unabhängig vor sich hin und es wird irgendwann asynchron


    Die beste Variante war schon immer, die Asynchronität möglichst klein zu halten und Korrekturmaßnahmen innerhalb eines Films komplett zu vermeiden. Wie oben geschrieben, ist die Asynchronität zwischen Audio und Video bei jedem Pixeltakt etwas anders. Bitmonster aus Beisammen (ich habe noch Kontakt zu ihm) hat damals extra ein Tool entwickelt, dass mittels Powerstrip den optimalen Pixeltakt unter allen, von der Grafikkarte unterstützten, heraussucht. Hat man seine Auflösung so optimiert, konnte man teilweise >24 h ohne einen einzelnen Frame Drop/Repeat schauen! madshi hat sowas ähnliches dann in madVR implementiert und das hier dokumentiert.

    Das ist der Königsweg und der war bei Röhrenprojektoren perfekt umsetzbar, da die einfach alle Pixeltakte sehr gnädig akzeptiert haben. Leider ist das bei digitalen Projektoren nicht immer so einfach. Viele Pixeltakte werden einfach nicht akzeptiert und das Bild bleibt schwarz.


    Wie stark die Asynchronität ist, zeigt madVR übrigens an:

    pasted-from-clipboard.png


    MPV zeigt auf der Kommandozeile je nach Synchronisationsmodus auch etwas an, mit dem ich aber bisher weniger anfangen konnte (zumal der Wert bei jedem Start anders ist):

    pasted-from-clipboard.png



    So viel zu der Wiedergabe von Videos auf einem Rechner. :)


    Wenn dann noch eine Capture-Karte dazu kommt, bekommen wir einen dritten Takt, nämlich den des angeschlossenen Quellgerätes. Das, was dann idealerweise passieren muss, nennt sich Genlock. Der Takt der Videoausgabe wird an den Takt der Videoeingabe angepasst. Das machen Standalone-Videoprozessoren z.B. so. Das sind aber keine PCs mit verschiedenen Takten und wurden gleich so entwickelt. Ich weiß nicht, wie der Envy das macht. Bei NVIDIA konnte ich zumindest herausfinden, dass die Quadros Genlock unterstützen. Aber so weit ich weiß, sind im Envy keine Quadros verbaut.

    Wenn man das ohne Genlock laufen lässt, wird die Asynchronität zwischen Capture- und Grafikkarte irgendwann zu wiederholten oder verworfenen Bildern führen, also Miniruckler. Man könnte die Asynchronität sicherlich auch per zeitlichem Blenden ausgleichen, also das, was bei madVR als "Smooth Motion" bekannt ist. Die Frage ist, wie stark man das bei sehr ähnlichen Bildraten sieht.


    Jedenfalls bringt eine Capture-Karte eine Variable mehr ins Spiel, die man nicht vernachlässigen sollte. Ich denke, da kann man schon einiges an Zeit drin versenken, bis das richtig sauber läuft.

    Ich habe es inzwischen in einem Prototypen geschafft, den Desktop zu warpen. Damit wäre auch das GUI verzerrt. Leider ist durch den Shader nur die Grafik betroffen, nicht aber der Cursor und die Koordinaten für das Klicken (z.B. auf Buttons). Das ist natürlich dann so mit der Maus kaum bedienbar. Für Video, Untertitel usw. reicht es aber.


    Der große Vorteil der nachträglichen Verzerrung ist, dass die anamorphe Verzerrung und der Zoom vom Player erledigt werden können. Das hat dann zur Folge, dass auch kleiner gezoomte Bilder korrekt in der Krümmung abgebildet werden. Das klappt zwar auch, wenn der Shader in MPV alles auf einmal macht, aber dort fehlt momentan die Automatisierbarkeit.


    Ich denke noch mal darüber nach, was eigentlich die beste Lösung wäre...