Falls Du mich bzw. meinen "Fall" damit meinst, habe ich mich wohl misverständlich ausgedrückt:
Alles klar. Dann ist "mein" Problem wohl ein anderes gewesen. 
Beiträge von FoLLgoTT
-
-
Ich bin auch über das Beenden von aufgerufenen Prozessen im End-Event gestolpert. Mit os.execute() passiert das nicht. Eine andere Alternative ist, den Parameter playback_only=false bei
mp.command_native_async() setzen. Dann der Prozess nicht mit in den Abgrund gerissen.
entschuldigt, ich bin noch neu, gibt es hier irgendwo einen Thread für Anfängerfragen oder soll ich das hier machen? z.B. verstehe ich den Post von dem User "FoLLgoTT" nicht.
Ich empfehle dir, erstmal ein paar Wochen quer im Forum zu lesen. Für CIH habe ich z.B. hier etwas geschrieben. Dann sollte das klarer werden.
-
Wie versprochen hier noch ein paar Screenshots zu SSimDownscaler. Man achte vor allem auf die feinen Details wie die Geländer der Balkons am rechten Gebäude oder die schrägen Kanten des linken Gebäudes.
Zoom = -1 (entspricht UHD -> HD):
Lanczos:
SSimDownscaler:
Zoom = -0.434 (entspricht 16:9 auf einer 2,4:1-Leinwand):
Lanczos:
SSimDownscaler:
Zoom X = -0.434 (entspricht 16:9 auf einer 2,4-Leinwand mit Anamorphot):
Lanczos:
SSimDownscaler:
Wie man sieht verringert sich der Unterschied mit kleinerem Zoomfaktor. Mit Anamorphot sehe ich zwischen Lanczos und SSimDownscaler auch beim (quasi verzögerungsfreien) Umschalten keinen Unterschied mehr. Darüber hinaus allerdings schon. Für diejenigen mit 2,4:1-Leinwand also eine Verbesserung bei den kleineren Formaten und für die, die auf HD runterskalieren sowieso.
PS: ich musste den Shader anpassen, damit er mit Anamorphot überhaupt aktiv wird, da er auf die Höhe reagiert hat und nicht auf die Breite.
-
versuch mal das mit SSimDownscaler.glsl zu kombinieren
Den hatte ich auch umfangreich getestet und bin zu dem Schluss gekommen, dass sich SSimDownscaler nur bei großen Skalierungsfaktoren lohnt (z.B. UHD auf HD). Bei meinen ist praktisch kein Unterschied im Direktvergleich erkennbar, also spare ich mir die Rechenlast und benutze Lanczos dafür.
Ich kann gerne noch mal Screenshots von SSimDownscaler machen, wenn gewünscht.
-
Schön zusammen gefasst. Volle zustimmung.
Mit Hilfe des Auflösungs/Refresh Scripts + JVC Steuerung wechselt man die Auflösung auf 3840x2160 und deaktiviert Anamorphic mode, wenn man einen Film startet
Mit dem Unterschied, dass ich nicht den Projektor habe skalieren lassen, sondern den Grafikkartentreiber. Also mit folgenden Einstellungen:
und
Den Anamorphic-Mode im Projektor braucht man dann gar nicht. Für den Auflösungswechsel auf dem Desktop macht das aber keinen Unterschied. Der reorganisiert sich dann auch neu.
Bei SDR wird bei mir übrigens auch mehrfach skaliert, da ich FSRCNNX einsetze. Also erst wird die Auflösung verdoppelt und dann per Lanczos auf das verzerrte und gezoomte Ziel skaliert. Ich habe das ausführlich getestet und FSRCNNX sieht selbst damit deutlich besser aus als nur mit Lanczos. Also danke auch noch mal an dich für den Tipp ganz am Anfang in diesem Thread!
-
deine Screenshots sehen gut aus, hast du das auch mit chanticos config eingestellt?
Du meinst die Konfiguration, die er unter anderem mit meiner Hilfe erstellt hat? Nein.
-
Vorteil: das geht dann mit jedem Bildinhalt (z.B. Desktop) und nicht nur mit mpv
Auch eine interessante Lösung.
Allerdings gibt der Player dann nicht die volle vertikale Auflösung aus, sondern immer nur 74 % davon. Und man hat die vertikale Skalierung nicht in eigener Hand, sondern überlässt sie der Grafikkarte. Im Direktvergleich kann man das bei hochauflösenden Bildern, die in 16:9 wiedergegeben werden (also der Worst Case), sehen.
Runterskaliert wurde mit Lanczos. Das sind Ausschnitte von Buroschs Hamburg-Testbild. Die merkwürdigen Regenbogenfarben entstehen durch die Interferenz zwischen Kamera und LCD-Monitor. Das sieht so natürlich nicht aus.
Vertikal 1600 (Grafikkartentreiber skaliert auf 2160):
Vertikal 2160 (MPV skaliert komplett):
-
Hier noch mal meine Lösung für eine CIH-Projektion auf eine 2,4:1-Leinwand mit einem Anamorphoten (siehe auch hier).
In der mpv.conf habe ich fest die Vorverzerrung für den Anamorphoten drin:
In einem Script lese ich dann aus meinen Metadaten am Film das Seitenverhältnis aus und wende einen festen Zoom an. Der Zoom in MPV ist etwas trickreich, da er logarithmisch zur Basis 2 eingegeben werden muss. Mit folgender Formel kann in LUA der notwendige Zoom für kleinere Seitenverhältnisse errechnet werden, wenn der Anamorphot immer im Lichtweg bleibt. LUA unterstützt leider nur den Logarithmus Naturalis, also muss man umrechnen. Aber das ist kein Problem:
zoom = math.log(Zielseitenverhältnis / 2.4) / math.log(2)
Man kann das Ganze auch in dynamic_crop.lua einbauen. Dann ersetzt man die Zeile
durch
Codeif current.w / current.h <= 2.4 then mp.set_property("video-zoom", math.log(current.w / current.h / 2.4) / math.log(2)) endDie Maskierung kann man dann im gleichen Zuge ansteuern, sofern man eine motorisierte hat.
Ergebnis:
-
Verstehe ich das richtig, du bräuchtest das damit du so hell oder dukel machen kannst wies dir gefällt?
Ich brauche das mit hoher Wahrscheinlichkeit gar nicht. Aber man kann es tun. Es wäre in Grenzen machbar.
PS: "Rendering Intent" ist hier das Stichwort.
-
Eigentlich bräuchte man eine Art "Loudness" für die Sättigung. Bei hoher maximaler Leuchtdichte müsste sie die unteren Stufen entsättigen und bei niedriger das Gegenteil, um unsere Wahrnehmung auszugleichen. Dasselbe könnte man für für andere leuchtdichteabhängige Parameter auch tun. Per Shader wäre das am HTPC problemlos machbar und eine Sache von ein paar Stunden.
-
Bei SDR waren mir die 40 ... 45 FL in der Barco Freya Vorführung definitiv zu hell und da überwiegen für mich die Nachteile -
Welche Nachteile meinst du?
Falls es dir um dunkle Szenen geht: es geht in diesem Thread ja nur um die maximale Leuchtdichte und nicht um den Kontrast. Wenn wir nur über diesen Wert diskutieren, dann sollten wir in der idealisierten Welt bleiben und den Schwarzwert gedanklich konstant (niedrig) halten. Dass die Realität ggf. anders aussieht, ist klar. Das ist aber aus meiner Sicht eine ganz andere Diskussion.
PS: ich habe mal einen Röhrenprojektor auf Gain 2,8 mit fast 40 fL gesehen und da gab es dank dem extrem hohen An/Aus-Kontrast gar keine Nachteile (zumindest nicht in Bezug auf die Leuchtdichte).
-
natürlich hilft uns die schwelle für das tagsehen, da die empfohlenen werte darüber liegen und wir somit aus den fliesenden übergängen raus sind.
Die empfohlenen Werte beziehen sich auf Weiß. Das Bild kann aber alle Stufen zwischen Schwarz und Weiß enthalten. Das heißt, mit jeder Referenzweißempfehlung befinden sich mehr oder weniger Stufen im Bereich des Nachtssehens. Also befinden wir uns grundsätzlich immer in dem Bereich des Übergangs.
Je höher das empfohlene Weiß, desto weniger Stufen fallen dort rein. Und umgekehrt: je höher das Weiß, desto mehr Stufen fallen ins Tagsehen.
die wahrgenommene sättigung hängt eben sehr stark mit dem gesteigerten kontrast empfinden zusammen und hat nichts damit zu tun das die farben wirklich mehr gesättigt sind.
Das hat auch keiner behauptet.
das ganze steigere ich aber bei einer projektion nicht ins unendliche wenn ich einfach mit mehr licht ballere, irgenwann gibt es nachteilige effekte.
Das ist klar. Aber 100 Nits sind eben nicht das Ende des sinnvollen Bereichs. Und die 16 fL (54 Nits), die jahrelang im Kino galten, stellen eher die untere Grenze dar.
-
Die Schwelle für Tagsehen kann keine sinnvolle Metrik für eine Referenzleuchtdichte sein, denn zum einen ist sie fließend und zum anderen ist bekannt, dass die wahrgenommene Sättigung mit der Leuchtdichte ansteigt (Hunt-Effekt). Gleiches gilt für den wahrgenommen Kontrast (Stevens-Effekt). Und nicht zuletzt befinden sich alle Stufen < 5 % nicht im Tagsehen (wenn man den Schwellwert als feste Grenze sehen würde).
Wie auch immer, es gibt für die SDR-Leuchtdichte nach wie vor im Konsumerbereich keinen Standard. Und ich vermute, dass in die Kinostandards auch stark die technologischen Grenzen bzw. Kosten eingeflossen sind. Daran muss man sich also nicht orientieren, wenn man es besser machen kann.
-
Gestern gab mir ((( atom ))) noch folgenden Tipp für die Strukturierung der verschiedenen Konfigurationsteile: man kann mit "include=" auf andere Konfigurationen referenzieren. So könnte man z.B. die Linux- und Windowsspezifischen auslagern. Oder auch Bitstreaming und Dekodierung usw.
Natürlich kann man den Parameter auch über die Kommandozeile anwenden.
-
Damit wird empfohlen, dass ein Referenzmonitor eine Leuchtdichte von 100 cd/m² besitzt, um darauf Filme in SDR zu mastern.
Genau, es wird nur empfohlen. Möglicherweise hat sich das auch irgendwann als de-facto-Standard beim Mastering durchgesetzt, im Heimbereich gab es aber nie einen echten Standard für die Leuchtdichte. Mal abgesehen davon, dass BT.1886 16 Jahre nach DVD- und 9 Jahre nach der Blu-ray-Einführung veröffentlicht wurde. Es handelt sich also quasi nur um eine Nachbesserung, die keiner im Heimbereich einhalten muss und in der Regel auch nicht tut.
Im Grunde ist das komplette Konzept der Referenzleuchtdichte sehr fragwürdig, denn es kommt immer auf das Umgebungslicht an. Man kann also gar nicht für TVs unter Tageslichtbedingungen dieselbe Referenzleuchtdichte wie für eine Projektion im schwarzen Keller festlegen. Genau das macht aber der HDR-Standard. Er differenziert mit seiner absoluten EOTF nicht. Das ist genauso sinnfrei wie krampfhaft die Referenzlautstärke unter allen Bedingungen einzuhalten.
-
Siehe Signatur, aber Willkommen im Nebenkriegsschauplatz, lasst euch aus, dafür ist er da.
Was stimmt mit dir nicht?
-
-
na klar, ich heiße ja nicht wie jemand, der mit A anfängt und mit m aufhört.
Solche Kommentare sind richtig unverschämt. ((( atom ))) verdankst du es überhaupt erst, dass du den Player am Laufen hast. Ohne ihn wäre hier keiner darauf aufmerksam geworden. Also bitte etwas mehr Respekt.
-
Chanticos config läuft z.B. bei mir auch nicht 1:1 (unter Win) das fbo Format schmeckt ihm nicht und er schaltet die Shader ab ...k.a. warum...
Man muss im Grunde gar kein fbo-format angeben. Der Default ist sowieso 16 Bit float und es wird automatisch der passende ausgesucht:
Default: auto, which first attempts to utilize 16bit float (rgba16f, rgba16hf), and falls back to rgba16 if those are not available. Finally, attempts to utilize rgb10_a2 or rgba8 if all of the previous formats are not available.Das ist es ja gerade, für eine Standardkonfiguration kommt man mit relativ wenigen Parametern aus, weil viele schon sinnvoll gesetzt sind. Jeder Parameter der unnötig gesetzt wird, macht es unübersichtlicher und verwirrt.
Windows und Linux unterscheiden sich praktisch nur in der Ausgabe von Bild und Ton, also Direct3D, WASAPI usw. Der Rest kann identisch sein.
Ich würde das so aufbauen, dass ich eine einfache Standardkonfiguration als Basis erzeugen würde. Quasi ein gemeinsamer Nenner. Spezialfälle könnte man dann als Parameterblöcke gesondert dokumentieren. Diese z.B.:
- Farbmanagement
- CIH (Auto-Crop, Auto-Zoom, Projektoransteuerung usw.)
- Warping für gekrümmte Leinwände
- Dekodierung von Audio (die meisten werden Bitstreaming benutzen)
- usw.
-
Ich hatte das dynamic-crop.lua mal ausprobiert. Leider ist der cropdetect-Filter in FFMPEG ziemlich unperformant, wenn das Bild sehr dunkel ist oder sogar schwarz. Mir ist das bei einigen Szenen in "The Expanse" aufgefallen und ich kann es mit einem Schwarzbild (->Teststream von Mehanik) provozieren. Dann entstehen Framedrops.
Wenn man sich den Quellcode anschaut, dann sieht man, dass der Algorithmus immer bis zur gegenüberliegenden Kante sucht, wenn er keinen Wert über dem Schwellwert findet. Dementsprechend dauert es länger. Für unsere Zwecke, nämlich schwarze Balken ausschließlich vertikal und immer symmetrisch, würde eine Analyse an der Unter- oder Oberkante reichen und dann auch nur bis 2,76:1 z.B. Das wäre deutlich performanter.
Ich muss noch mal darüber nachdenken. Bisher habe ich auch keinen Weg gefunden, dass ein Shader Daten irgendwohin liefert. Falls da jemand eine Idee hat, immer her damit.
