Status: Draft (2026-10-26), reflects measured values. Data scales were measured directly by us, and licenses were verified only up to the text stated on the official pages and LICENSE files of each dataset and repository. This article does not constitute legal advice. "Commercially usable" is based strictly on the written text; final decisions regarding commercial services must undergo legal review. Writing rules: Measured data is the default, unmeasured items are marked as "Unmeasured," and items with no found basis are marked as "Cannot verify."

Data, Licenses, and Training Processes

Table of Contents

• 1. Why This Article Is Needed Separately
• 2. Dataset Table
  • Storage
• 3. Where and How Training Actually Runs
  • The Disposable Pod Approach
  • Kubeflow Is Installed, But Not Yet Used for the Scoring Engine
• 4. Experimental Rules: Making Numbers Trustworthy
  • Fixed Splitting
  • Documenting Leakage Warnings
  • Single Primary Metric, Pairwise Comparison, Median Seed
  • Defining Ruling Rules Before Seeing Results
  • Real-Time Budget
  • Rulings Born from Failures
  • Code License Principles
• 5. Current Measured Metrics at a Glance
• 6. The Path to Commercial Service: Direction and Principles
  • Principles
  • First Case Built Using This Principle
  • Plan
  • What Happens to Evaluation Data?
• 7. Conclusion
• References
• Further Reading

1. Why This Article Is Needed Separately

Discussions about models usually end with architecture and accuracy. However, in real-world services, two questions always follow:

1. What was used to measure these numbers? Even the same model yields vastly different numbers depending on the data and rules used for measurement.
2. Can this model be used? The licenses of the data used for training carry over directly to the model.

TT Lab decided on October 18, 2026, to pivot toward a commercial service, and since then, the second question has become the primary question for every model. The final section of this article covers that direction, principles, and plan.

2. Dataset Table

Some aspects are not apparent from the table alone.

• Non-commercial data forms the basis of evaluation. Most public table tennis datasets featuring ball positions, bounces, and rally winner labels carry non-commercial licenses, and nearly all accuracy numbers to date have been evaluated on top of them.
• Commercially usable actual training materials are still sparse. Currently, 12 images from a single 2015 league broadcast that do not overlap with the test set were used for corner training. This is the source of the limitation noted in Section 4: "generalization to other gymnasiums was not observed."
• Videos from the same location were excluded from training. Other videos from the same gymnasium and laboratory as the test images were labeled but withheld from training to prevent optimistic bias in testing.
• Dataset-specific pitfalls (such as labels restricted only to event vicinities or multiple rallies bundled into a single label) are detailed in Part 7of the preceding series.

Storage

Originals are stored unmodified on the NAS. Working copies reside on the GPU server volume across 15 bundles totaling about 89GB (including 33GB for OpenTTGames, 26GB for T3Set, and 20.7GB for international broadcasts). The laptop GPU setup mounts the NAS as read-only without a separate local volume. Research outputs (inference results, heatmaps, trained weights) are also kept in a dedicated NAS folder. Download logs record the same path size as 132GB, showing a discrepancy (it cannot be verified which value is current).

3. Where and How Training Actually Runs

While "training" often evokes large GPU clusters, most scoring engine training tasks are very small.

Extraction and inference (running the ball model across public videos, pose extraction, etc.) were executed on CPU and GPU pods of the GPU server or laptop GPUs.

The Disposable Pod Approach

Training on laptop GPUs is executed via disposable podson Kubernetes. A pod containing the training code and inputs is pinned and launched on a specific node and deleted upon completion (--rm). This approach stems from actual incidents experienced previously.

• Without pinning nodes, workloads land in random places. Heavy build jobs previously landed unpinned on low-memory nodes, crashing other services on those same nodes. Consequently, training pods always pin their nodes, verify remaining memory and GPU allocation on that node before launching, and specify memory requests and limits (corner training requests 3Gi with a 5Gi limit, confirming 6–8GiB availability prior to launch).
• Leaving no residue upon completion. If a pod leaves GPUs occupied, operations personnel cannot access them. "0 remaining pods" is verified once training finishes.
• Privileges are not granted. Even disposable pods run without service account tokens, and the NAS is mounted as read-only.

There were days when GPU pods failed to launch entirely due to GPU driver issues. When utilizing small lab-scale GPUs, it is necessary to develop the habit of checking whether the environment is healthybefore writing training code.

Kubeflow Is Installed, But Not Yet Used for the Scoring Engine

On October 18, 2026, Kubeflow Trainer (v2.3.0, JobSet v0.12.0) was installed via GitOps, and successful synchronization was confirmed. A dedicated training zone was also established. The boundaries of that zone are as follows:

• Pods run non-root, all capabilities dropped, privilege escalation prohibited (Pod Security ... restricted).
• GPU workloads are restricted to the laptop GPU node, images are pulled exclusively from the internal registry, and service account tokens are omitted.
• Up to 1 GPU, total memory limit of 6Gi, and maximum 4 pods.
• No inbound or outbound network access (even pip cannot reach the internet). Necessary assets are pre-loaded into the shared volume (NAS, 200Gi).

However, training executed via this TrainJob has thus far been limited to table tennis robotic arm reinforcement learning and smoke tests. There is no record of training scoring engine models (ball, filtering, correction, corners) using TrainJob. The reasons are documented in the operations manual. The data and large GPUs required for fine-tuning the ball model reside on the GPU server, whereas the training zone's GPUs are pinned to the laptop GPU node, creating a mismatch in rules. Decisions regarding data migration or rule adjustments must come first. Although installation files for pipelines (KFP 2.16.1) and hyperparameter tuning (Katib v0.19.0) exist, following initial synchronization error troubleshooting logs, their current status is unverified, and no records of their use for table tennis models were found.

To be honest, this is not a major issue at the current scale. Filtering and correction take only a few minutes on a laptop CPU, and the keypoint model takes 20 minutes. A training platform will become necessary when we need to retrain the ball model from scratch (Section 6).

4. Experiment Rules: Making Numbers Trustworthy

What takes more time than training is measuring fairly. At the very beginning of the research log, we wrote down the rules applied to all experiments (2026-10-13).

Fixed Split

This split is for research purposes. Training materials for commercial services follow the principles in Section 6.

Note on Data Leakage Warning

The rule engine was refined while observing all 12 public matches (including 7 test matches) on 2026-10-11–12. Therefore, the test score of the rule baseline is in-sample and thus optimistic. Since new learning-based methods have never seen the test matches, the comparison is biased against the new methods. We note this warning at the beginning of the log and include it in every comparison. Also, because the list of training videos for the ball model is not disclosed, we do not know if they overlap with the test matches. Therefore, ball detection quality is not read as generalization performance.

Single Primary Metric, Paired Comparison, Seed Median

• The primary metric is fixed to a single one: rally winner accuracy. Secondary metrics (correct without confirmation, needs confirmation, no decision, bounce F1, ms per frame, decision latency) are recorded together, but do not change the primary metric. This is to prevent cherry-picking the best-looking metric among many.
• Evaluated via paired comparisonof the same rallies. We use McNemar's exact test and paired bootstrap 95% intervals (10,000 iterations). Since recounting the same rally under multiple degradation conditions is not independent, intervals in those cases are noted as optimistic.
• For learning-based models, we record the median and range of 3–5 seeds. As seen in the keypoint model, a single seed could increase confident&incorrect counts by 1–2 within a single batch.

Pre-registering Decision Rules Before Seeing Results

For several experiments (needs-confirmation correction v3, edge lines, full camera scoreboard, keypoint model), adoption criteria were written in the log before seeing the results (pre-registration). For example, the keypoint model criterion was: "increase confident&correct cases across 35 new frames, do not increase confident&incorrect cases in any batch, based on the median of three seeds." Even if some criteria were not met, we recorded them without hiding anything. For the keypoint model, after seeing the test results of the first decoding, we designed a second decoding and ran the test twice, recording everything as-is in the log and Part 4.

Real-Time Budget

• Causal processing: Frames after the decision timestamp are limited to a short lookahead (default 200ms or less). Methods that decide after viewing the entire rally are separately categorized as "recorded tracks" and not mixed in.
• Frame budget: At 60fps, 16.7ms per frame. The sum of new modules must be 5ms or less per frame.
• Decision latency: Rally end → score within 1.5 seconds.
• Methods exceeding the budget are classified as "real-time impossible" even if their accuracy is high. Pose integration (approx. 25ms per frame) was rejected for this reason.

Rulings Born from Failures

• R1. Coordinate-level synthetic occlusion does not replace real occlusion. The benefits of development experiments that simulated occlusion by erasing points from ball coordinates did not transfer to real video degradation (drawing occlusion ellipses on the video). This is because in real occlusion, detections tend to jump to random locations rather than simply disappearing.
• R2. Learning-based modules are trained by mixing 30fps copies. This is because the filter trained exclusively on 60fps broke down at 30fps (Part 4).
• R7·R8. Label correction. We found and split dataset labels where multiple rallies were bundled together, and those corrections formed the basis of correction v2.

Code Licensing Principles

We do not import GPL, AGPL, or MPL code, but re-implement methods from scratch. Training materials for each model are recorded in the weight metadata (nc_sources) and the log. This record serves as the basis for determining what needs to be retrained during commercial transition (Section 6).

5. Current Empirical Figures at a Glance

The last line is the most important. All numbers so far have come from public videos: research-grade videos well-shot with fixed cameras, broadcast footage, and synthetic degradation. There are yet no figures for what users actually use: "a smartphone mounted on a tripod at a local table tennis club." Obtaining those figures requires self-filmed videos with manual labels, which leads directly to the task in the next section.

6. Path to Commercial Service: Direction and Principles

TT Lab decided on October 18, 2026, to pivot toward a commercial service, and accordingly, we are replacing training data and weights with those permitted for commercial use. This section outlines only the direction, principles, and plans. All judgments are based on data and statements in the repository and do not replace legal review.

Principles

1. Operational models are trained on materials permitted for commercial use. Four types of materials can be used: self-filmed and self-labeled videos, synthetic materials created with our own code (table drawings, synthetic rally trajectories), public videos permitting commercial use such as CC BY, CC0, and public domain, and corrections reviewed by users who consented to training usage (Part 6).
2. Non-commercial (NC) datasets are used exclusively for internal research and evaluation. The non-commercial data in the dataset table above will be used to research and benchmark the engine, but not as training material for commercial services. Its use in evaluation is also subject to legal review (below).
3. Public assets are created using commercially usable originals. Demo videos on the site were recreated using commercially usable originals in alignment with the commercial transition (2026-10-24–25). The camera scoreboard demo was newly filmed using CC BY league broadcast footage, and author attribution, licenses, and modifications are displayed on screen for each original.
4. Training materials are recorded for each model. We leave materials in the weight metadata (nc_sources) and the research log so that we can determine at any time which model needs to be retrained with what.
5. GPL, AGPL, and MPL code are not imported. We re-implement methods from scratch (Section 4).

First Case Built Under These Principles

The table tennis keypoint model in Part 4 is the first model built from scratch using these principles. It was trained with an Apache-2.0 encoder, 80% self-synthesized drawings, and 20% CC BY 3.0 broadcast footage (12 matches), while non-commercial datasets were used solely for testing (metadata nc_sources=[]). How to attribute CC BY in the trained weights will be determined through legal review.

Plan

• Learning-based filtering and correction. The bounce filter and "needs confirmation" correction from Part 4 can be retrained without videos because their inputs consist only of ball trajectories and judgment features. The fastest path is to generate trajectories using synthetic rally code and verify them with a small set of self-labeled matches. Accumulated correction logs will also be used as training material for correction.
• Ball model. We are also preparing a path to train the ball model using self-filmed and self-labeled data. This requires labeled videos and a large GPU, which is where the training platform from Section 3 truly becomes necessary.
• Rule engine thresholds. Constants manually determined while observing public matches will be re-validated and adjusted using our own test set.
• Self-filmed test set. Placed at the highest priority as it resolves both the evaluation discussion and the "unmeasured smartphone field accuracy" issue.

What Happens to Evaluation Data?

Evaluationcurrently uses non-commercial data. The 7 public test matches form the basis for almost all numbers in this article. Whether it is permissible for a commercial company to use non-commercial data for internal evaluation is a legal question depending on the interpretation of "non-commercial" in data licenses, so we do not conclude it here. There is only one technologically certain path: to build a labeled, self-filmed test set. Doing so simultaneously fills the biggest blank: "unmeasured smartphone field accuracy."

7. Summary

• Accuracy figures so far have mostly been measured on non-commercial public data, and commercially usable actual training materials are still scarce.
• Training is small-scale: a few minutes on a laptop CPU, and 20–70 minutes in a disposable laptop GPU pod. Kubeflow is installed but not yet used for scoring engine training.
• To keep numbers trustworthy, we adhere to fixed splits, a single primary metric, paired comparisons, seed medians, pre-registration, and real-time budgets, and we explicitly note any deviations.
• In alignment with the commercial service, we are replacing training materials and weights with commercially usable ones. Non-commercial data is used strictly for internal research and evaluation, and retraining starts from self-filmed, self-labeled, and synthetic data.

TT's Word. Just as important as how accurately the model predicts is "whose data it learned from." That is why we now aim to study using notebooks we filmed and drawings we made.

References

1. R. Voeikov, N. Falaleev, R. Baikulov. "TTNet: Real-time Temporal and Spatial Video Analysis of Table Tennis." CVPR Workshops, 2020. arXiv:2004.09927. OpenTTGames data CC BY-NC-SA 4.0 (statement on data release page).
2. T. Gossard, J. Schmalzl, A. Ziegler, A. Zell. "Sound-Based Spin Estimation in Table Tennis: Dataset and Real-Time Classification Pipeline." IEEE STAR, 2025. arXiv:2409.11760. Data CC BY-NC 4.0 (repository README).
3. T. Gossard, F. Radovic, A. Ziegler, A. Zell. "BlurBall: Joint Ball and Motion Blur Estimation for Table Tennis Ball Tracking." CVPR Workshops (CVsports), 2026. arXiv:2509.18387. Code MIT.
4. N. Ravi et al. "SAM 2: Segment Anything in Images and Videos." ICLR, 2025. Code and checkpoints Apache-2.0.
5. Y. Xiong et al. "Efficient Track Anything." ICCV, 2025. Code and checkpoints Apache-2.0.
6. Extended OpenTTGames (rally end reasons, winner, stroke labels). arXiv:2512.19327. CC BY-NC-SA 4.0.
7. Our measurements and records: Repository docs/tt/PERFORMANCE.md 2.1·2.10·2.19, docs/study/tt-score-models/07-datasets.md(data counting), Research Ledger Section 0 (experimental rules) · Ruling · E00 · E25 · E27 · E33 · E35 · E44, deploy/ training task guide document below, backend/app/tt_score_demos.py preface (original demo).

Further Reading

• This series Part 4: Model Principles and Papers: The structure and measured results of the three training models presented here.
• This series Part 6: Match Records and Privacy: Conditions under which human-corrected rulings can become training material again.
• Previous series TT Score Model Anatomy Part 7: Counting Table Tennis Datasets Directly.