File size: 9,062 Bytes
c6abe34
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
# Supabase configuration
SUPABASE_URL=your_supabase_url_here
SUPABASE_KEY=your_supabase_anon_key_here
SUPABASE_SERVICE_KEY=your_supabase_service_role_key_here

# JWT Configuration
JWT_SECRET=your_jwt_secret_here
JWT_ALGORITHM=HS256
JWT_EXPIRATION_MINUTES=1440

# Application settings
DEBUG=false
HOST=0.0.0.0
PORT=8000
REQUEST_TIMEOUT_SECONDS=120

# CORS (comma-separated list). Example:
# CORS_ORIGINS=http://localhost:5173,http://localhost:3000,https://yourapp.com
CORS_ORIGINS=

# File storage
UPLOAD_DIR=./uploads
MAX_UPLOAD_SIZE_MB=500
SERVE_UPLOADS_IN_DEBUG=true

# GPU settings
GPU_ENABLED=true
CUDA_DEVICE=0

# Model paths
PLAYER_DETECTOR_PATH=models/player_detector.pt
BALL_DETECTOR_PATH=models/ball_detector_model.pt
COURT_KEYPOINT_DETECTOR_PATH=models/court_keypoint_detector.pt
POSE_MODEL_PATH=models/yolov8n-pose.pt
# Train simple CNN model


What matters is not just that the model predicts 18 keypoints, but that your backend has a canonical meaning for each index so the system always knows:

which side of the court the point belongs to

whether it is boundary, paint, or midline

where it should land on the tactical map

how to recover if some points are missing or swapped

From your new model:

0 = far left, top boundary

10 = far right, top boundary

5 = far left, bottom boundary

15 = far right, bottom boundary

8 and 9 = centre line top/bottom

2, 3, 6, 7 = left paint box

12, 13, 16, 17 = right paint box

1 and 4 = left baseline inner markers

11 and 14 = right baseline inner markers

So the first thing is: your code must stop treating these as just “18 anonymous points”. It should treat them as a court geometry schema.

Recommended canonical keypoint meaning

Use this exact mapping in code:

COURT_KEYPOINTS = {
    0: "left_outer_top",
    1: "left_baseline_upper_inner",
    2: "left_paint_outer_top",
    3: "left_paint_outer_bottom",
    4: "left_baseline_lower_inner",
    5: "left_outer_bottom",

    6: "left_paint_inner_top",
    7: "left_paint_inner_bottom",

    8: "midline_top",
    9: "midline_bottom",

    10: "right_outer_top",
    11: "right_baseline_upper_inner",
    12: "right_paint_outer_top",
    13: "right_paint_outer_bottom",
    14: "right_baseline_lower_inner",
    15: "right_outer_bottom",

    16: "right_paint_inner_top",
    17: "right_paint_inner_bottom",
}

That gives the model output real meaning.

Very important logic rule

Your system should always think in two spaces:

1. Image space

These are the predicted coordinates from the model:

[(x0, y0), (x1, y1), ..., (x17, y17)]
2. Court space

These are the fixed coordinates on your tactical board.

For example:

COURT_MODEL_POINTS = {
    0:  (0, 0),
    1:  (0, 10),
    2:  (0, 20),
    3:  (0, 30),
    4:  (0, 40),
    5:  (0, 50),

    6:  (15, 20),
    7:  (15, 30),

    8:  (47, 0),
    9:  (47, 50),

    10: (94, 0),
    11: (94, 10),
    12: (94, 20),
    13: (94, 30),
    14: (94, 40),
    15: (94, 50),

    16: (79, 20),
    17: (79, 30),
}

These values are example tactical-map coordinates using your 94 × 50 style court.

Then your homography becomes:

src = predicted_image_points
dst = tactical_model_points
H, _ = cv2.findHomography(src, dst, cv2.RANSAC)

That is what makes player projection work.

The real refinement you need

Your current logic probably assumes:

all points are present

all points are in the correct order

no side confusion happens

That is risky.

You need 4 layers of logic:

1. Semantic index map

Every index must have a fixed court meaning.

2. Side validation

The system should check if left-side points are actually left of right-side points.

Example:

x(0) < x(8) < x(10)

x(5) < x(9) < x(15)

left paint should be left of midline

right paint should be right of midline

3. Structural validation

Check the court shape is geometrically plausible.

Examples:

0 and 10 should be roughly same y-level

5 and 15 should be roughly same y-level

8 should be above 9

2 and 6 should be roughly same y-level

3 and 7 should be roughly same y-level

12 and 16 should be roughly same y-level

13 and 17 should be roughly same y-level

4. Missing-point recovery

If one or two points are low-confidence or absent, use the rest and continue.

Best mental grouping for the 18 points

This helps your code a lot.

Outer boundary
OUTER_CORNERS = [0, 5, 10, 15]
Midline
MIDLINE = [8, 9]
Left baseline vertical markers
LEFT_BASELINE_CHAIN = [0, 1, 2, 3, 4, 5]
Right baseline vertical markers
RIGHT_BASELINE_CHAIN = [10, 11, 12, 13, 14, 15]
Left paint box
LEFT_PAINT = [2, 6, 7, 3]
Right paint box
RIGHT_PAINT = [12, 16, 17, 13]

This lets you reason about the court as shapes, not isolated dots.

Adjacency logic you should encode

This is useful for drawing, validation, and debugging.

COURT_EDGES = [
    (0, 8), (8, 10),          # top boundary
    (5, 9), (9, 15),          # bottom boundary
    (0, 1), (1, 2), (2, 3), (3, 4), (4, 5),   # left side chain
    (10, 11), (11, 12), (12, 13), (13, 14), (14, 15),  # right side chain
    (8, 9),                   # center line
    (2, 6), (6, 7), (7, 3),   # left paint
    (12, 16), (16, 17), (17, 13),  # right paint
]

This makes your rendered court match the actual geometry in your Roboflow template.

What the model should “know”

The model itself does not truly know basketball meaning unless your logic gives it that meaning.

So after inference, do this:

Step 1: collect points with confidence
keypoints = [
    {"id": 0, "x": x0, "y": y0, "conf": c0},
    ...
]
Step 2: attach semantics
for kp in keypoints:
    kp["name"] = COURT_KEYPOINTS[kp["id"]]
    kp["side"] = (
        "left" if kp["id"] in [0,1,2,3,4,5,6,7]
        else "right" if kp["id"] in [10,11,12,13,14,15,16,17]
        else "center"
    )
Step 3: validate court orientation

For example:

left average x must be less than centre average x

centre average x must be less than right average x

Step 4: build homography only from valid points
Strong recommendation: use named coordinates instead of raw index logic everywhere

Instead of this:

p0 = pts[0]
p1 = pts[1]
p2 = pts[2]

Do this:

named = {COURT_KEYPOINTS[i]: pts[i] for i in range(len(pts))}

left_outer_top = named["left_outer_top"]
midline_top = named["midline_top"]
right_outer_top = named["right_outer_top"]

That makes the whole pipeline easier to debug.

Suggested tactical coordinates for your exact new model

Here is a cleaner court-map layout you can start with:

TACTICAL_POINTS = {
    0:  (0, 0),
    1:  (0, 8),
    2:  (0, 18),
    3:  (0, 32),
    4:  (0, 42),
    5:  (0, 50),

    6:  (18, 18),
    7:  (18, 32),

    8:  (47, 0),
    9:  (47, 50),

    10: (94, 0),
    11: (94, 8),
    12: (94, 18),
    13: (94, 32),
    14: (94, 42),
    15: (94, 50),

    16: (76, 18),
    17: (76, 32),
}

You can tune these to match your SVG court exactly.

Validation function you should add

Something like this:

def validate_court_keypoints(points):
    """
    points: dict[int, tuple[float, float]]
    """
    errors = []

    required = [0,5,8,9,10,15]
    for idx in required:
        if idx not in points:
            errors.append(f"Missing critical point {idx}")

    if all(k in points for k in [0, 8, 10]):
        if not (points[0][0] < points[8][0] < points[10][0]):
            errors.append("Top row x-order invalid")

    if all(k in points for k in [5, 9, 15]):
        if not (points[5][0] < points[9][0] < points[15][0]):
            errors.append("Bottom row x-order invalid")

    if all(k in points for k in [8, 9]):
        if not (points[8][1] < points[9][1]):
            errors.append("Midline top/bottom order invalid")

    if all(k in points for k in [2, 6]):
        if not (points[2][0] < points[6][0]):
            errors.append("Left paint width invalid")

    if all(k in points for k in [16, 12]):
        if not (points[16][0] < points[12][0]):
            errors.append("Right paint width invalid")

    return errors

This alone will save you from many bad projections.

Best upgrade for your backend prompt / Antigravity

Tell it this:

The court keypoint model has 18 semantically fixed points. The backend must not treat them as anonymous ordered points only. It must maintain a canonical index-to-court-location mapping, validate court orientation and geometry after inference, and compute homography using only structurally valid keypoints. Missing or low-confidence points should be handled with graceful degradation, and all downstream tactical projection must rely on named semantic court points rather than raw positional assumptions.

In simple terms

Your new logic should understand:

0–5 = left boundary column

10–15 = right boundary column

8 and 9 = centre line

2,3,6,7 = left paint rectangle

12,13,16,17 = right paint rectangle

So yes — your model can still work, but your code now needs a court-geometry interpretation layer, not just raw keypoint indexing.

I can write you the exact Python module for this next: a court_keypoints.py file with mappings, validation, homography preparation, and named-point conversion.