Resampling - Versionsgeschichte

Aliebelt: Diese Seite wurde zum Übersetzen freigegeben

2023-09-03T18:42:48Z

Diese Seite wurde zum Übersetzen freigegeben

Aliebelt am 3. September 2023 um 18:42 Uhr

2023-09-03T18:42:19Z

Aliebelt am 3. September 2023 um 18:40 Uhr

2023-09-03T18:40:20Z

Aliebelt am 29. August 2023 um 22:36 Uhr

2023-08-29T22:36:14Z

Aliebelt am 7. August 2023 um 14:20 Uhr

2023-08-07T14:20:56Z

Alenz: Diese Seite wurde zum Übersetzen freigegeben

2022-04-19T08:30:36Z

Diese Seite wurde zum Übersetzen freigegeben

Neue Seite

<languages />
<translate>

Die Aufzeichnung der Benutzerinteraktion in emoTouch ist event-gesteuert. Jedes Mal, wenn ein Benutzer mit der Benutzeroberfläche interagiert, z.B. einen Schieberegler bewegt, wird auf dem Gerät des Teilnehmers ein Event ausgelöst, an den emoTouch-Server übertragen und in der Datenbank mit dem genauen Zeitstempel aufgezeichnet. Es gibt verschiedene Arten von Events für verschiedene Arten von Benutzerinteraktionen, z. B. Schiebereglerbewegungen, Tastenbetätigungen, Markieren von Kontrollkästchen usw. Einige zusätzliche Events werden ausgelöst und aufgezeichnet, wenn z.B. ein Part beginnt, ein Video abgespielt wird oder ein Benutzer sein mobiles Gerät dreht.

Die event-gesteuerte Architektur von emoTouch speichert Daten mit der bestmöglichen zeitlichen Genauigkeit. Die tatsächliche Genauigkeit der aufgezeichneten Zeitstempel der Ereignisse hängt von verschiedenen Parametern ab, z.B. von der Geschwindigkeit des verwendeten Geräts und der Netzwerkverbindung. emoTouch versucht jedoch, z.B. die Netzwerklatenz zu ermitteln und zu kompensieren und speichert den Zeitstempel eines Events so genau wie möglich.
Gleichzeitig ist die event-gesteuerte Architektur sehr effektiv und datensparsam. Wenn keine Interaktion stattfindet (z.B. weil der Benutzer einen Schieberegler eine Zeit lang nicht bewegt), werden auch keine Events ausgelöst und es entsteht kein unnötiger Netzwerkverkehr oder unnötige Datenspeicherung.


Die anfänglichen, event-gesteuerten Daten, die emoTouch in der Datenbank aufzeichnet, werden "Rohdaten" ('Raw data') genannt. Obwohl die Rohdaten den Zeitstempel der Ereignisse mit der bestmöglichen zeitlichen Genauigkeit enthalten, ist diese Art von Daten für die meisten Arten der Datenanalyse nicht geeignet. Für alle Analysen, die Berechnungen auf der Basis von mehreren Teilnehmern beinhalten (z.B. die Berechnung des Mittelwerts einer Schiebereglerposition über alle Teilnehmer zu einem bestimmten Zeitstempel), müssen 'resampelte Daten' ('Resampled Data') mit einer festen Abtastrate verwendet werden. Resampelte Daten enthalten in diskreten Zeitintervallen, z.B. alle 100 Millisekunden, die aktuelle Position z.B. eines Schiebereglers für jeweils alle Teilnehmer.

== Beispiel == 
[[Datei:Resampling1.png|mini|Abbildung A: Rohdaten]]
Die Teilnehmer A (blau) und B (grün) bewegen einen Schieberegler, ausgehend von einem gemeinsamen Anfangswert von 3 zum Zeitpunkt t0. Als erster bewegt Teilnehmer A zum Zeitpunkt t1 seinen Schieberegler auf den Wert 1. Bei t5 bewegen beide Teilnehmer ihre Schieberegler zufällig genau zum gleichen Zeitpunkt. NUR die Änderungen der Werte der Schieberegler lösen Events aus und werden mit den Zeitpunkten t0 bis t5 in der Datenbank gespeichert (Abbildung A) - und mehr nicht!


Wenn man versucht, den Mittelwert des Schiebereglers für die Teilnehmer A und B zu den Zeitpunkten t0 bis t5 zu berechnen, führt dies in den meisten Fällen zu falschen Ergebnissen, denn zu den Zeitpunkten t1, t2, t3 und t4 enthält die Datenbank jeweils NUR einen einzigen Wert für EINEN Teilnehmer. Ein Mittelwert, der zu diesen Zeitpunkten berechnet wird, entspräche dann einfach dem Wert dieses einen Teilnehmers - das ist offensichtlich fehlerhaft. Nur bei t0 und t5 sind jeweils ZWEI Werte in der Datenbank gespeichert, was den korrekten Mittelwert von 3 (t0) und 4 (t5) ergibt.


Die Lösung für dieses Problem ist die Verwendung von resampelten Daten. Bei dieser Neuabtastung wird ein Raster aus äquidistanten Zeitstempeln mit dem Zeitintervall ∆t erstellt. In der Datenbank wird dann der Wert des Schiebereglers für JEDEN Teilnehmer zu JEDEM Zeitpunkt des neuen Zeitrasters gespeichert.
[[Datei:Resampling2.png|mini|Abbildung B: Resampelte Daten]]


Abbildung B zeigt, wie die Ereignisse aus den event-gesteuerten Rohdaten in das neue Zeitraster der resampelten Daten überführt werden. t0 bis t5 sind die ursprünglichen Zeitstempel aus den Rohdaten, r0 bis r8 (rot) die neu erstellten Zeitstempel der resampelten Daten.
Wie ersichtlich, werden die tatsächlichen Schiebereglerwerte für beide Teilnehmer zu JEDEM einzelnen Zeitpunkt des Zeitrasters in der Datenbank gespeichert. Falls innerhalb eines Zeitraster-Intervalls ''kein'' neuer Rohwert auftritt, werden dabei die Werte des vorherigen Zeitintervalls wiederholt ('Upsampling'). Diese Wiederholung von Werten führt zwar zu deutlichen Redundanzen im Datensatz, aber ermöglicht auch Berechnungen, die mit den Rohdaten nicht möglich sind. So können problemlos z.B. Mittelwerte für jeden Zeitpunkt im neuen Zeitraster berechnet werden. Falls innerhalb eines Zeitraster-Intervalls ''mehrere'' Roh-Events liegen, wird lediglich entweder der erste oder der letzte der Werte in die resampelten Daten übernommen, der Rest wird verworfen. Dieses 'Downsampling' ist also unweigerlich immer mit einem gewissen Informationsverlust verbunden. Der Modus des Downsampling kann im Resample-Dialog von emoTouch eingestellt werden.


Die Zeitstempel im Zeitraster der resampelten Daten sind etwas weniger genau als die event-basierten Ursprungsdaten. So erfolgte beispielsweise die erste Änderung von Wert 3 auf 1 durch Teilnehmer A NICHT zum Zeitpunkt r1, wie die Wertänderung in den resampelten Daten vermuten läßt, sondern bereits etwas früher zum Zeitpunkt t1. Da aber t1 nicht mit dem neuen, äquidistanten Zeitraster übereinstimmt, zeigt sich die Änderung erst zum neuen Zeitstempel r1. Je kleiner das Intervall ∆t des Resampling ist, desto geringer ist die mittlere Zeitabweichung zwischen dem ursprünglichen und den resampelten Zeitstempeln.
Nicht zuletzt sind die Dateien für resampelte Daten deutlich größer als für Rohdaten. Die Rohdaten in Abbildung A benötigen nur 8 Zeit/Teilnehmer/Wert-Zeilen, um die Event-Informationen zu speichern, während bei den resampelten Daten 16 Zeilen benötigt werden. Die resampelten Daten enthalten viele redundante Informationen, die selbst dann gespeichert werden, wenn gar keine Benutzerinteraktion stattfindet. Je kleiner dabei das Resampling-Intervall ∆t ist, desto größer ist die Menge der redundanten Informationen.


Da die Verwendung von Resampling-Daten für viele numerische und statistische Analysemethoden von Zeitreihendaten unerlässlich ist, berechnet emoTouch nach Abschluss einer Durchführung einen ersten Resampling-Datensatz mit einem Zeitintervall von 100 ms (10 Hz). Die Rohdaten selbst werden ebenfalls sicher gespeichert und niemals verändert. Wenn das anfängliche 10-Hz-Resampling nicht Ihren Anforderungen entspricht, können Sie im Bereich 'Realisierungen' (Registerkarte 'Resamplings') weitere Resamplings mit anderen Abtastraten berechnen lassen. Diese neuen Resamplings werden dabei immer aus den Rohdaten berechnet. Beachten Sie jedoch, dass die Wahl eines sehr kleinen Resampling-Intervalls viel Zeit für die Berechnung benötigt und einen sehr großen Datensatz mit vielen redundanten Informationen erzeugen kann. Es ist also ratsam, sorgfältig zu überlegen, welche Zeitauflösung für die jeweilige Studie WIRKLICH erforderlich und nützlich ist.
'''(Hinweis: Die Berechnung von Resamplings ist bei Playback-Studien derzeit noch nicht möglich, da die Sessions zu ganz unterschiedlichen Zeitpunkten stattfinden können und zunächst auf den Medienstimulus synchronisiert werden müssen. Die Funktion wird in einer späteren Version implementiert)'''
</translate>

@@ Zeile 10: / Zeile 10: @@
 <!--T:2-->
-== Notwendigkeit für Resampling ==
+== Notwendigkeit von Resampling ==
 Die anfänglichen, event-gesteuerten Daten, die emoTouch in der Datenbank aufzeichnet, werden "Rohdaten" ('Raw data') genannt. Obwohl die Rohdaten den Zeitstempel der Ereignisse mit der bestmöglichen zeitlichen Genauigkeit enthalten, ist diese Art von Daten für die meisten Arten der Datenanalyse nicht geeignet. Für alle Analysen, die Berechnungen auf der Basis von mehreren Teilnehmern beinhalten (z.B. die Berechnung des Mittelwerts einer Schiebereglerposition über alle Teilnehmer zu einem bestimmten Zeitstempel), müssen 'resampelte Daten' ('Resampled Data') mit einer festen Abtastrate verwendet werden. Resampelte Daten enthalten in diskreten Zeitintervallen, z.B. alle 100 Millisekunden, die aktuelle Position z.B. eines Schiebereglers für jeweils alle Teilnehmer.

@@ Zeile 31: / Zeile 31: @@
 <!--T:8-->
 Da die Verwendung von Resampling-Daten für viele numerische und statistische Analysemethoden von Zeitreihendaten unerlässlich ist, berechnet emoTouch nach Abschluss einer Durchführung einen ersten Resampling-Datensatz mit einem Zeitintervall von 100 ms (10 Hz). Die Rohdaten selbst werden ebenfalls sicher gespeichert und niemals verändert. Wenn das anfängliche 10-Hz-Resampling nicht Ihren Anforderungen entspricht, können Sie im Bereich 'Realisierungen' (Registerkarte 'Resamplings') weitere Resamplings mit anderen Abtastraten berechnen lassen. Diese neuen Resamplings werden dabei immer aus den Rohdaten berechnet. Beachten Sie jedoch, dass die Wahl eines sehr kleinen Resampling-Intervalls viel Zeit für die Berechnung benötigt und einen sehr großen Datensatz mit vielen redundanten Informationen erzeugen kann. Es ist also ratsam, sorgfältig zu überlegen, welche Zeitauflösung für das jeweilige Projekt WIRKLICH erforderlich und nützlich ist.
-'''(Hinweis: Die Berechnung von Resamplings ist bei Playback Projekten derzeit noch nicht möglich, da die Sessions zu ganz unterschiedlichen Zeitpunkten stattfinden können und zunächst auf den Medienstimulus synchronisiert werden müssen. Die Funktion wird in einer späteren Version implementiert)'''
 </translate>

@@ Zeile 2: / Zeile 2: @@
 <translate>
-== Datenerzeugung in emoTouch ==
+== Datenerzeugung in emoTouch == <!--T:1-->
 Die Aufzeichnung der Benutzerinteraktion in emoTouch ist event-gesteuert. Jedes Mal, wenn ein Benutzer mit der Benutzeroberfläche interagiert, z.B. einen Schieberegler bewegt, wird auf dem Gerät des Teilnehmers ein Event ausgelöst, an den emoTouch-Server übertragen und in der Datenbank mit dem genauen Zeitstempel aufgezeichnet. Es gibt verschiedene Arten von Events für verschiedene Arten von Benutzerinteraktionen, z. B. Schiebereglerbewegungen, Tastenbetätigungen, Markieren von Kontrollkästchen usw. Einige zusätzliche Events werden ausgelöst und aufgezeichnet, wenn z.B. ein Part beginnt, ein Video abgespielt wird oder ein Benutzer sein mobiles Gerät dreht.
@@ Zeile 9: / Zeile 8: @@
 Gleichzeitig ist die event-gesteuerte Architektur sehr effektiv und datensparsam. Wenn keine Interaktion stattfindet (z.B. weil der Benutzer einen Schieberegler eine Zeit lang nicht bewegt), werden auch keine Events ausgelöst und es entsteht kein unnötiger Netzwerkverkehr oder unnötige Datenspeicherung.
-<!--T:2-->
+== Notwendigkeit von Resampling ==  <!--T:2-->
 Die anfänglichen, event-gesteuerten Daten, die emoTouch in der Datenbank aufzeichnet, werden "Rohdaten" ('Raw data') genannt. Obwohl die Rohdaten den Zeitstempel der Ereignisse mit der bestmöglichen zeitlichen Genauigkeit enthalten, ist diese Art von Daten für die meisten Arten der Datenanalyse nicht geeignet. Für alle Analysen, die Berechnungen auf der Basis von mehreren Teilnehmern beinhalten (z.B. die Berechnung des Mittelwerts einer Schiebereglerposition über alle Teilnehmer zu einem bestimmten Zeitstempel), müssen 'resampelte Daten' ('Resampled Data') mit einer festen Abtastrate verwendet werden. Resampelte Daten enthalten in diskreten Zeitintervallen, z.B. alle 100 Millisekunden, die aktuelle Position z.B. eines Schiebereglers für jeweils alle Teilnehmer.
-<!--T:3-->
+== Beispiel ==  <!--T:3-->
 [[Datei:Resampling1.png|mini|Abbildung A: Rohdaten]]
 Die Teilnehmer A (blau) und B (grün) bewegen einen Schieberegler, ausgehend von einem gemeinsamen Anfangswert von 3 zum Zeitpunkt t0. Als erster bewegt Teilnehmer A zum Zeitpunkt t1 seinen Schieberegler auf den Wert 1. Bei t5 bewegen beide Teilnehmer ihre Schieberegler zufällig genau zum gleichen Zeitpunkt. NUR die Änderungen der Werte der Schieberegler lösen Events aus und werden mit den Zeitpunkten t0 bis t5 in der Datenbank gespeichert (Abbildung A) - und mehr nicht!
@@ Zeile 21: / Zeile 18: @@
 Wenn man versucht, den Mittelwert des Schiebereglers für die Teilnehmer A und B zu den Zeitpunkten t0 bis t5 zu berechnen, führt dies in den meisten Fällen zu falschen Ergebnissen, denn zu den Zeitpunkten t1, t2, t3 und t4 enthält die Datenbank jeweils NUR einen einzigen Wert für EINEN Teilnehmer. Ein Mittelwert, der zu diesen Zeitpunkten berechnet wird, entspräche dann einfach dem Wert dieses einen Teilnehmers - das ist offensichtlich fehlerhaft. Nur bei t0 und t5 sind jeweils ZWEI Werte in der Datenbank gespeichert, was den korrekten Mittelwert von 3 (t0) und 4 (t5) ergibt.
-=== Resamplingvorgang ===
+=== Resamplingvorgang === <!--T:5-->
 Die Lösung für dieses Problem ist die Verwendung von resampelten Daten. Bei dieser Neuabtastung wird ein Raster aus äquidistanten Zeitstempeln mit dem Zeitintervall ∆t erstellt. In der Datenbank wird dann der Wert des Schiebereglers für JEDEN Teilnehmer zu JEDEM Zeitpunkt des neuen Zeitrasters gespeichert.
 [[Datei:Resampling2.png|mini|Abbildung B: Resampelte Daten]]
@@ Zeile 30: / Zeile 26: @@
 Wie ersichtlich, werden die tatsächlichen Schiebereglerwerte für beide Teilnehmer zu JEDEM einzelnen Zeitpunkt des Zeitrasters in der Datenbank gespeichert. Falls innerhalb eines Zeitraster-Intervalls ''kein'' neuer Rohwert auftritt, werden dabei die Werte des vorherigen Zeitintervalls wiederholt ('Upsampling'). Diese Wiederholung von Werten führt zwar zu deutlichen Redundanzen im Datensatz, aber ermöglicht auch Berechnungen, die mit den Rohdaten nicht möglich sind. So können problemlos z.B. Mittelwerte für jeden Zeitpunkt im neuen Zeitraster berechnet werden. Falls innerhalb eines Zeitraster-Intervalls ''mehrere'' Roh-Events liegen, wird lediglich entweder der erste oder der letzte der Werte in die resampelten Daten übernommen, der Rest wird verworfen. Dieses 'Downsampling' ist also unweigerlich immer mit einem gewissen Informationsverlust verbunden. Der Modus des Downsampling kann im Resample-Dialog von emoTouch eingestellt werden.
-<!--T:7-->
+=== Auswirkung des Resamplings === <!--T:7-->
 Die Zeitstempel im Zeitraster der resampelten Daten sind etwas weniger genau als die event-basierten Ursprungsdaten. So erfolgte beispielsweise die erste Änderung von Wert 3 auf 1 durch Teilnehmer A NICHT zum Zeitpunkt r1, wie die Wertänderung in den resampelten Daten vermuten lässt, sondern bereits etwas früher zum Zeitpunkt t1. Da aber t1 nicht mit dem neuen, äquidistanten Zeitraster übereinstimmt, zeigt sich die Änderung erst zum neuen Zeitstempel r1. Je kleiner das Intervall ∆t des Resampling ist, desto geringer ist die mittlere Zeitabweichung zwischen dem ursprünglichen und den resampelten Zeitstempeln.
 Nicht zuletzt sind die Dateien für resampelte Daten deutlich größer als für Rohdaten. Die Rohdaten in Abbildung A benötigen nur 8 Zeit/Teilnehmer/Wert-Zeilen, um die Event-Informationen zu speichern, während bei den resampelten Daten 16 Zeilen benötigt werden. Die resampelten Daten enthalten viele redundante Informationen, die selbst dann gespeichert werden, wenn gar keine Benutzerinteraktion stattfindet. Je kleiner dabei das Resampling-Intervall ∆t ist, desto größer ist die Menge der redundanten Informationen.
-<!--T:8-->
+=== Resamplingintervall/ Abtastrate === <!--T:8-->
 Da die Verwendung von Resampling-Daten für viele numerische und statistische Analysemethoden von Zeitreihendaten unerlässlich ist, berechnet emoTouch nach Abschluss einer Durchführung einen ersten Resampling-Datensatz mit einem Zeitintervall von 100 ms (10 Hz). Die Rohdaten selbst werden ebenfalls sicher gespeichert und niemals verändert. Wenn das anfängliche 10-Hz-Resampling nicht Ihren Anforderungen entspricht, können Sie im Bereich 'Realisierungen' (Registerkarte 'Resamplings') weitere Resamplings mit anderen Abtastraten berechnen lassen. Diese neuen Resamplings werden dabei immer aus den Rohdaten berechnet. Beachten Sie jedoch, dass die Wahl eines sehr kleinen Resampling-Intervalls viel Zeit für die Berechnung benötigt und einen sehr großen Datensatz mit vielen redundanten Informationen erzeugen kann. Es ist also ratsam, sorgfältig zu überlegen, welche Zeitauflösung für das jeweilige Projekt WIRKLICH erforderlich und nützlich ist.
-== Resampling von Playback Projekten ==
+== Resampling von Playback Projekten == <!--T:9-->
 In Playback Projekten finden die Sessions gewöhnlich asynchron statt. Seit Version 1.7.0 werden die Daten daher vor der Auswertung vorverarbeitet und synchronisiert.
 → [[Datenvorverarbeitung und Synchronisierung von Playback Projekten |Zum Artikel "Datenvorverarbeitung und Synchronisierung von Playback Projekten"]]
 </translate>