Größe von .moi Dateien (Texturen) und Verhalten bei "Sprung zu Index"

[hora58]

Da könnte man sich jetzt fragen, was das miteinander zu tun hat.
Hat es! (Vermutlich) Das habe ich in den letzten (Tagen) Nächten feststellen müssen.
Unterschiedlichen Quellen kann man entnehmen, dass ein vorheriges manuelles Aufbereiten des Bildmaterials bezüglich der Ausgabequalität (z.B. 16:9 1920x1080px etc.) nicht nötig ist, da das von m.objects mit Hilfe der Textur Technik optimal erledigt würde.
Da ich das gerne glauben wollte, habe ich aus den RAW Dateien meiner Kamera qualitativ hochwertige JPGs generiert, mit 15-20MB Größe 3:2 6000x4000px. Dies führt zu .moi Datein von rund 2MB Größe.
Nach Anpassung des Seitenverhältnisses per Bildfeld- oder Zoomobjekt auf 16:9 waren es schon bis zu 4MB.
Bei manchen Bildern mit Kamerafahrten und Zoomfaktoren von bis zu 300% (was das Ausgangsmaterial ja locker hergibt) waren die .moi Dateien dann auch mal bis zu 20MB groß.

(Im Normalfall mit einem potenten Schenker Notebook mit Windows Leistungsindex von 7,2 - i7 QuadCore, 16GB RAM, SSD, leistungsstarker Graka kein Problem )

Das eigentliche Problem hat sich erst gezeigt, als ich versucht habe, per Indexmarken Teilsequenzen der Show anzuspringen und die Sprungziele eines oder mehrere (überlagerte) Bilder dieser Größenordnung waren.
Ergebnis: Bild und Ton- Aussetzer von 3-5 sec. !
Erwartet hätte ich einen Sprung in "Echtzeit"da die Bilder ja als Texturen vorhanden sind und nicht individuell berechnet/geladen werden müssen.

Um dem Verhalten auf den Grund zu gehen habe ich diverse Tests durchgeführt:

Das Verhalten ist erst bei großen .moi Dateien bemerkbar. Bei vorher bezüglich Seitenverhältnis, Zoomfaktor und Dateigröße (.pic-3MB, .moi-500k bis 2MB) optimierten Bildern eher nicht.

Erstaunlich: Beträgt die Distanz von einer Sprungmarke zum Ziel (auch wenn die zugrunde liegende Textur noch so groß ist) weniger als etwa 10 sec. auf der Timeline ist keinerlei Verzögerung zu bemerken !!?? (Bringt in der Praxis jedoch wenig)
Auch der (asynchron geschaltete) Ton läuft ohne Unterbrechung weiter - so hätte ich das in jedem Fall erwartet.(Bild1)

Beträgt die Distanz aber 10-15 sec. und mehr, kommt es plötzlich zu einer Latenz von mehreren Sekunden.
Nicht toll- zumindest der (asynchrone) Ton läuft weiter - aber nur dann, wenn die Zielmarke noch über dem selben Soundsample liegt! (Bild2)

Möchte man jetzt allerdings - wie ich - auf eine (am Anfang oder Ende der Show abgelegte) Teilsequenz mit eigenem Ton abzweigen kommt es zum kurzzeitigen Stillstand von Bild und Ton!!
Und das ist leider unbrauchbar. (Bild3)

Wäre schön wenn das Jemand nachvollziehen könnte, um einzugrenzen ob dieses Verhalten "normal" und technisch "logisch" ist oder ob es sich bei der Bild und/oder Ton- Unterbrechung um einen Bug handelt. (Und damit zu untermauern, dass die Texturgröße dafür nicht verantwortlich ist.)
-- Getestet auf Win.7 64bit SP1 mit m.objects creative Build 2345 - Hardware s.o. --

Nachtrag - Noch eine Beobachtung: Bei jedem Sprung wechselt m.objects kurz in den "Pause" Modus. ( Erkennbar, dass die Zeitanzeige kurzzeitig von "grün" auf "gelb" wechselt) ?!

Im Zuge meiner Tests bin ich auch noch auf eine weitere - nennen wir es mal Unzulänglichkeit - bei Indexmarken gestoßen:
viewtopic.php?f=5&t=3108

Gute Nacht! ;-)

Horst

[m.objects]

Hallo Hora58,

Ihre Beobachtung bestätigt sogar zu 100% die Aussage, dass es keinerlei Vorteil hat, die Bilder im Vorfeld herunter zu skalieren.
Die resultierende Größe der Texturdateien belegt das, denn je weiter Sie in ein Bild zoomen, desto höher muss die Auflösung der Textur ja werden.
Der Vergleich mit im Vorfeld manuell klein gerechneten Bildern liefert kein sinnvolles Resultat, da diese ja gar nicht mehr genügend Auflösung für das Aufzoomen mitbringen. Hier legt m.objects selbstverständlich auch keine hochskalierte Textur für an, da ohnehin kein Gewinn an Information mehr möglich ist.
Dass Sprünge über eine weitere Distanz je nach Arrangement länger dauern können ist auch vollkommen normal. Die Verzögerung, die Sie beobachten, hat nämlich damit zu tun, dass - abhängig von der Anzahl der verwendeten Spuren und der Anzahl und Auflösung der darauf gewechselten Bilder - eine mehr oder minder große Datenmenge in die Grafikkarte transferiert werden muss.
m.objects geht in einigen Optimierungen da einen "vorsichtigen" Weg, der eine ruckelfreie Wiedergabe von Animationen garantieren soll. Um ggf. individuelle Einstellungen für die Optimierung der Sprünge an Ihrer Maschine vorzunehmen, können Sie uns gerne einmal anrufen, bevorzugt während Sie gerade vor dem PC sitzen. Warum es bei Ihnen zu einem "Stillstand" des Tons kommen sollte, wo dieser doch augenscheinlich auf "asynchron" eingestellt ist, können wir dann ebenfalls erörtern, denn ein solches Problem kann ich weder nachvollziehen, noch gäbe es dafür einen technischen Grund.

Mit freundlichem Gruß
Steffen Richter

[hora58]

Hallo Herr Richter,

zunächst vielen Dank für Ihre rasche Antwort. Dies unterstreicht Ihren wohl ziemlich einzigartigen Kundenservice.

Ich stimme mit dem ersten Teil ihrer Antwort absolut überein, wenn wir davon ausgehen, dass wenn wir von "Zoomen" sprechen gemeint ist, dass während der Show in Bilder von 100% auf 200% oder sogar 300% ( bei 6000x4000 px Ausgangsmaterial und 1920x1080 px Ausgabegröße gut möglich) gezoomt wird. Dann, da sind wir uns einig, muss natürlich auch die Auflösung der Texturdatei dem "Extremfall" genügen, was zu ähnlichen Größen wie beim Ausgangsbild führt.
Solche Zoomorgien sind aber vermutlich die Ausnahme. In vielen Fällen wird jedoch nicht - oder nur geringfügig (Ken Burns Effekt) gezoomt.
Wenn man bei statischen Bildern den komfortablen Weg über m.objects wählt um mittels Zoom- oder Bildfeldobjekt den finalen (z.B. 1920x1080px) Bildausschnitt zu erzeugen, handelt man (jedenfalls ich bei meinem Test s.u.) sich zigfach größere .moi Dateien ein.
Und da das so zu sein scheint, bestätigen Sie im zweiten Teil Ihrer Antwort "...Die Verzögerung, ...hat nämlich damit zu tun, dass - ... eine mehr oder minder große Datenmenge in die Grafikkarte transferiert werden muss..." zu 100% wiederum meine ( und manch anderer) These, dass ein, auf die größte erforderliche Ausgabeauflösung im Vorfeld reduziertes Bild vorteilhafter ist.

Da die von mir geschilderten Verzögerungen ( bis hin zu Tonaussetzern ) jedoch sogar in meiner 3-minütigen Test Show mit nur 10 Bildern auftreten, sich GPU (15%) und Grafikkarten Speicher ( max. 150MB von 2GB) eher "langweilen" und das Auftreten des Effekts nachvollziehbar durch eine Veränderung der Sprungmarkenentfernung im 2stelligen Sekundenbereich beeinflussen lässt, zweifle ich immer noch, dass ausschließlich die Datenmenge dafür verantwortlich ist.

P.S.: Habe auch wie bereits in Thread http://forum.mobjects.com/viewtopic.php ... port#p5227 aus dem Jahr 2009 (!) thematisiert mit den "Pfeilobjekten" experimentiert und konnte damit das Verhalten positiv beeinflussen. ( Obwohl das doch mitlerweile nicht mehr nötig sein sollte)

Bitte nicht falsch verstehen. Mir liegt es fern, hier über m.objects zu "motzen" (dazu müsste ich mir nicht so viel Arbeit machen) - ich möchte es, wie wohl alle hier, nur weiter optimieren und trage auch gerne weiterhin dazu bei.

Viele Grüße
Horst Raab



.moi Dateien im mob_Auto Ordner mit hochauflösendem Ausgangsmaterial ( Die beiden markierten Dateien "bequem" mittels Zoomobjekt auf die gewünschte Größe getrimmt)

test_texture_mo_moi.PNG (69.85 KiB) 4245 mal betrachtet

.moi Dateien im mob_Auto Ordner mit tw. hochauflösendem Ausgangsmaterial ( Die beiden markierten Dateien im Vorfeld auf die gewünschte Größe getrimmt)

[hora58]

... Nachtrag:
Wenn das Sprungziel auf einer völlig leeren Spur platziert wird, ist die Verzögerung auch bei längeren Distanzen zumindest beim Hinsprung weg - oder unmerklich kurz. Der Sprung zurück von dieser Teilsequenz dauert dann wieder.....
...Ausser ich wende den Trick mit den Pfeilobjekten an (!) Dabei ziehe ich die Objekte der letzten Bilder der belegten Spuren hinter die Rücksprung Marke der Teilsequenz.
Damit scheint der Effekt offensichtlich doch was mit der Speicherfreigabe zu tun zu haben.
Dieser "Pfeiltrick" ist leider nur in meiner konstruierten Test Show anwendbar, da ich im Normalfall die Pfeilobjekte nicht "kilometerlang" durch die ganze Show ziehen kann.

Laienhafte Idee: Wäre es möglich ein "portables Pfeilobjekt" anzubieten? Also ein Objekt, dass man frei platzieren kann, dass die gleiche Wirkung hat (Speicherfreigabe?), wie das Verlängern der Pfeile der Bilder?

Mag sein, dass dies ein sehr spezielles Problem ist, das (nur mich?) wenige tangiert. Aber Vielleicht hilft eine Lösungsfindung die generelle Performance von m.objects zu verbessern.

Viele Grüße
Horst

[m.objects]

Hallo Herr Raab,

Sie sind da ja nahezu wissenschaftlich vorgegangen.
Verstehen Sie mich bitte ebenfalls nicht falsch: Ich denke, dass theoretische Betrachtungen der Texturverwaltung für die Mehrzahl der Anwender ohne Belang sind. Für uns als Entwickler sind solche Dinge natürlich wichtig, weshalb wir die gesamte Textur-Engine seit Ihrer Einführung vor einigen Jahren vielfach testen und auch oftmals überarbeiten und optimieren.
Daher führt diese Diskussion hier im Forum meines Erachtens zu weit, hier bekommen andere Anwender eher etwas zu lesen, was in den E-Mail Verkehr zwischen technisch versiertem Anwender und Entwickler gehört. Aufgrund eines in der Praxis tatsächlich wenig relevanten Testszenarios und daher falscher Schlussfolgerungen könnte es auch Anwender verunsichern. Die an der mehrheitlich umgesetzten Praxis klar vorbei zielende Annahme in Ihrem Test ist nämlich, dass von einer signifikanten Anzahl von Bildern nur ein relativ kleiner Ausschnitt statisch ausgewählt wird, also ohne Animation wie z.B. Ken-Burns Effekt. Nur in diesem Fall nämlich kann ein vorab gewählter, kleiner Bildausschnitt in Zielauflösung einen Vorteil im Bezug auf die Datenmenge (nicht einmal im Bezug auf die Qualität) bringen.
Daher bekräftige ich unbedingt noch einmal die Aussage, dass Bilder im Normalfall nicht vor der Einbindung extern skaliert werden sollten. Die Vorteile: Die Mit wenigen Mausklicks kann man Zoomfaktor oder Bildausschnitt unter Beibehaltung der optimalen Ausgabequalität verändern. Das selbe gilt für etwaige Änderungen (insbesondere Erhöhungen) der Ausgabeauflösung, sei es für 4K-TV oder Videoexport in beliebigen Auflösungen. Und - last but not least - sparen Sie so eine Menge Zeit.

Mir sind die technischen Hintergründe aller Ihrer Beobachtungen - auch im Bezug auf die genannten Pfeilobjekte - vollkommen klar, all das ist exakt so im Design der Software spezifiziert. Ich bitte um Verständnis, dass ich hier im Forum jedoch keine noch tiefer gehenden technischen Erläuterungen dazu geben kann, denn das lässt ein handelsüblicher Arbeitstag leider nicht zu (in der Texturverwaltung stecken sehr viele Überlegungen und einige Monate Entwicklungsaufwand -> viele Bildschirme voller Text wären zur Erläuterung nötig).

Auch zitiere ich mein Angebot (s.o.), das Sie bitte bei weiteren Fragestellungen zur Optimierung der Performance nutzen sollten:

m.objects geht in einigen Optimierungen da einen "vorsichtigen" Weg, der eine ruckelfreie Wiedergabe von Animationen garantieren soll. Um ggf. individuelle Einstellungen für die Optimierung der Sprünge an Ihrer Maschine vorzunehmen, können Sie uns gerne einmal anrufen, bevorzugt während Sie gerade vor dem PC sitzen. Warum es bei Ihnen zu einem "Stillstand" des Tons kommen sollte, wo dieser doch augenscheinlich auf "asynchron" eingestellt ist, können wir dann ebenfalls erörtern, denn ein solches Problem kann ich weder nachvollziehen, noch gäbe es dafür einen technischen Grund.

Mit freundlichem Gruß,
Steffen Richter