es hat leider diesmal ein bisserl länger mit dem antworten gedauert, weil ich bei einer ganz ähnlich gelagerten diskussion bereits einmal den nötigen code schreiben wollte, um FlowNet2 auch tatsächlich mit gebräuchlichen videoverarbeitungsmitteln nutzen zu können, mich aber erst diesmal hingesetzt habe, um das auch tatsächlich umzusetzten -- was natürlich [wie üblich] dann doch wieder ein bisser kompliziert war als erwartet.
aber zuerst einmal zu dem konkreten beispiel:
erlich gestanden halte ich dieses premiere resultat leider auch für eher unzureichend. offenbar kommt hier wohl wirklich nur eine sehr einfach form des frameblendings zum einsatz, die ganz und gar nicht zu überzeugen vermag.
das beispiel selber ist aber ganz interessant, weil es gleich ein paar stolpersteine enthält, an denen sich optical flow lösungen gewöhnlich die zähne ausbeissen. :)
ein erstes problem, das man an diesem beispiel sehr eindrucksvoll vor augen geführt bekommt, ist die tatsache, dass hier zwar jedes zweite einzelbild relativ sauber wirkt -- also mehr od. weniger dem ausgangsmaterial entspricht, aber dafür die zwischenbilder umso schlimmer wirken. das führt in der praxis zu einem recht unhübschen flimmern. andere programme (bspw. nuke) begegenen diesem problem, indem sie nicht nur zusätzliche zwischenilder bei der verdoppelung der framerate einfügen, sondern vielmehr zwei neue symmetrisch interpolierte bilder an stelle der vorhandnen setzten -- also, wenn die ausgangsbilder auf der zeitachse ursprünglich der position 0, 1, 2... entsprechen, werden neue bilder an position: 0.25, 0.75, 1.25, 1.75 usw. gesetzt. damit wird ein viel homogenerer fluss sichergestellt.
trotzdem hat es mir natürlich diese etwas primitivere lösung im vorfindlichen beispiel sehr einfach gemacht, einfach nur jedes zweite bild herauszugreifen, um sauberes ausgangsmaterial für vergleichende versuche mit anderen programmen zu gewinnen.
so schaut es dann bspw. im resolve aus, wenn in den projekteinstellungen 'optical flow retiming' und 'enhanced estimation' eingestellt sind:
resolve_output
das ist schon deutlich besser!
resolve macht das mittlerweile wirklich ganz sauber -- und auch mit erstaunlichem tempo = praktisch in echtzeit!
die qualität ist den meisten fällen bzw. bei geeignetem ausgangsmaterial in vielen fällen durchaus brauchbar od. eben einfach ungefähr dort, wo auch alle anderen traditionellen optical flow lösungen angesiedelt sind.
so gesehen leistet die 'Kronos' node bzw. der 'VectorGenerator' im NukeX [non-commercial] von haus aus auch nicht wirklich mehr:
nuke_kronos
der große unterschied im vergleich zum resolve besteht aber darin, dass man hier nicht nur ein paar sehr spärliche einstellungsmöglichkeiten zur verfügung hat, sondern eine ganze menge parameter fein justieren kann, aber auch wesentlich tollere mögchlichkeiten vorfindet, das ganze bgeschehen zu kontrollieren und mit masken u.ä. ggf. weiter zu verbessern. im übrigen kann man hier auch synthetisierten motion blur u.ä. auch nachtraglich in frei wählbarer dosierung ins bild reinrechnen...
aber, wie oben schon angesprochen, wollte ich endlich auch einmal ausprobieren, wie sich diese gänzlich neueratigen lösungen, die nicht mehr nur auf den traditionellen mustererkennungstechnigen basieren, sondern machine learning techniken benutzen, im ganz praktischen vergleich dazu ausnehmen?
mittlerweile gibt's dazu ein nvidia-docker image von den FlowNet2 entwicklern an der uni freiburg, die den zugang zu diesen relativ jungen schätzen der akademischen forschung verhältnismässig einfach macht. leider generiert diese demonstrationsimplementierung nur files im .flo format, mit denen man außerhalb der elfenbeintürme relativ wenig anfangen kann. aus diesem grund habe ich schließlich ein
kleines script geschrieben, das die ausgabe in gängige OpenEXR motion vector files übersetzt, wie sie in professionen video lösungen zu diesem zweck gewöhnlich verwendet werden. man muss damit also nur die betreffende bildsequenz in einem ordner als nummerierte PNG bilder abspeichern, den berechnungsprozess aufrufen, und die resultierenden EXR files dann bspw. als motion input für die Kronos node im NukeX nutzen. das ist zwar nicht ganz einfach, aber für etwas erfahrenere kollegen vermutlich durchaus nachahmbar... ;)
hier jedenfalls das gegenständliche beispiel nach der bearbeitung mit dieser lösung:
nuke_flownet2
sonderlich überzeugend wirkt das resultat aber in diesem fall leider nicht. :(
ganz abgesehen davon, dass sich im konkreten fall störungen zeigen, mit denen offenbar das trainierte netz so überhaupt nicht klar kommt (bspw. die artefakten auf der motorhaube), gibt's einfach eine ganz grundsätzliches problem mit diesem ansatz, das seine ursprung in der ungewöhnlich sauberen segmentierung von objekten bzw. tiefenebenen im bild hat.
wenn man die bewegungsvektoren, wie sie bspw. nukes VectorGenerator [ganz rechts im bild] errechnet, mit dem vergleicht, was FlowNet2 liefert, sticht das sofort ins auge:
leider ist diese genauigkeit der abgrenzung nicht immer von vorteil. die probleme mit der straßenlaterne links im video machen das leider mehr als deutlich. da ist einem dann oft der matsch bzw. das vermischen der tiefenebenen, wie es die meisten anderen optical flow lösungen mit sich bringen, fast lieber.
ich fürchte also fast, dass auch diese lösung nicht unbedingt out of the box sofort zu besseren resultaten fürhrt. vermutlich muss man also weiterhin mit diversen compositing tricks manches nachzubessern versuchen, vielleicht sogar mit geeigneteren trainigsdaten spielen, trotzdem ist es ein ziemlich spannender ansatz, den man vermutlich auch ganz gut ergänzend bzw. im zusammenspiel mit den bekannten methoden nutzen könnte...
hier noch ein paar andere beispiele aus den daala test clips, die evtl. auch noch andere aspekte sichtbar werden lassen könnten:
pedestrain_area (25->50fps mit jeder menge motion blur schon in den ausgangsbildern)
crowd_run (25->50fps + 50% retime => 4 x slomo)
ducks_take_off (detto)