OLED - Die Zukunft?

Lostion (Beitrag #13405) schrieb:

SSDs?

Dann kommst mit deine 50 Eus aber wieder nicht hin.

Du glaubst doch nicht ernsthaft, das Samsung die Dinger für mehr als 50 € herstellt?

Herstellen tut LG den 65 EG auch nicht für 8,9k.
Da gehört ja auch noch ein wenig mehr dazu wie nur die SSD. Da brauchts erteinmal ne schnelle Schnittstelle und genügend Rechenpower und das in einem Tv? Never. Wie stellst dir das eigentlich vor? Ich stell dann auf Familien im Brennpunkt und dann dreht erstmal 20 Minuten die Eieruhr?

Ich weiß nicht, mir kommt das Puffern unrealistisch vor. Viele wollen den Knopf drücken und gleich fernsehen. Da sind bestenfalls ein paar Sekunden als Puffer akzeptabel.

Was genau hat man an meinem Beitrag nun nicht verstanden, das man 3 Optionen haben sollte? Habs doch erklärt in den Beiträgen vorher.

Heutzutage werden YT Videos weggeklickt wenn sie erst nach 5 Sekunden laufen und da kommst du mit 20 Minuten. Mal davon abgesehen, dass es gar nix bringt.

Was interessiert einem die breite Masse? Die kann ja Option 1 wählen und fertig? Natürlich würde es was bringen, weil die frames eben 2-3 mal durchgegangen werden würden und nicht nur einmal. Was denkst du wie sowas in der Postproduktion abläuft? Meinste die setzen sich da hin und sagen "Och ja heute hab ich aber keine Lust auf Color Shading, hauen wir eben Filter XYZ rein und aus die Maus" also sorry aber manchmal.

Lostion (Beitrag #13414) schrieb:

Was denkst du wie sowas in der Postproduktion abläuft? Meinste die setzen sich da hin und sagen "Och ja heute hab ich aber keine Lust auf Color Shading, hauen wir eben Filter XYZ rein und aus die Maus" also sorry aber manchmal.

Okay, also ein 20 min Puffer und jemand von der Postproduktion. Alles klar.

In der Postproduktion kann man sich ja ruhig mehr Zeit lassen. Aber selbst dort investiert man keine Zeit in Zwischenbildberechnung.

Man könnte ja die Sender 50p in 100Hz wandeln lassen. Dadurch steigt schonmal die Bildschärfe wegen der geringen Haltezeit pro Frame und die Artefakten dürften weniger sein, wenn sie gute Hardware einsetzen. Viele haben das Motionflow eh aktiviert. Nur sehen dann Leute wie mich, die das nicht wollen, in die Röhre. Zudem ist die Datenrate für die Sender viel zu hoch, so dass man zu Lasten der Qualität stärker komprimieren muss.

20minuten ist uebertrieben und unsinnig. Vermutlich wuerden 5-10s schon reichen. 10s sind immerhin zwischen 240 und 600 einzelbilder. Die momentane Technik scheint nicht mehr als 5-10 zu benutzen. Eher waere vermutlich auch eine ganze Sekunde ausreichend, damit die Rechenleistung hinterher kommt. Bei dem richtigen Algorithmus wird das Problem sicherlich auch bei der Lizenz liegen. Denn es gibt ausreichend viele zur Berechnung nur darf die nicht jeder einfach nutzen.

sabberwurst (Beitrag #13404) schrieb:

Ich weiß ja nicht, wenn die 3 Ghz Quadcore Prozessoren immer noch Probleme haben, dann kann es an der Leistung eigentlich nicht liegen. Vor einigen Jahren hatte man vielleicht eine 800 Mhz Single CPU.

Ihr denkt da immer viel zu sehr in PC-Technik. Ein solcher TV hat eine Bildverarbeitung drin, die in Hardware realisiert ist, und schon jetzt locker mehr Rechenarbeit schafft als ein 3 GHz-Quadcore in Software. Die Chips, die da verbaut sind, heißen heute SoC (System on Chip), nicht mehr CPU, weil die CPU nur noch ein Bruchteil von dem ist, was in so einem SoC verbaut ist. Da gibt es dann beispielsweise im Embedded-Bereich oder in Smartphones SoCs, die Videodecoder drin haben, die drei Full-HD-Videos in Echtzeit decodieren, skalieren und auf einem Display darstellen können. Ruckelfrei! Das schafft selbst ein heutiger 3Ghz Quadcore-Prozessor im PC *nicht*. Klar kann ein PC das, aber nur, weil er dann auch entsprechende Hardware-Features der Grafikkarte zuschaltet. Er kann es aber nicht rein in Software durch die CPU.

Ihr denkt also in völlig falschen Dimensionen. Das heißt wenn es einen Algorithmus gibt, dann kann der heute durchaus in Form von Hardware auch sehr preisgünstig realisiert werden. Oder umgekehrt gesagt, wenn es noch nicht in Hardware verfügbar ist, dann wird so ein Algorithmus auch schwer zu finden sein.

Ich verstehe die Idee, die Ihr mit der Pufferung habt. Aber das Problem ist etwas anders gelagert. Warum ruckelt es momentan? Weil die Algorithmen nicht mehr erkennen können, ob es sich bei den Objekten aus verschiedenen Bildern noch um das gleiche Objekt handelt oder nicht. Im ersten Fall muss man das Objekt auf halber Strecke hinsetzen, im zweiten Fall kann man es nicht bearbeiten und es bleibt die Lücke im Zwischenbild. Eigentlich steht und fällt die Qualität der Zwischenbilder mit genau dieser Erkennung.

Dazu werden heute Verfahren eingesetzt, die in einem gewissen Umfeld einer Pixelgruppe nach Pixelgruppen suchen, die so ähnlich aussehen. Eigentlich kommen diese Verfahren aus der Videoencodierung, wo man dadurch Datenrate spart, indem man einer alten Pixelgruppe nur sagt, dass sich sie um 10 Pixel nach rechts und 2 Pixel nach oben verschoben hat, anstatt diese Pixelgruppe nochmal erneut abzuspeichern. Die Verschiebung braucht zwei Zahlen, die Pixelgruppe von sagen wir mal 8x8 Pixeln neu zu speichern braucht 64 Werte. Also spart man 62 Werte, wenn man so eine Verschieberichtung findet. Natürlich alles etwas vereinfacht gesprochen.

Sprich diese Verschiebungserkennung ist schon jetzt Teil jeder Videoencodierung. Und diese Verfahren werden bei den Zwischenbildern einfach wiederverwendet. Und dann wird im Zwischenbild die Pixelgruppe eben nur um 5 Pixel nach rechts und 1 Pixel nach oben verschoben. So einfach ist das im Prinzip. Der TV erkennt da nicht, dass es sich um einen Fußball oder ein Auto handelt was sich da bewegt. Er erkennt nur Pixelgruppen.

Je mehr sich aber die Pixelgruppe verändert, desto schwieriger wird es, sie noch als die gleiche Pixelgruppe zu erkennen. Wenn also der Fußball sich dreht und das Muster auf dem Fußball in eine andere Richtung zeigt, dann ist es schon viel schwieriger, diese Pixelgruppe im nächsten Bild wieder zu fiinden, denn sie sieht ja leicht anders aus. Das heißt bei der Zwischenbildberechnung muss man auch einen gewissen Unterschied tolerieren. Und hier wird es jetzt halt kitzlig. Toleriert man kaum Unterschiede, können viele Objekte nicht mehr gefunden werden, weil sie sich minimal verändert haben, und entsprechend gibt es für diese Objekte kein Zwischenbild. Und toleriert man zu große Unterschiede, wird auch mal eine Objekt als Ziel erkannt, das in Wirklichkeit ein ganz anderes Objekt ist. Und schon bewegt sich der Fußball im Zwischenbild in eine falsche Richtung und wir haben einen Fehler.

Die Algorithmen behelfen sich, indem sie oft mehr als nur ein Bild anschauen. Dann bekommt sozusagen jede Pixelgruppe, die als bewegtes Objekt in Frage kommt, eine Nummer. Und man schaut wohin sich das Objekt von Bild 1 zu Bild 2 bewegt und dann wieder von Bild 2 nach Bild 3 und von Bild 3 nach Bild 4. Und wenn da nun ein Ausreißer dabei ist, dann kann man den ggf. korrigieren. Wenn also z.B. die Bewegung bei drei Bildübergängen immer nach rechts geht aber in einem Übergang mittendrin nach oben, dann ist die Erkennung in diesem Schritt höchstwahrscheinlich falsch.

Wie nun unschwer zu erkennen ist, wird diese Erkennung immer schwerer, je weiter die Bilder auseinander liegen. Denn erstens sind die Objekte dann so weit voneinander weg, dass sie bei einer Suche "im Umfeld" nicht mehr gefunden werden. Und zweitens haben sich die Pixelgruppen dann schon so stark verändert, dass man sie kaum noch als das gleiche Objekt erkennen kann. Zum Beispiel der Ball hat sich weiter gedreht, die Beleuchtung und damit die Farbe hat sich durch die neue Perspektive geändert, das Objekt wird durch ein anderes teilweise verdeckt und hat nun eine andere Form, usw.

Das heißt noch mehr Bilder anzuschauen bringt vermutlich gar nicht viel. Wo das Puffern allerdings trotzdem was bringen kann, ist einfach, Zeit für die Berechnung zu gewinnen. Denn momentan wird oft optimiert, was die "Suche im Umfeld" angeht. So wird oft nur in die Hauptrichtungen (rechts, rechts unten, unten, links unten, links, links oben, oben, rechts oben) gesucht. Mit dem Effekt, dass Bewegungen nur erkannt werden, wenn sich das Objekt in eine dieser Richtungen bewegt. Sobald die Bewegung irgendwie krumm schräg ist, versagt die Bewegungserkennung. Ganz blöd wird es, wenn mal was erkannt wird und dann wieder nicht. Denn dieser Wechsel von "Bewegung mit Zwischenbild" zu "Bewegung ohne Zwischenbild" und umgekehrt ist dann das, was man als einzelne Ruckler wahrnimmt. Hätte man also mehr Zeit zu suchen, könnte man in noch mehr Richtungen prüfen und könnte dann vielleicht auch solche schrägen Bewegungen erkennen.

Insofern ja, puffern könnte was bringen, aber nicht weil man dann mehr Bilder zur Verfügung hat, sondern weil man dann genauer suchen könnte. Das heißt man würde mit 20min Puffer anfangen zu schauen und am Ende des Filmes hätte man den Puffer aufgebraucht. Aber ich denke man könnte einfach nur auch die Hardwareerkennung etwas aufbohren, dann hätte man das gleiche Ergebnis, aber in Echtzeit.

Wie so oft ist das aber eine Frage von Kosten und Nutzen. Wenn ein Ergebnis schon jetzt so gut ist und es nur ab und zu Fehler gibt, dann macht es keinen Sinn mehr, noch viel daran zu verbessern. Weil der Mehraufwand immens wird, die Verbesserung aber nur noch gering ist.

Gruß,

Hagge

Der Gedankenansatz von Lostion geht ja nicht davon aus, dass man mit 20 Minuten "Puffer" unglaubliche 28800 Frames (24p) zusammen analysieren soll. Das wäre komplett sinnfrei.

Der Gedankenansatz geht davon aus, dass bei einem 90-Minuten-Film eine Rechenkapazität von 90 Minuten zur Verfügung steht. Baut man einen "Puffer" von 20 Minuten ein, dann steht für 90-Minuten-Film eine Rechenkapazität von 110 Minuten zur Verfügung. Das wäre dann weniger sinnfrei. ;-)

Der Ansatz wäre mit ein wenig mehr Rechenleistung genauso und sogar effektiver zu lösen. Was wiederum nichts nutzt, wenn man keine besseren Algorithmen einsetzen kann.

Was die Hersteller über 2 bis 5 Frames (oder auch 24 Frames) nicht hinbekommen (oder aus Gründen der Kosteneinsparung nicht hinbekommen wollen), bekommen sie auch mit 20 Minuten Vorsprung nicht gebacken. Zusätzlicher Puffer zur Vermeidung von Fehlern bei MCFI. Ein netter, aber nicht zielführender Gedanke.

Servus

Der Ansatz von Lostion ist aber einfach nicht brauchbar am TV, denn der TV weiß nicht, ob man jetzt einen 90minuten Film anschaut oder einen Film über 3 Stunden oder eine Filmreihe über 24h. Wo will man die Grenze legen?
Genau das ist das Problem mit dem Puffer. Er wird eigentlich nur benutzt, um über eine größere Zahl von Bildern Berechnungen durchzuführen.
Momentan werden halt ganz einfache Filter benutzt, wie Hagge schon erwähnt, die nur horizontale, vertikale und 45° bzw. -45° Bewegungen erkennen. Das sind Algorithmen die man glaube seit mitte der 90er für die Erkennung von bewegten Objekten in Videos verwendet und deren Bewegungsrichtung. Es gibt da komplexere und bessere Methoden. Wichtig ist z.B. auch eine Erkennung wenn ein Szenen bzw Kamerawechsel stattfindet. Ist dieses nämlich nicht der Fall passieren gerne diese Fehler wie abgetrennte Arme, da der TV in der nächsten Szene den Arm wiedererkennt und ihn in der Zwischenbildberechnung z.B. von links nach rechts im Bild wandern lässt.
So Berechnungen gibt es und auch recht gute, aber die sind halt meist Lizenztechnisch gesichert.

Die Zwischenbildberechnung von den meisten TVs die ich gesehen habe, kannst du eigentlich immer in die Tonne kloppen, wenn man keine perfekt lineare Bewegung hat, denn diese ziehen im Prinzip nur eine Linie von einem zum nächsten Frame. Maximale 2-5 Frames. Dieses reicht häufig leider nicht aus eine natürliche Bewegung zu erkennen und nachzubilden, denn Armbewegungen sind nicht linear. Wir bremsen ab. Dazu können wir uns nur in "Rundbahnen" bewegen. Wir haben im gesamten Körper (Zunge mal aussen vor) keine gebilde, die eine Linearbewegung erlauben.

Lostion (Beitrag #13414) schrieb:

Was interessiert einem die breite Masse? Die kann ja Option 1 wählen und fertig?

Na dann ruf mal bei LG an, ob die dir DEINEN TV bauen, glaube aber eher nicht. LG und auch den anderen, interessiert nämlich genau die breite Masse, da sie ja Massenprodukte herstellen.

BigBubby (Beitrag #13420) schrieb:

Der Ansatz von Lostion ist aber einfach nicht brauchbar am TV, denn der TV weiß nicht, ob man jetzt einen 90minuten Film anschaut oder einen Film über 3 Stunden oder eine Filmreihe über 24h. Wo will man die Grenze legen?

War ja auch nur ein Rechenbeispiel von mir.
Der Grundgedanke eines Puffers ist im Allgemeinen, dass er wieder aufgefüllt wird, wenn weniger "zu tun" ist. Er soll nur "Engpässe" temporär überbrücken.

Aber meinerseits genug mit dem unseligen Puffer.
Es gibt sinnigere Themen als das.
Und mit "OLED - Die Zukunft" hat es auch nichts zu tun.

Servus

Ein letztes Statement würde ich auch gerne noch loswerden.

Ein Puffer von ca. 5Sekunden würde völlig ausreichen, wenn die Berechnung schnell genug ist.
1. 5 Sekunden Film laufen in den Puffer
2. Diese 5 Sekunden Film werden INTENSIV bearbeitet, wobei die Bearbeitungszeit unter 5 Sekunden liegen muss
3. Exakt 5 Sekunden später werden die bearbeiteten 5 Sekunden ausgegeben.
4. Zeitgleich wandern die nächsten 5 Sekunden in den Puffer.
Und weiter geht's mit
2:
3:
4:
2
3
4

Auf diese Weise gibt es keinen überlaufenden Puffer oder irgendein Aufholen oder sonstwas!

Also theoretisch durchaus realisierbar.

Mir geht es ausschließlich darum, die Zwischenbildbetechnung zu verbessern und Fehler zu reduzieren, damit evtl. mehr User diese nutzen würden.
Komplett beheben lassen werden sich die Fehler vermutlich nie, aber eben doch etwas reduzieren.
Und das ist in Echtzeit schwieriger als in 5 Sekunden.

phoenix0870 (Beitrag #13423) schrieb:

Und das ist in Echtzeit schwieriger als in 5 Sekunden.

Dein Beispiel ist für mich Echtzeit-Verarbeitung.
Es müssen 5 Sekunden Film in <= 5 Sekunden aufbereitet werden.

https://de.wikipedia.org/wiki/Echtzeit

Aber ich weiß was Du meinst.

Servus

Ich glaube meinen letzten Satz können wir ignorieren!

phoenix0870 (Beitrag #13423) schrieb:

Auf diese Weise gibt es keinen überlaufenden Puffer oder irgendein Aufholen oder sonstwas!

Was gewinnst Du durch diese 5 Sekunden? Du musst doch dann trotzdem alles in Echtzeit berechnen, da Du zu jedem Zeitpunkt nur 5 Sekunden Verarbeitungszeit für 5 Sekunden Film hast. Wenn es länger dauert, ist die Anzeige der vorangegangenen 5 Sekunden schon durch, bevor von den aktuellen 5 Sekunden Nachschub kommt, d.h. es gibt eine Pause.

Was ist dann der Vorteil von diesen 5 Sekunden? Wie gesagt, die Bewegung wird an wenigen Frames festgemacht und ein größerer Abstand führt dann nicht mehr zu einem verbesserten Verhalten, weil die Objekte dann gar nicht mehr gefunden werden.

Gruß,

Hagge

Ich gewinne eine ganze Menge!

Auch aktuell muss es schon einen kleinen Puffer geben, damit das erste und das zweite Bild verglichen werden können.

Ablauf in meiner Vorstellung :
1 Erstes Bild in den Puffer
2 Zweites Bild in den Puffer
3 Vergleichen und mit Zwischenbild ausgeben,
während drittes und viertes Bild in den Puffer geladen und verglichen werden.
Etc
Etc

Gibt es nun eine Störung im Bild, so gibt es keine Möglichkeit diese zu korrigieren.

Bei einem Puffer von 5 Sekunden, können kleine Fehler direkt korrigiert werden, wenn man davon ausgeht, dass die Berechnung für die 5 Sekunden höchstens 3 Sekunden dauert.
Mit entsprechend großem Puffer könnten Fehler also minimiert werden, bevor sie angezeigt werden.

Wenn ich mit einem Videobearbeitungsprogramm Fehler suchen und korrigieren lasse, dauert das bei einem 90 Minuten Film vielleicht 10 Minuten.

Die Analyse und Korrektur geht normalerweise schneller als in Echtzeit, wodurch man, bei einem etwas größeren Puffer Luft für Problemstellen bekommen könnte.
Ohne genügend Vorlauf wird es schwierig.

Und jetzt muss ich weiterarbeiten.

5 sec müssen es nicht mal sein. Aber ~1 sec sollte es schon sein und nicht nur 1-2 frames. Dieses braucht man, um komplexere Bewegungen als eine lineare passend interpolieren zu können, denn sonst sieht es aus, wie es heute aussieht. IFC ist z.B. eine Katastrophe, wenn du nicht perfekt gerade Bewegungen amcht, wird es falsch interpoliert und deshalb hat man unnatürliche Bewegungen, die "beschleunigt aussehen", denn statt das reale Abbremsverhalten bei Bewegungen darzustellen, verlaufen diese plötzlich komplett linear und so bewegt sich aber in der Natur nichts. Selbst Roboter machen dieses nicht. Die haben auch erst eine Beschleunigungs und am Ende eine Bremsphase.

Streng genommen reichen aber schon 3 Frames, um über lineare Interpolationen hinauszukommen

Ein Frame ist eigentlich nur ein Rahmen, warum heißt es nicht Picture

Nui (Beitrag #13429) schrieb:

Streng genommen reichen aber schon 3 Frames, um über lineare Interpolationen hinauszukommen :P

An sicht hast du recht, aber guck dir mal an, wieviele unterschiedliche Geraden du mit drei Punkten darstellen/abtasten kannst ;-)

Die ganze Puffer geschichte ist hinfällig wenn ein TV eine gute zwischenbildberechnung aufweißt , sehe keine vorteile darin !

sabberwurst (Beitrag #13430) schrieb:

Ein Frame ist eigentlich nur ein Rahmen, warum heißt es nicht Picture :?

Scheinbar aus historischen Gründen: https://en.wikipedia.org/wiki/Film_frame

[...] the single images have been recorded on a strip of photographic film that quickly increased in length, historically; each image on such a strip looks rather like a framed picture when examined individually.

pa-freak1 (Beitrag #13432) schrieb:

Die ganze Puffer geschichte ist hinfällig wenn ein TV eine gute zwischenbildberechnung aufweißt , sehe keine vorteile darin !

Du hast schon verstanden, dass es um die Zwischenbildberechnung geht und diese nur gut sein kann, wenn ein paar Bilder gepuffert werden? Schließlich braucht der TV Material, aus denen er Bilder berechnen kann.

2 Bilder müssen ja gepuffert werden, sonst kann er gar keine Zwischenbilder berechnen. Bringt es für diese 2 Bilder dann etwas, wenn noch weitere, nachfolgende Bilder gespeichert werden? Eigentlich müssten ja nur ein gescheiter Algorithmus ansehnliche Bilder als Zwischenschritte eines bewegten Punktes berechnen. Nur fällt mir gerade auf, dass eine Bewegung über 2 Frames hinweg sehr schnell sein kann, dass eine lineare Berechnung sehr auffallen würde. Also müsste man schon einige Frames einbeziehen, um die möglichst richtigen Bewegungsabläufe zu erfassen.

Ich stelle mir ein Bild mit Millionen Bildpunkten und bis zu 100.000en Details dermaßen komplex vor, dass es fast an ein Wunder grenzt, das überhaupt bei manchen Hersteller relativ flüssig klappt ohne ständige Artefakte. Die Datenrate die pro Sekunde bewältigt werden muss, ist ja auch nicht zu verachten.

@BigBubby
Ein parr schon das er er ein vernünftiges bild zwischen zwei bilder auf die reihe kriegt aber das mehrere minuten vorauspuffern halte ich für schwachsinn.
Die Bildprozessoren sind ja schnell genug für dies heutzutage , scheitert bei manchen nur an der software.
Ich kann mir kaum vorstellen das der bildprozessor des EC930V zu langsam oder auf zu wenig zwischenspeicher zurückgreifen kann für die zwischenbildberechnung.
Hier fehlt es ja eindeutig an programmierkenntnise und erfahrung.
Ein Sony TV aus 2012 hatt kaum einen leistungsstärkeren Bild Prozzesor an board aber trotzdem einen bessere bewegungsinterpolation.

sabberwurst (Beitrag #13435) schrieb:

2 Bilder müssen ja gepuffert werden, sonst kann er gar keine Zwischenbilder berechnen. Bringt es für diese 2 Bilder dann etwas, wenn noch weitere, nachfolgende Bilder gespeichert werden? Eigentlich müssten ja nur ein gescheiter Algorithmus ansehnliche Bilder als Zwischenschritte eines bewegten Punktes berechnen.

Nimmst du nur 2 Bilder als Berechnungen ist die Interpolation stark eingegrenzt. Betrachte folgendes Beispiel mit einem bewegten Punkt (in Grün). Wenn du paarweise versucht Bewegung zu interpolieren, hast du eigentlich keine Wahl außer gerade Strecken zu laufen. Mit 3 Punkten kannst du hingegen Kurven annehmen.


Das basiert alles natürlich auf Annahmen und es sollte auch klar sein, dass eine Bewegungsinterpolation nicht immer die korrekte Bewegung bestimmen kann, dafür fehlen einfach Informationen.

Ist zwar theoretisch richtig/wünschenswert, aber ich bin mir ziemlich sicher dass es keine Engine gibt, die in dieser Form eine temporale Verkettung der Bewegungsvektoren macht. Viel zu komplex, und fehleranfällig außerdem.

Die eigentlichen Schwierigkeiten bzw. Probleme liegen sowieso ganz woanders. Beispiel ... jemand turnt einen Hampelmann. Bild#1: die Arme waagerecht zur Seite, Bild#2: die Arme 45° nach oben, Bild#3: die Arme senkrecht nach oben. Diese Bewegung bringt jede Engine zum Scheitern, weil die Suche nur nach "gleichen" Bildblöcken sucht, die dann verschoben werden müssen. Bei den drei unterschiedlichen Winkelstellungen dieses Beispiels gibt es aber keine "gleichen" Blöcke, das bewegte Objekt sieht in jedem Frame anders aus, deswegen wird die Suche die "zusammengehörenden" Blöcke wahrscheinlich gar nicht erst finden, und dann gibt's Artefakte.
Da kann man noch so viele Frames absuchen, das hilft garnix. Die Suche zwischen zwei aufeinanderfolgenden Frames ist schwierig genug, und für den gegebenen Zweck ist das auch ausreichend.

-Didée- (Beitrag #13438) schrieb:

Ist zwar theoretisch richtig/wünschenswert, aber ich bin mir ziemlich sicher dass es keine Engine gibt, die in dieser Form eine temporale Verkettung der Bewegungsvektoren macht. Viel zu komplex, und fehleranfällig außerdem.

Meh.
Ich kann nur aus eigener Erfahrung, dass Panasonic bis zu meinem VTW60, tatsächlich nur jene Bewegungen ordentlich interpoliert, welche sich kurvenfrei bewegen. Inklusive eines Mauszeigers auf einem schwarzen Hintergrund (ich denke das ist relativ simpel). Meinst du nicht, das hängt mit diesem Thema zusammen?

Also nicht mit dem Thread Thema, versteht sich. An dem reden wir wieder alle vorbei

Didee also dein Beispiel ist natürlich extrem, wenn du nur von drei Frames mit drei Stellungen ausgehst.
Wenn man aber normale Abläufe nimmt, verändern sich die Bilder nicht so stark. Das ganze wird dann z.B. in einem 5x5 Raster abgetastet und schon findet man die sich bewegenden blöcke sehr leicht wieder. Das macht man schon 1-2 dekaden zur Bewegungserkennung so. Die Berechnung erfolgt auch über "umwege", was den Rechenaufwand stark vereinfacht. Wenn du willst kann ich dir da mal eine alte Vorlesung zukommen lassen. Ist allerdings nur Bildershow und auf Englisch.

Danke BigBubby. Ich arbeite seit 'nem Jahrzehnt mit genau dieser Materie und stecke bis zum Bauchnabel drin. Vermute mal, Doom9.org und Avisynth sind keine geläufigen Begriffe für Dich.

... Ach, und in einem 5x5 Raster sucht sowieso niemand. Die Vektor-Prediktoren werden in einer abfallenden Subsampling-Kaskade gesucht, die abschließende Feinsuche typischerweise in 16x16. auf jeden Fall ist in jedem Sampling/Suche-Stadium die Blockgröße immer 2^x, weil das in die Register am besten 'reinpasst.

@ Nui

Wie gut war eigentlich die bewegtbildoptimierung der letzten plasmas sowie den VTW 60 , hab das nie gesehen ?

Bei meinem GW20 und GT 30 war sie eher unbrauchbar aber auch nicht nötig.

Beim oled fällt auf das er sich immer wieder mal verschluckt wenn der Dejudder auf zwei steht , manchmal macht er den job zufriedenstellend und
dann wimmelt es wieder von bewegungsartefakte , wenn ich bei MADVR in den Exclusive Mode Settings den Backbuffer von 4 auf 8 stelle sind
schwenks zwar sauber und flüssig aber auf kosten der gesamtschärfe des bildes.

Ich habe mir schon gedacht das ich mal reclock teste , trotz nativer 23p und 24p zuspielung vom pc könnte ein fehler in der taktung des sounds geben.
Normalerweiße gibt es da probleme wenn man einen externe soundkarte verwendet , da ich aber über HDMI zuspile entfällt das normalerweiße.
Aber man weiß ja nie.

pa-freak1 (Beitrag #13442) schrieb:

Bei meinem GW20 und GT 30 war sie eher unbrauchbar aber auch nicht nötig.

Unverändert unbrauchbar und nicht nötig.

Servus

-Didée- (Beitrag #13441) schrieb:

Danke BigBubby. Ich arbeite seit 'nem Jahrzehnt mit genau dieser Materie und stecke bis zum Bauchnabel drin. Vermute mal, Doom9.org und Avisynth sind keine geläufigen Begriffe für Dich. ... Ach, und in einem 5x5 Raster sucht sowieso niemand. Die Vektor-Prediktoren werden in einer abfallenden Subsampling-Kaskade gesucht, die abschließende Feinsuche typischerweise in 16x16. auf jeden Fall ist in jedem Sampling/Suche-Stadium die Blockgröße immer 2^x, weil das in die Register am besten 'reinpasst.

avisynth kenn ich in der tat. Doom9 müsste ich jetzt googeln. Du hast natürlich recht, dass man eher ein 2^x nimmt. Aber das kann man auch z.B. in deutlich kleineren Rastern machen. Die Kaskadierung (ich kenne leider den korrekten Begriff nicht mehr, da das ganze bei mir 5-10 Jahre her ist, wie hieß denn noch diese "Pyramide") erhöht natürlich deutlich die geschwindigkeit. Aber soweit ins Detail wollte ich nicht mehr gehen.

Weil sie bei plasma nie nötig war hatt man sich wahrscheinlich auch nie sonderlich mühe gegeben.

Bei den Panasonic LCDs ist es ja auch nicht besser. ;-)

Aber ich bin auch nicht unbedingt der Maßstab, da ich MCFI grundsätzlich ablehne, weil keine Einzige auch nur zumindest befriedigende Ergebnisse liefert.
Und ja - ich kenne die von Sony und es ist noch die "Einäugige unter den Blinden" der Gattung der MCFI-Parias.

Meine sehr persönliche Meinung zu dem Thema als jemand, der bereits 2006 zu Plasma bekehrt wurde. Fußball-WM 2006 auf Plasma - geil.

Servus

Ich lehne sie eigentlich auch ab aber bei den Sample & Hold Oleds wäre eine auf dem Niveau von Sony besser als nichts.
LG braucht unbedingt ein paar lektionen von sony in der Richtung um zu sehen wie das geht.

Ist ja alles gut, am besten bin ich still und lass' euch hier in Ruhe weiter diskutieren. Mein Punkt ist einfach der ... irgendwo irgenwelche "Whitepapers" gelesen zu haben und über deren Erkenntnisse und Schlussfolgerungen gestaunt zu haben, das ist eine Sache. Hingegen, wenn man sich aktiv mit der Implementierung und Benutzung solcher Mechanismen beschäftigt hat, dann stellen sich viele Dinge etwas anders dar. Wenn ich mit Avisynth:MVTools "State-of-the-Art" (mehr oder weniger: in etwa auf Niveau der besten verfügbaren H.264-Implementierungen) Berechnungen anstelle, dann hab' ich ca. 40~50 verschiedene Parameter, mit denen ich die Suche nach Bewegungsvektoren beeinflussen/steuern kann, und ca. 20~30 verschiedene Parameter, mit denen ich die Ausführung der Bewegungs-Kompensation bzw. -Interpolation (zwei völlig verschiedene Paar Stiefel!) beeinflussen/steuern kann. Ganz zu schweigen von zusätzlicher Nach- bzw. Parallel-Bearbeitung, um mögliche Fehlerfälle zu erkennen und adäquat zu handhaben: das ist dann nochmal eine on-top Zusatzbaustelle.

Weiterer Problemfall: halbtransparente Bildelemente. Das können einfach Sender-Logos sein, oder im aktuellen Bild Spiegelungen in einem Fenster, oder entsprechende CGI-Effekte. Was machen wir denn, wenn innerhalb eines x*x-Blockes sowohl "Bewegung" als auch "Nicht-Bewegung" miteinander vermischt sind? Ja genau: mit einer "suche-gleiches-und-verschiebe den-Inhalt" Methode machen wir da gar nichts, zumindest nichts gutes. (Problem: eine andere Methode gibt es nicht...)
Statische Texte (Untertitel) gehören auch in diese Kategorie.

Weiterer Problemfall: Beispiel: eine völlig unbewegte Mauer/Steinoberfläche wird von einer flackernden Lichtquelle (Kerze, Fackel, Lagerfeuer) beleuchtet. Das stellt jede MC-Engine vor ernsthafte Probleme. Tatsächlich bewegt sich gar nichts, aber die Helligkeitsunterschiede verführen jede 'normale' Methode dazu, eine "Bewegung" zu erkennen, wo gar keine ist -- mit fatalen Ergebnissen. Klar, das kann man vermeiden, indem man auf Highpass- oder DCT-Abstraktionen arbeitet. Aber das verbessert wiederum nur diese speziellen Problemfälle, führt jedoch zu einer Verschlechterung in Situationen wo keine Highpass-Informationen vorhanden sind, sondern die Bildelemente hauptsächlich aus Low-Freq Informationen bestehen (etwa: wabernde Nebelschwaden, Unterwasserszenen, usw). Dann geht's eben dort vermehrt schief.

Weiterer Problemfall: Bereiche mit repetiven Mustern. Etwa ein Gartenzaun, der per Panning durch's Bild wandert. Jeder Zaunpfahl sieht genau so aus wie jeder andere, und was die Search-Engine als "best Match" befindet, das ist ... häufig problematisch. Natürlich kann man dieses Problem durch eine striktere Feld-Kohärenz in der Bewegungssuche deutlich verbessern, aber dann handelt man sich eben wieder verstärkte Probleme in anderen Bereichen mit "gemischten" Bewegungssituationen ein, wo eine starke Vektorkohärenz wiederum kontraproduktiv ist.

Probleme, Probleme, viele viele Probleme. DAS sind die Dinge, die die Qualität (oder nicht) einer Zwischenbild-Engine ausmachen. Und nichts davon lässt sich in irgend einer Weise mit "Pufferung" oder "mehr-Frames-berücksichtigen" verbessern. Die wirklichen Problem liegen einzig&allein zwischen direkten Frame-toFrame Beziehung ... und der Tatsache dass die Chips nun mal keine Idee haben was "Bewegung" eigentlich ist, sondern nur x*x Blöcke miteinander vergleichen können.

Und wer das alles SO noch nicht selber (ausgiebigst: Aufwand in "Mannjahren") gemacht hat, sondern nur in irgend 'nem Menü zwischen "Niedrig/Mittel/Hoch" ausgewählt hat, der braucht -- Entschuldigung -- MIR nichts darüber zu erzählen.

Also: diskutiert schön weiter darüber, was ihr euch erträumt oder vorstellt. Nachwort: die Praxis ist gleichermaßen sehr, sehr viel schwieriger, als auch sehr viel profaner.

@-Didée

Wem meinst du eigentlich jetzt ?

Wie soll sowas auch gut funktionieren, für mich ist das nur Schnipselei. Nehmen wir dieses Bild: https://upload.wikim...polation_example.jpg

Das meiste im Bild ruht udn verändert sich nicht, aber die galoppierenden Beine schon.
Im ersten Bild ist das Bein vorne rechts gebeugt und streckt sich im nächsten Bild aus. Also werden beide Bilder herangezogen, in beiden das Bein entfernt, die Hintergrund extrapoliert, und irgendwie zwischen den Pixel beider Beine Zwischenpixel berechnet, die zufällig ein gesamtes, erkennbares Bein ergeben. Dass es überhaupt soweit so gut klappt, grenzt für mich an ein Wunder
Gerade fehlende Informationen wegen der Beine die die Hintergründe in beiden Bildern verdecken, müssen doch erfunden werden, ohne dass es sich bemerkbar macht. Auch das zwischenberechnete Bein ist kein Echtes und kann unmöglich der Realität entsprechen, wie wenn das Bild tatsächlich gefilmt worden wäre. Für mich ist das Hexerei.

@sabberwurst: Das ist keine Hexerei, sondern ein einfacher Taschenspielertrick zur Demonstration. Im originalen Bildmaterial waren die ("unteren") Bildframes bereits alle vorhanden. Oben wird nur jedes zweite der Originalbilder gezeigt, und dann ist das "Wunder" sehr einfach erklärt.
(Es gibt keine Engine, die nur aus der oberen Sequenz das errechnen könnte, was unten gezeigt wird.)

Didee, kannst nicht mal schnell einen Codec erfinden, der mit bewegten Bildobjekten arbeitet, so wie es gerade beim Ton in Mode kommt?

pa-freak1 (Beitrag #13449) schrieb:

@-Didée Wem meinst du eigentlich jetzt ?

Er meint wohl mich in dem Fall ;-)

Didee nur mal so. Es würde schon reichen eine Bewegung die auf zwei Bildern "erkannt" wurde mit dem dritten zu vergleichen, ob der Bewegungsvaktor gleich oder verändert vorkommt. Wenn da nicht erkannt wird, dann linear interpolieren, wenn dort erkannt wird, dann entsprechend die interpolation eventuell nicht linear ansetzen. Damit würden sich fehler nicht deutlich vermehren, dagegen könnten bewegungen deutlich realistischer wirken.

Achja mannjahre habe ich sicherlich nicht damit verbracht. Habe "nur" meine Studienarbeit (Umfang einer heutigen Bachelorarbeit) in der digitalen Bildverarbeitung geschrieben ;-)

Für mich ist das aber Schnippelei, ich kann mir nicht vorstellen, dass das sauber funktioniert.

BigBubby (Beitrag #13453) schrieb:

Habe "nur" meine Studienarbeit (Umfang einer heutigen Bachelorarbeit) in der digitalen Bildverarbeitung geschrieben ;-)

Glückwunsch! Und wieviel davon hat sich auf die praktische Umsetzung von Inter-Frame-Interpolation bezogen?

Es würde schon reichen eine Bewegung die auf zwei Bildern "erkannt" wurde mit dem dritten zu vergleichen, ob der Bewegungsvaktor gleich oder verändert vorkommt.

Da Du ja vom Fach bist: überlege mal kurz, wie man das Source/Destination Problem in den Griff bekommt. Du suchst von X nach Y, X hat eine fest definierte Koordinate, Y landet "irgendwo". Bei zusätzlicher temporaler Korrelation gibt es keinen feste Zuordnung zu der Startkoordinate X'2. Die vorherigen Vektoren landen ja nicht "fix" auf dem Basis-Suchraster, sondern eben "irgendwo". Wenn Du jetzt von X'2 eine neue Suche startest, dann mach' mal eine Korrelation zu den vorherigen Vektoren, deren Endkoordinaten eben nicht auf der/den Koordinate/n der neuen Startposition liegt. Wünsche viel Spaß!! -- Es gibt da keine wohldefinierbare Zuordnung. Und wenn zwei, drei oder vier "Alt"-Vektoren mit ihrer Zielkoordinate in die Nähe der neuen Startkoordinate zeigen: welche von denen nimmste denn dann?

-Didée- (Beitrag #13455) schrieb:

Es würde schon reichen eine Bewegung die auf zwei Bildern "erkannt" wurde mit dem dritten zu vergleichen, ob der Bewegungsvaktor gleich oder verändert vorkommt. Da Du ja vom Fach bist: überlege mal kurz, wie man das Source/Destination Problem in den Griff bekommt. Du suchst von X nach Y, X hat eine fest definierte Koordinate, Y landet "irgendwo". Bei zusätzlicher temporaler Korrelation gibt es keinen feste Zuordnung zu der Startkoordinate X'2. Die vorherigen Vektoren landen ja nicht "fix" auf dem Basis-Suchraster, sondern eben "irgendwo". Wenn Du jetzt von X'2 eine neue Suche startest, dann mach' mal eine Korrelation zu den vorherigen Vektoren, deren Endkoordinaten eben nicht auf der/den Koordinate/n der neuen Startposition liegt. Wünsche viel Spaß!! -- Es gibt da keine wohldefinierbare Zuordnung. Und wenn zwei, drei oder vier "Alt"-Vektoren mit ihrer Zielkoordinate in die Nähe der neuen Startkoordinate zeigen: welche von denen nimmste denn dann?

Ich hatte erst einen etwas längeren Text hier, aber machen wir eine Kurzfassung. Natürlich muss man überprüfen, welche Methoden die höchsten Raten erreicht. Dabei gäbe es die Möglichkeit die beiden Koordinaten miteinander zu vergleichen (Also den Inhalt der Koordinaten des Suchrasters) und dort eine Schwelle festlegen, wieweit sie sich unterscheiden dürfen oder eben nicht, und so müsste man dann maximal 4 Rasterpunkte überprüfen. Alternativ einfach immer die Rasterkoordinate verwenden, die dem Zielvektor am nächsten ist. Wenn man es richtig aufwendig haben will, was ich für nicht praktikabel halte, wäre bei jeder Rasterkoordinate aus System 1 eine verschiebung der Rasterkoordinaten in Frame 2 durchlaufen zu lasse und das auf 3 eben so anzuwenden. Also immer drei Frames als Triple zu betrachten und berechnen und nicht nur wie jetzt Dupel. Ich bezweifle aber, dass hier die Rechenkapazität ausreicht. Wenn ich mich noch ein paar Stunden damit beschäftigen würde, würden mir sicherlich noch einige weitere Algorithmen einfallen, die sicherlich auch effizienter sind. Die drei oben waren einfach jetzt mal aus dem Bauch raus.
Eine allgemeine Alternative wäre auch gar nicht die Betrachtung von bekannten Bereichen, sondern punktweise über eine größeren Zeitrahmen die Zeitkoordinate zu interpolieren. Nachteil wäre eine gewisse Unschärfe im Bild, wo man dann nachregulieren müsste mit passender Kantenerkennung.
Ich müsste mich auch allgemein noch mal in die Themtik reinarbeiten. Ist deutlich zu lange her. Da gab es viele schöne Kniffe, um scheinbar komplexe Aufgaben leicht zu lösen...

-Didée- (Beitrag #13455) schrieb:

BigBubby (Beitrag #13453) schrieb: Habe "nur" meine Studienarbeit (Umfang einer heutigen Bachelorarbeit) in der digitalen Bildverarbeitung geschrieben ;-) Glückwunsch! Und wieviel davon hat sich auf die praktische Umsetzung von Inter-Frame-Interpolation bezogen?

Es ging bei mir nicht um die Interpolation, aber teilgebiet war auch die wiedererkennung von bekannten Strukturen innerhalb von Videos für diagnostische Zwecke. Eine Interpolation ist dort gefährlich, da es um Menschenleben geht. Um so wichtiger ist eine korrekte Erkennung.