Model Principles and Papers: The Ball, the Table, and Three Models We Trained Ourselves

Status: Draft (2026-10-26), empirical measurements reflected. Numbers marked as "Paper" are values verified by opening the original papers and official repositories, while other numbers are values measured directly by us using public videos and synthetic diagrams. Accuracy for mobile field footage is unmeasured. Bibliographic references whose original texts could not be fully verified are noted as such in the bibliography. Writing Rule: Empirical data is the baseline, and unmeasured items are marked as "Unmeasured."

Table of Contents

• 1. Map: Which Model Runs Where
• 2. The Ball: Drawing Maps Instead of Guessing Coordinates
  • Why It Is Difficult
  • Lineage: TrackNet → WASB → BlurBall
  • Our Usage
  • Empirical Measurements
  • Fine-Tuning Attempt: Why It Was Disabled
• 3. The Table: Detect, Verify, and Track
  • Detection Chain
  • Re-evaluating the Detected Rectangle
  • Tracking: Pyramidal Lucas–Kanade and RANSAC
  • From Four Corners to Table Plane: Homography
• 4. The Three Models We Trained
  • ① Filtering False Bounces: 18K-Parameter 1D CNN
  • ② Correcting "Needs Verification": 19-Feature Logistic Regression
  • ③ Table Corner Model: Frozen Encoder and Small Heatmap Head
• 5. Posture and Sound: Signals Left Out
  • Posture (RTMPose): Coaching Only
  • Sound: Excluded from the Engine
• 6. Conclusion
• References
• Further Reading

1. Map: Which Model Runs Where

The perception component of automated adjudication is a combination of several models and classical algorithms.

This article explains the principles sequentially from top to bottom, presenting the concepts from the research papers alongside our own implementations. Since the lineages of the ball and table models are covered in more detail in Part 2·andPart 3 , we will recap the key points here and follow them withwhat has changed since then We place weight onwhat we have learned.

2. Ball: Draw a map, do not guess coordinates

Why it is difficult

A table tennis ball is 40mm in diameter. On a screen reduced to 512x288, it is only a few pixels wide, and a fast ball blurs into a long streak of muted lines during a single frame exposure. It is frequently occluded by the paddle and body, and a white ball is easily confused with white clothing, lighting, and wall patterns.

Lineage: TrackNet → WASB → BlurBall

TrackNet(2019)[3] introduced two main ideas. First, instead of directly predicting the ball's (x, y) coordinates as two numbers, it has the network draw a heatmapwith a raised peak where the ball is likely to be. Since convolutional neural networks apply the same judgment across spatial positions, outputting a spatial map suits their architecture, and smooth ground-truth targets stabilize training. Second, it feeds three consecutive frames together . A single frame cannot tell whether a white dot is a ball or dust, but three frames reveal what is moving as the ball.

WASB(2023)[2] combined three elements targeting a standard baseline applicable to multiple sports: a lightweight HRNet-family backbone [16] that preserves resolution to the end, real-valued heatmaps and quality focal loss that shrink with distance, and inference that discards distant candidates by predicting the next position using an accelerated motion model.

BlurBall(2025–2026)[1] is our ball model. The core difference lies in where the labels are placed. Existing datasets marked the leading edgeof the blurred ball as its position, which the paper points out is asymmetric and discards velocity information contained in the blur. Therefore, the paper places the ball position at the center of the blurand labels the blur direction (Θ) and half-length (l) together. The ground-truth heatmap also covers the entire stripe connecting both ends of the blur rather than just a single point. Its structure adds channel attention (Squeeze-and-Excitation) to WASB's HRNet backbone.

The output heatmap is thresholded (0.7 in the paper) to form blobs, and performing Principal Component Analysis (PCA) on those pixels yields the principal axis angle as the blur angle and half the projection range on the principal axis as the blur length. The confidence score is the averageof the blob values, because using the sum would unfairly favor longer blurs (paper). Since the blur vector provides a velocity cue during exposure time, the paper reports that incorporating it when fitting a quadratic polynomial to the first 3 frames reduced the trajectory prediction mean error from 84.4px to 53.0px (paper). We do not yet use the blur direction for judgment because converting blur into velocity requires knowing the camera exposure time, and mobile phones can change exposure per frame.

Our usage

• The weight size is 5.8MB, and the input is a window of 3 frames at 512x288 resolution. The real-time pipeline uses only the heatmap of the last frame in the window (to avoid waiting for future frames).
• We use the author's weights as-is without fine-tuning . When loading, we verify the sha256 and read them weights_only=True only (Part 1).
• If there are multiple candidates, we select the one with the highest score among candidates within 80px on a 512 screen from the previous ball position. This is a very simplified version of WASB's "discarding distant candidates from prediction".
• Just before detecting the ball, the 0.5% and 99.5% brightness percentiles of each frame are stretched to 0 and 255 (TTSCORE_BRIGHTEN, no training). Under synthetic "dark" conditions (brightness × 0.25 + noise), matches in 7 test games using the real-time pipeline increased from 34 to 51 (McNemar p=0.0001), while clean footage showed no significant loss at 53 vs 54 (2026-10-14, log E18). Calculations take 1.6ms centrally on a laptop CPU. Gains on actual dark table tennis footage from mobile phones have not been measured.

Actual measurements

One reason why public test games show near-perfect results must be read with caution. Since the BlurBall training video list is not public, it is unknown whether it overlaps with the public games we use for testing. Therefore, we do not interpret these numbers as generalization performance and instead include numbers from other labs and broadcast footage.

Fine-tuning attempt: Why it was turned off

To make the model more robust to complex backgrounds and dark conditions, we created a self-distilled fine-tuned version (clutter-v1) using the production weights as a teacher (log E31). Mixing 20% clean footage, 40% complex background, darkness, low resolution, blur, JPEG artifacts, camera shake, and 30fps, it was trained for 69 minutes and 8,934 steps on a disposable laptop GPU (8GB class) pod. Under synthetic degradation, ball recall rose from 0.752 to 0.949 for severe degradation and from 0.685 to 0.924 for darkness. However, it failed to meet a single activation condition for the actual pipeline test ("missed incorrect answers should not exceed production", 10 vs 8), so we turned it off.

3. Table: Find, Verify, Track

To figure out "where the ball landed," the four corners of the table are needed. Table processing involves three steps: find oncebefore the match starts, verifywhether the found rectangle is actually a table, and then track

Figure: Table finding chain, merging with corner model, optical flow tracking

Finding chainlive/tablemodels.pyFinding is a chain of trying multiple models in sequence and falling back to the next if one fails ( sam3 → efficienttam → color ). The real-time operator setting is , but SAM 3 in the first slot is actually not invoked for the reasons below, so it runs as EfficientTAM S → Color-based (verified operational worker status on 2026-10-25, log E44). The recorded footage worker is efficienttam → sam2 → color .

SAM 2[4] is a model that segments video by streaming it frame by frame. On each frame, an image encoder runs once, and current frame features perform cross-attention with the memory bank(features of recent frames and frames where the user provided points and boxes) to remember previously segmented objects while viewing the current frame. There is also an occlusion head that separately predicts whether an object is visible in the current frame. In our use case, prompt-based segmentation—"giving a few points on the table to output the mask of that object"—is key.

EfficientTAM[5] is a lightweight version of SAM 2. The paper attributes SAM 2's heaviness to its hierarchical image encoder and memory module, replacing the encoder with a plain non-hierarchical ViT (Tiny/Small) and reducing the number of tokens to 1/4 by average pooling keys and values to 2x2, exploiting the property that spatial tokens in memory are nearly identical to their neighbors. The paper reports accuracy comparable to SAM 2 (HieraB+) while being about 2x faster on an A100 and having about 2.4x fewer parameters (paper). Sizes are 18M for Ti and 34M for S. Mobile phone speeds are not transcribed here because the numbers in the paper's abstract and main text tables do not match.

SAM 3[6] uses short textto find all objects corresponding to that concept. It is characterized by separating "Is it there?" and "Where?" as a presence token to independently determine "Is that concept in this image?" Since a human does not need to click points, it is the principle best suited for automatic initialization of the first frame. However, we cannot use it yet.

• is a method where weights require access approval to be received (a gate), and they cannot be received before approval.
• The worker image is Python 3.11, but SAM 3 requires 3.12 or higher, causing it to fail at the loading stage and drop to the next step. This is the price paid for the deployment method of Part 1, which "layers code onto images without baking them."
• It is heavy with 848 million parameters. It is better suited for initialization or labeling assistance than a real-time loop.
• The SAM License does not explicitly block commercial use in its text, but unlike Apache and MIT, it includes conditions for unilateral terms changes, termination upon litigation, prohibition of reverse engineering, and export controls. Legal review is required first if you want to use it in a commercial service.

Color-based trackingis a fallback path when a GPU is not available. It finds rectangles using the color of the table top and the white lines. The server side has ttscore/tablefind.py, and the browser side also has a copy of the same logic.

Condition: 7 find conditions in public bundle × 103 frames = 721 frames, same post-processing, 2026-10-13(docs/tt/PERFORMANCE.md 2.12). Therefore, the first operational slot is EfficientTAM S.

Re-evaluating found rectangles

Just because the segmentation model found "something" does not guarantee it is a ping-pong table. The found rectangle is re-evaluated through seven checks(ttscore/tablecheck.py, check names color, facing, tall, flat, uneven, spill, noline). These include whether the top color looks like a ping-pong table, whether the rectangle's orientation, height, and flatness look like a ping-pong table, whether the side lengths are even, whether it overflows the table, and whether white lines are visible. If even one check fails, the confidence score is lowered below the "sure" threshold of 0.55, and the screen prompts the user to either "tap please" (tap the table once) or "pick directly" (pick the four corners yourself).

Tracking: Pyramid Lucas–Kanade and RANSAC

Finding takes a heavy 1–2 seconds, so it cannot be done every frame. To ensure the corners are not lost even when the phone shakes or the broadcast camera moves, after finding them, they are tracked with optical flow.(live/tablecv.py).

• Lucas–Kanade[9]: Assumes that "the brightness inside a small window remains the same even when it moves," and iteratively finds the displacement between two images using spatial gradients of the video. It is fast because it is a small least-squares problem for a single window.
• Pyramid[10]: Since large movements cannot be caught with a small window, the rough movement is found at the top of a pyramid where the video is reduced into multiple levels, and then passed down and refined at lower levels. Our setting uses a 21×21 window with the pyramid going up to three levels above the original.
• Good features to track[11]: Points (corners) with large small eigenvalues of the gradient matrix are tracked well. They are first selected from locations expanding the ping-pong table rectangle by 12% (white lines, net, corners, legs), and if points are insufficient due to the featureless top surface, they are filled from the entire screen. This is because hand shake causes the entire screen to move together.
• Forward-backward consistency check and RANSAC[14]: Points that move independently, like players and the ball, must be discarded. Points moved from reference → current are moved back from current → reference, and if they deviate by more than 1.5px, they are discarded. RANSAC homography (3px threshold) is then calculated using the remaining points.
• Preventing cumulative error: Since errors accumulate when frames are chained together, we always map directly from the reference screen to the current frame. The result of the immediately preceding frame is only provided as an initial estimate.
• Cuts and recovery: Scene changes (cuts) are detected using differences in a screen reduced to 64×36, and when returning to the same camera view after a cut, they are matched instantly without a model using ORB features of a saved reference screen (up to 4 frames).

Dense optical flow like Farnebäck[12] was only used in experiments measuring overall screen movement amounts, and sparse Lucas–Kanade was right for ping-pong table tracking because only a single rectangle moves and it must be executed every frame.

Synthetic experiments show why tracking is so important (2026-10-13, log E12). When ball coordinates were used as-is on the screen, match accuracy in pan/zoom video dropped from 50 to 24–40, but completely recovered when projected back to the plane using the ground-truth homography. An even more interesting finding is that jitter matters more than accuracyin breaking judgments. A homography estimated separately per frame lost 5–10 rallies with just 2px of jitter, whereas temporally continuous (propagated) estimation performed on par with the upper bound even with 5px of error. Bounce judgment looks at the V-shape of screen y, and inter-frame jitter creates fake V-shapes. Therefore, operations smoothly track via optical flow (60Hz) every frame.

From four corners to the table plane: Homography

Points on a plane are mapped in the camera image by a single 3×3 matrix H [13]. Excluding scale, H has 8 degrees of freedom, and since each pair of corresponding points provides two equations, 4 pairs determine it(three of the four must not lie on a straight line). By constructing H with four corners on the screen ↔ four real table corners (2.74m × 1.525m), the ball at the moment of bounce can be mapped to meter-scale table coordinates.ttscore/table.py).

There are two pitfalls.

• It only applies to points on the plane. Since a ball in the air is not on the plane, it is only used at the exact moment the ball touches the table. The ball center at the bounce moment is also 20mm above the contact point, so it is adjusted accordingly.
• Four points alone do not indicate which side is the long side. Any rectangle can be mapped to a rectangle in two ways. The code resolves this if a human or data specifies the end sides, otherwise by using points clicked on each of the two table halves, and if even those are absent, by calculating the focal length and actual length ratio using the orthogonality condition of two vanishing points.

4. The three models we trained

From here on, these are models we trained ourselves, not author weights. All three are small, and all three occupy roles that "filter or verify what rules or large models have already done."

① Filtering fake bounces: 18K-parameter 1D CNN

Problem. In Part 3, if a single bounce is wrong, the entire sequence goes out of order. Bounces produced by rules mix in fakes, such as hits read as bounces or net-crossing balls shaking.

Model. A small 1D convolutional neural network that looks at a short window of ball trajectories(ttscore/bounceveto.py). The input consists of the judgment frame and 9 features from the preceding 16 frames (ball visibility, detection confidence, net-relative x and y, velocity, whether it is above the table top, inside the net band, or outside the end), and after three convolutional layers, a small MLP outputs the probabilities of a bounce, hit, or net pass. It has 18,179 parameters.

Usage: Filtering only. We use this model to not create new bounces, but merely discard rules-generated bounces whose probabilities within ±2 frames are all below 0.3. This decision came from experiments. Making the model predict bounces by itself collapsed when used without look-ahead (0 future frames) because it failed to see right after a bounce, spreading probabilities forward. Filtering, however, needed 0 look-ahead because the rules already established the positions (log E01). Thus, latency addition is 0, and computation takes about 0.1ms per frame on a laptop CPU.

Training. Learned using ball trajectories and bounce, net, and hit markers, mixing 60fps even frames + 30fps copies + copies with 15% and 30% occluded coordinates. Trained on a laptop CPU (2026-10-13, logs E01 and E05). The reason for mixing 30fps copies was that the initial version actually degraded by 6–11 percentage points on 30fps inputs (out of distribution). The mixed version eliminated losses at 30fps. From this, the rule that all learning-based modules must always mix 30fps copies (log Ruling R2) was established.

Field test(direct real-time pipeline, 7 public test games × 11 degradation conditions, 627 rallies × conditions, 2026-10-13, log E08):

In pairwise comparison, it was +4.9 percentage points (since the same 57 rallies were recounted across 11 conditions, samples are not independent so the interval is optimistic). The control group is important. In clean development games, "discarding low-confidence bounces" scored identically to learned filtering, but under actual degradation conditions, it collapsed completely in reverse. This is because detection confidence drops together even for true bounces when lighting darkens. The benefit of learned filtering comes from looking at trajectory shape, not from "discarding low-confidence bounces."

We also found one limitation. When occlusion near the bounce erased the V-shape, interpolated trajectories yielded low probabilities, causing real bounces to be discarded (occlusion subset 41 → 38 in log E11). Therefore, filtering was paused if there were samples where the ball was not visible near the bounce (log E17).

② Correcting "Needs confirmation": 19-feature logistic regression

As seen in Part 3, "confidence < 0.6" failed to distinguish errors (AUC 0.51). We trained a logistic regression model to output the probability that a judgment is incorrectusing 19 values the engine already knows at the moment of judgment(ttscore/reviewcal.py).

Logistic regression has two advantages: training data (judgments run under various degradation conditions) does not need to be massive, and results can be explained to humans. Linear models allow us to directly read how much each feature "pushed toward error," immediately generating the chip's excuses ("lost the ball," "long rally") from those contributions. Calculation is a single dot product per judgment.

Training material consists of judgments run directly through the real-time pipeline and the winning ground-truth of those rallies. v2 incorporated label correctionsinto the same features. This was because correct engine judgments were being learned as "incorrect" in places where ground-truth labels grouped multiple rallies together (logs R7, R8, E25). The threshold was chosen via 5-fold cross-validation per training game unit, and the v2 threshold is 0.0442. Results are in the table in Part 3, Section 5. Incorrect without confirmation (including ghosts) decreased from 20 to 8, and needs confirmation increased from 450 to 497.

One thing to note. Because the correction is learned from the judgment distribution produced by the ball model, changing the ball model requires changing the correction as well. Leaving v2 unchanged atop fine-tuned ball weights caused incorrect without confirmation to increase from 14 to 28 (log E31). Therefore, a separate v3 was trained as a pair.

③ Table corner model: Frozen encoder and small heatmap head

Problem. On 2026-10-25, we tested where the production find chain fails using 35 new images (26 league broadcast clips, 4 4K club side-views, 2 1934 vintage film clips, and 3 laboratory diagonal-views, all commercially usable open-source footage), resulting in: Zero-tap correct & confident: 0/35 (Log E42). Analyzing the cause, in side- and diagonal-views the net splits the top surface, making the split mask almost always half, and pushed the floor and wall masks—which had higher selection scores—to the top. We tested seven post-processing tweaks (grid prompts, expansion lower-bound, white line threshold, half-merging, half-inspection, etc.), but none satisfied the condition of "improving on the new batch without getting worse anywhere." It was a fundamental limitation of stitching rectangles together in the mask space.

Idea. Bypass masks and output vertices directly . Much like human pose estimation draws heatmaps for each joint [15][16][17][18], we output two heatmaps: one for the four table corners and one for the two net ends.

Architecture. We freezethe image encoder of EfficientTAM S already used by the production find chain (same weights, Apache-2.0), and stack a small head with a few convolutional layers (approx. 640k parameters) on top of its 64×64×256 features to output two 128×128 heatmaps. One heatmap is for the four corners, and the other is for the two net ends. Because table tennis tables are symmetric, we do not assign names to the corners (such as top-left); instead, we read the four peaks in perimeter order. The loss is weighted MSE against a σ 4px Gaussian target.

Why freeze? We only had 12 real training images. When pretrained features are good and training conditions differ from deployment conditions, some analyses suggest that if the backbone is trained jointly while the head is still garbage early on, the pretrained features can become distorted, degrading out-of-distribution performance [19]. Because that paper primarily deals with linear heads in classification tasks, we use it only as a principle-level rationale. There was also a practical reason: production already uses the same encoder weights, so there were no new weights or packages to download. We have not yet experimented with unfreezing the encoder.

Training Data: 80% synthetic, 20% real. We used only commercially usable data.

• Synthetic: We rendered table tennis tables (dimensions 2.74 × 1.525 × 0.76m, net 15.25cm) drawn with our code across random camera setups (distance 2.4–15m, FOV 35–100°, height/tilt), lighting, blur, noise, JPEG, monochrome, floors, background walls, adjacent tables, and human panels. No external images were used. Because the renderer knows the exact corner coordinates, manual labeling was not required. The net-end labels were defined as the points where the net intersects the long sides at the height of the table(the middle of the long sides).
• Real: 12 images from a 2015 Slovenian league broadcast (Wikimedia Commons, CC BY 3.0) not overlapping with the test set . We augmented them via scaling, translation, rotation, color adjustment, and horizontal flipping.
• Excluded: Other footage from the same gym as the club videos used in testing, and other footage from the same lab/cameras as the lab videos in testing. Even though we generated labels for them, we did not include them in training. Including them would make the test overly optimistic. Non-commercial datasets were used exclusively for testing.

This design follows the philosophy of domain randomization [20][21]. The idea is that if you intentionally and wildly vary rendering so that it is unrealistically chaotic, real footage becomes "just another variation" among the countless variations the model has seen. The pipeline of training purely on synthetic data and then supplementing with a small amount of real data is a direction demonstrated by [21]. In table tennis, previous research has explored training ball and table 2D detection solely on real labels, while learning 2D-to-3D trajectories purely through physically plausible synthesis [22].

Training consisted of 2,500 iterations × batch size 12 (= 30k images) with AdamW and a fixed seed set, taking about 20 minutes per run on a disposable laptop GPU pod (5 runs). We used the final weights without selection.

Decoding: Trust the geometry, not the peak magnitude. The initial decoding strategy ( preregistration: confident if the minimum of the four corner peaks is ≥ 0.5) was rejected. Peak magnitudes learned from synthetic data almost always exceeded 0.5 on real images. This is overconfidence. There were many cases where three corners were correct while one latched onto a scoreboard or net post.

Therefore, we created a second decoding strategy (d2) (ttscore/tablekp.py). We select four out of the top six peaks from the corner heatmap to form a convex quadrilateral, and use that quadrilateral alone to calculate where the net ends should be, matching them against the peaks in the net heatmap.

1. The intersection point of the two diagonals of the quadrilateral represents the centerof the actual table even under perspective (projective center).
2. The line connecting that center and the vanishing point formed by extending the two end sides represents the "line where the net is placed" in perspective.
3. The points where that line intersects the two long sides are where the net ends should be.

Because the net and corners are separate heatmaps, checking that they match geometrically provides evidence independent of peak magnitude. The condition for confidence is "minimum peak ≥ 0.5 and net-end distance ≤ 12px." The 12px threshold was chosen from values of 8, 12, 16, and 24 using a validation set(300 synthetic images + 4 real images excluded from training). Confident & incorrect cases on the validation synthetic set dropped from 54–68 down to 5–9.

This calculation uses only points on the table plane. Although the top of the net is 15.25 cm above the plane and should not be included in homography, our net-end labels are points at table height, and even then, we use them only for validation and to determine which side is the end side, not in homography calculations . Homography is calculated exclusively using the four corners.

Merging: Policy D. The corner model does not replace the existing find logic; they are evaluated together.

Adoption criteria were established and logged in the project record prior to viewing results (preregistered): confident & correct must increase on the new 35 images, and confident & incorrect must not increase on any batch (median of the seed set).

Actual Measurement: Research Testing(204 test images, confident & correct / confident & incorrect, 2026-10-25, Log E43, docs/tt/PERFORMANCE.md 2.19):

A version trained solely on synthetic data (using the same decoding) yielded more confident & correct results on the public batch (+24) but also increased confident & incorrect cases, failing to meet the criteria. The 12 real images effectively curbed overconfidence. Running the production code as-is (seed 2 weights, 2.5MB for the head only) scored 89 / 22, taking an additional 40ms per find on a laptop GPU.

We honestly note three limitations.

• We evaluated the test set twice. The d2 decoding was designed after inspecting the test results of the first decoding. While the threshold was chosen via validation, the design itself was influenced by the test set.
• Gains were concentrated in one area. All four gains on the new 35 images came from different segments of the same broadcast used for training, and the gain on the public batch came from side-view footage. The 4K club, vintage film, and lab diagonal views remained at 0. Generalization to other gyms or broadcasts was not demonstrated with this dataset.
• Labels were not annotated by humans. The corners for the 12 real training images and 35 new test images were read by an AI annotator using a 2x magnified grid, and occluded distant corners were calculated via vanishing points and marked (approx. ±5px).

Actual Measurement: Post-Activation in Production(Night of 2026-10-25 – dawn of 2026-10-26, Log E44). On 2026-10-25, we enabled the corner model in the production real-time worker. Afterward, 212 test images were sent to the production worker at JPEG quality 70 (matching the camera scoreboard), and logs confirmed that the corner model executed for all 212 responses. Mimicking the screen flow (done if confident without tapping, one tap if not, or manual four-corner point if still not), we evaluated 204 images from three datasets with ground truth. For the baseline (corner model disabled), since production could not be turned off, we ran the same code on a disposable laptop GPU pod using the same JPEG images.

There were trade-offs. The corner model introduced 5 newly incorrect confident cases (max 114px — in different segments of the same training broadcast), while eliminating 8, bringing the total down from 26 to 23. Looking solely at the 27 clips grouped by filming condition, confident & incorrect increased from 3 to 4. Since it did not violate the deactivation criteria (confident & incorrect exceeding baseline or errors), we decided to keep it enabled.

This comparison contains some variance. The baseline was run on a different GPU, causing the existing find's confidence to differ from production on 14 out of 204 images (due to GPU differences). Additionally, at JPEG quality 70, the existing find performed worse than on lossless images (71/22 → 61/26), so these figures should not be directly compared to the research test numbers. Actual browser-based end-to-end screen tests were not conducted, and the table above simulates the screen flow rules.

5. Pose and Audio: Unused Signals

Pose (RTMPose): Coaching Only

RTMPose [7] is a top-down method that first detects human bounding boxes (RTMDet) and estimates poses for each person cropped out. Instead of heatmaps, it uses SimCC [8] to formulate keypoint localization as two classification problems: x-coordinate classification and y-coordinate classification . The idea is to subdivide each pixel into multiple bins to achieve sub-pixel precision even at low resolutions.

TT Lab uses this model only for precision analysis in coaching screens(ttcoach/pose.py). Experiments integrating it into the scoring engine were conducted twice and rejected both times.

• Filtering out bounds using pose dropped rally winner accuracy on 12 public match videos from 93.1% to 87.6–92.0% (PERFORMANCE 2.9.5).
• Combining pose with fake bound filtering showed minor improvements in occluded sections but did not surpass using rules alone. Crucially, pose estimation took 24.6–25.0ms per frame on the GPU, exceeding the 5ms budget for new modules (Log E11). It is "impossible for real-time."

Audio: Not included in the engine

The time the ball is in contact with the surface is very short at 1.3–1.8 ms, so sound can indicate "when" much more precisely than the video frame interval (33 ms for 30 fps) [23]. In a clean recording dataset, our classifier also distinguished between table tennis table and racket sounds 99.3% of the time. However, in actual training ground recordings, we could not confirm an effect on the score (PERFORMANCE 2.7·2.9.6, previous series Part 6). Performance on clean recordings dropped significantly in the presence of noise and sounds from neighboring table tennis tables.

Therefore, the real-time pipeline does not receive sound. The camera scoreboard does not request audio when opening the camera (getUserMedia({audio:false})), and recorded footage analysis discards sound. We were unable to find any research papers on table tennis scoring combining video, sound, and pose within the scope of this survey (with the caveat that the search scope was narrow) [24][25].

6. Conclusion

• The ball uses BlurBall, the end of the lineage of "heatmap + multiple frames + center of blur," using the authors' exact weights. Since the training data was not released, we do not interpret public test figures as generalizability.
• The table tennis table is detected once using a segmentation model, reviewed in seven ways, and tracked every frame using pyramidal Lucas–Kanade and RANSAC. What broke the judgments was more of a frame-to-frame jitterthan vertex error.
• All the sets we trained are small and occupy a position of filtering or verifying the results of rules and larger models. They consist of an 18k-parameter filter, a 19-feature regression, and a 640k-parameter head.
• The vertex model reduced operational "please tap here" prompts by 17%, but generalizability to other gymnasiums has not yet been observed. Real commercialized data from other gymnasiums is the next task.

TT Note. Initially, the vertex model insisted it was always right. So we made it double-check, "Is the actual net end really where the net end should be?", and it became much more humble.

References

1. 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.
2. S. Tarashima, M. A. Haq, Y. Wang, N. Tagawa. "Widely Applicable Strong Baseline for Sports Ball Detection and Tracking." BMVC, 2023. arXiv:2311.05237.
3. Y.-C. Huang, I.-N. Liao, C.-H. Chen, T.-U. İk, W.-C. Peng. "TrackNet: A Deep Learning Network for Tracking High-speed and Tiny Objects in Sports Applications." arXiv:1907.03698, 2019.
4. N. Ravi et al. "SAM 2: Segment Anything in Images and Videos." ICLR, 2025. arXiv:2408.00714. Code and checkpoints Apache-2.0.
5. Y. Xiong et al. "Efficient Track Anything." ICCV, 2025. arXiv:2411.18933. Code and checkpoints Apache-2.0. (Conference publication verified via references in other papers; conference one-pager not viewed)
6. N. Carion, L. Gustafson, Y.-T. Hu et al. "SAM 3: Segment Anything with Concepts." ICLR, 2026. arXiv:2511.16719. SAM License (2025-11-19).
7. T. Jiang, P. Lu, L. Zhang, N. Ma, R. Han, C. Lyu, Y. Li, K. Chen. "RTMPose: Real-Time Multi-Person Pose Estimation based on MMPose." arXiv:2303.07399, 2023.
8. Y. Li, S. Yang, P. Liu, S. Zhang, Y. Wang, Z. Wang, W. Yang, S.-T. Xia. "SimCC: A Simple Coordinate Classification Perspective for Human Pose Estimation." ECCV, 2022. arXiv:2107.03332.
9. B. D. Lucas, T. Kanade. "An Iterative Image Registration Technique with an Application to Stereo Vision." IJCAI, 1981, pp. 674–679.
10. J.-Y. Bouguet. "Pyramidal Implementation of the Lucas Kanade Feature Tracker: Description of the Algorithm." Intel Corporation, Microprocessor Research Labs, 2000. (Full text not opened; bibliography and OpenCV citations verified)
11. J. Shi, C. Tomasi. "Good Features to Track." CVPR, 1994, pp. 593–600.
12. G. Farnebäck. "Two-Frame Motion Estimation Based on Polynomial Expansion." SCIA, 2003, LNCS 2749, pp. 363–370.
13. R. Hartley, A. Zisserman. Multiple View Geometry in Computer Vision, 2nd ed. Cambridge University Press, 2004. Chapters 2 and 4.
14. M. A. Fischler, R. C. Bolles. "Random Sample Consensus: A Paradigm for Model Fitting with Applications to Image Analysis and Automated Cartography." Communications of the ACM 24(6):381–395, 1981.
15. A. Newell, K. Yang, J. Deng. "Stacked Hourglass Networks for Human Pose Estimation." ECCV, 2016. arXiv:1603.06937.
16. K. Sun, B. Xiao, D. Liu, J. Wang. "Deep High-Resolution Representation Learning for Human Pose Estimation." CVPR, 2019. arXiv:1902.09212.
17. X. Zhou, D. Wang, P. Krähenbühl. "Objects as Points." arXiv:1904.07850, 2019.
18. J. Tompson, A. Jain, Y. LeCun, C. Bregler. "Joint Training of a Convolutional Network and a Graphical Model for Human Pose Estimation." arXiv:1406.2984, 2014.
19. A. Kumar, A. Raghunathan, R. Jones, T. Ma, P. Liang. "Fine-Tuning can Distort Pretrained Features and Underperform Out-of-Distribution." ICLR, 2022. arXiv:2202.10054. Cited only at the principle level.
20. J. Tobin, R. Fong, A. Ray, J. Schneider, W. Zaremba, P. Abbeel. "Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World." IROS, 2017. arXiv:1703.06907.
21. J. Tremblay et al. "Training Deep Networks with Synthetic Data: Bridging the Reality Gap by Domain Randomization." CVPR Workshops, 2018. arXiv:1804.06516.
22. D. Kienzle, K. Ludwig, J. Lorenz, S. Satoh, R. Lienhart. "Uplifting Table Tennis: A Robust, Real-World Application for 3D Trajectory and Spin Estimation." arXiv:2511.20250, 2025.
23. 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.
24. S. Tsuji et al. "Audio-Visual Self-Supervision for Frame-Level Player-wise Offensive Shot Detection in Table Tennis Matches." MMSports '24, 2024. doi:10.1145/3689061.3689064. (Bibliography verified via search summaries only)
25. X. Zhou, Q. Huang, L. Xie, S. Cox. "Detection of Ball Hits in a Tennis Game using Audio and Visual Information." APSIPA ASC, 2012.
26. Our measurements: repository docs/tt/PERFORMANCE.md 2.1·2.8·2.12·2.19, research ledgers E01·E05·E08·E11·E12·E17·E18·E25·E31·E42·E43·E44. Code live/blurball.py·tablecv.py·tablemodels.py, ttscore/table.py·tablekp.py·bounceveto.py·reviewcal.py.

Further Reading

• Previous series TT Score Model Anatomy Part 2: Finding the Ball, Part 3: Finding the Table Tennis Table.
• Reading Vision Models Parts 1 and 3: U-Net and HRNet, Part 10: SAM 2 and EfficientTAM, Part 11: SAM 3.
• Reading Vision Models Parts 2 and 5: Optical Flow, Part 7: Pose Heatmaps, Part 9: Ball Tracking.
• This series Part 5: Data, Licenses, and Training Process: How and where training runs, and principles of training data tailored for commercial services.