Hand-tracking comparison
Paste two job result JSONs to compare CPU vs GPU runtime and FPS sampling accuracy.
Report A
Report B
Charts
Visual comparison of runtime cost and FPS sampling effects. Series colours: Report A in Totum blue, Report B in slate (unless noted).
Runtime / device
R1 · Wall-clock breakdown
R2 · Processing time
R3 · Time per frame
R4 · Peak RSS
R5 · Realtime factor
Video duration ÷ processing (≥1 is faster than realtime).
Accuracy / FPS sampling
A1 · Movement share
A2 · Bimanual activity
A3 · Frames analysed
A4 · Metric ratios (B ÷ A)
How many times larger Report B is vs A for key motion metrics.
Per-hand metrics
M1 · Path length (px)
M2 · Movement count
M3 · Visibility %
M4 · Idle %
M5 · Working-area %
M6 · Out-of-view events
M7 · Smoothness LDLJ
Not directly comparable across different sampling rates.
Dwell quality
D1 · Dwell counts
D2 · Dwell composition
Exact 1.0s dwells nested in totals (false-positive signal at 1 FPS).
D3 · Dwell duration histogram
Spatial
S1 · Dwell positions
Point size scales with dwell duration. Frame coordinates in pixels.
S2 · Working area vs path length
FPS sweet-spot analysis
Load every result JSON from a sweep (all FPS, CPU and GPU). The app treats the highest FPS as the reference "truth" and shows how each metric converges toward it, against the runtime cost of sampling faster — so you can pick the lowest FPS that is "good enough".
Load from cloud
Pick a published sweep from
cdn.totum.surgery/testdata/ml-comparisons/manifests.json
Or drop result JSON files here
click to choose files — select a whole folder's worth at once
Choose JSON filesLoaded reports
Sweet-spot charts
The reference is the highest FPS loaded for the selected device. Convergence lines flatten toward 100% as sampling gets fine enough; the elbow chart weighs accuracy against runtime cost.
Sweet spot
Accuracy vs runtime (the elbow)
Blue = % of metrics within tolerance of the reference. Amber = wall-clock runtime. The knee — high accuracy before runtime climbs — is the sweet spot.
Metric convergence (closeness to reference)
Each line shows how close a metric is to its highest-FPS value (100% = identical). The dashed line marks the tolerance threshold — above it counts as converged.
Runtime cost (all devices)
Total wall-clock vs FPS
Processing per frame vs FPS
Metric behaviour vs FPS
Path length (px)
Movement count
Bimanual activity %
Visibility %
Idle %
Dwell count
Deploy decisions · accuracy vs processing time
Side-by-side CPU and GPU view for mass-inference planning. Accuracy is measured against the highest-FPS reference in the loaded sweep; wall-clock and processing time show what that quality actually costs on each device. Use the same JSON set as the FPS sweep tab (or load it here).
Load from cloud
Same published runs as FPS sweep analysis (shared once loaded)
Or drop sweep result JSON files here
Same files as FPS sweep analysis — loading here also updates that tab, and vice versa
Choose JSON filesNo reports loaded
Accuracy vs processing cost
Large charts for deployment planning. Accuracy = share of tracked metrics within tolerance of the highest-FPS reference. Prefer the upper-left of the scatter (high accuracy, low runtime).
Decision charts
Accuracy vs wall-clock (CPU & GPU)
Each point is one FPS setting. Labels show FPS. Closer to the top-left is better — more accurate quality for less processing time.
Overall accuracy vs FPS
Solid lines = accuracy on each device. Dashed line = your target accuracy threshold. Where each line crosses the threshold is that device's sweet spot.
Total processing time vs FPS
Wall-clock cost of analysing one video at each sample rate. GPU stays flat; CPU climbs steeply — this is the mass-inference cost curve.
GPU speedup vs FPS
How many× faster GPU is than CPU at the same FPS.
Videos / hour at each FPS
Throughput estimate from wall-clock (3600 ÷ total_s).