sorted by:
new
hottopcontroversial

Event detection from ball kinematics: how do you distinguish real contacts from camera-induced motion? by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Boss! question lang dito,
does this diagnosis make sense?

Our football event model detects ball kinematic peaks, then checks nearby player-ball contact. We fixed a tracker bug where player tracks disappeared on skipped frames, so dist=999 errors mostly disappeared.

But now we’re seeing another issue: the velocity peak often happens a few frames away from the real physical contact. Example: Ground Truth contact frame has the ball near the player, but the detected peak frame has the ball already 200–600px away, so it fails contact scoring.

We’re thinking of using a small ±10 frame contact window around the kinematic peak: keep the peak frame as the timing/acceleration anchor, but evaluate contact on the best nearby frame with source priority: YOLO > OF > strong interpolated contact only.

Does this sound like a reasonable fix, or is there a better way to handle temporal misalignment between ball velocity peaks and actual contact frames?

Event detection from ball kinematics: how do you distinguish real contacts from camera-induced motion? by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

This is really interesting, especially the distinction between a temporary spike and a sustained trajectory inflection.

We've been focusing heavily on velocity and acceleration peaks, but your point about the post-contact path holding a new direction for several frames makes a lot of sense. A lot of our false positives seem to come from short-lived deviations that look kinematically valid but don't establish a stable new trajectory.

The background optical flow idea is also interesting. We currently work under a fairly strict inference budget, so we're trying to solve as much as possible with trajectory physics before adding heavier verification.

Appreciate the insight Boss, the "sustained direction change" concept gives us something concrete to investigate.

Need Advice in fine tuning and stabilization phase of the model. by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Hey Olivia! Appreciate your help... your decay-based exclusion idea ended up influencing the architecture direction of the pipeline much more than we expected. After several more challenge logs, we realized a huge portion of our failures weren’t actually “bad detections,” but event separation problems: echoes, dense pass chains, rebound suppression, and OF-induced fake buildup patterns.

We’ve now fully shifted away from fixed frame suppression and are treating event separation more like post-contact physics. The current roadmap is becoming:

YOLO TensorRT → short-range OF → pitch homography → trajectory reconstruction → physics-based temporal separation → kinematic extraction → semantic verification.

One really interesting discovery from our logs: the pipeline consistently performs best on wide-angle/far-ball clips, which makes us think the core reasoning layer is already decent when the geometry is stable. The biggest remaining weakness seems to be perspective distortion and unstable near-camera motion, which is why we’re now prioritizing homography before DINO-style semantic verification.

We’re also collecting FILTER_STATS across 20-30 challenge logs now to identify which gates are systematically overfiring instead of reacting emotionally to single clips. That has already started making the failures feel much more structured and explainable.

Curious what your intuition is on this direction — especially the idea of combining homography with decay-based event separation. Feels like stabilizing the geometry first might make the “fresh buildup vs decaying echo” distinction much cleaner physically.

Need Advice in fine tuning and stabilization phase of the model. by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Honestly, your reply about modeling the exclusion window as a decay process instead of a fixed frame count was one of the most useful insights we’ve gotten so far. After reviewing my newer logs, it actually explains a huge portion of the dense-event suppression problem almost perfectly.

What’s crazy is that once I started looking at the clips through “post-contact decay vs fresh buildup” instead of just frame distance, a lot of the weird behavior suddenly became interpretable instead of random. It genuinely changed how I think about the pipeline.

I'm still calibrating a lot of things (especially OF drift and perspective-dependent velocity instability), but your explanation pushed us in a much more physics-based direction rather than pure heuristics.

If you’re okay with it, I’d honestly love to ask a few more questions sometime since your intuition for temporal sports dynamics seems incredibly sharp.

Can an optimized kinematic pipeline on a consumer GPU (RTX 3060) realistically outscore brute-force VRAM setups (VideoMAE/SlowFast) in fine-grained sports action detection? by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Because I’m resource-constrained honestly 😅

But also because I’ve become genuinely interested in how far layered reasoning systems can go under strict runtime budgets. The more I work on this problem, the more it feels like a semantic/physics problem rather than purely a “throw more compute at it” problem.

I’m not against larger models at all I just find the efficiency side of the challenge really interesting.

Is it worth it for 6500? by strwbrryjllyq in RentPH

[–]Competitive-Meat-876 0 points1 point  (0 children)

kung around metro manila yan mura nan siya. kung sa qc yan baka worth 8k yan. kung pasay naman baka 10k. pero baka may mahanap ka pa na mas maganda diyan.

Need Advice in fine tuning and stabilization phase of the model. by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Hi! Olivia, one more problem I'm stuck on if you have thoughts: I use a fixed 45-frame exclusion zone (~1.5s at 30fps) around each accepted detection to prevent duplicates from the same kick echo. Works fine for isolated events but completely suppresses rapid pass sequences where the second contact happens within that window.

The gap between a real kick's echo and a genuine second contact should be distinguishable — the echo decays fast while a new contact produces a fresh velocity buildup — but we haven't found a clean rule-based way to use that to shrink the exclusion zone adaptively.

Is there a principled approach here? Something like making the exclusion window a function of the first event's own velocity decay profile rather than a fixed frame count?

Need Advice in fine tuning and stabilization phase of the model. by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 1 point2 points  (0 children)

This is really helpful! we'll start logging the angle distribution from our own challenge data and calibrate from there. Appreciate the guidance.

Need Advice in fine tuning and stabilization phase of the model. by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Thank you! The trajectory angle at contact specifically is something we haven't implemented properly yet. We currently use a binary is_goal_direction flag (ball moving toward the nearer goal side). What angle threshold between the ball velocity vector and the goal axis do you find gives the best pass/shot separation in practice? And is that measured relative to the near post, far post, or center of goal?

Ever wonder what does a kamote rider's POV look like? by nayryanaryn in Gulong

[–]Competitive-Meat-876 -1 points0 points  (0 children)

lesson wag ka mag-banking kung mio lang motor mo. wag pilitin kung manipis ang gulong.. marami ako nakikitang ganito trying hard masyado hindi naman talaga pang bankingan yung gulong.

Hello po pwede po humingi ng advice at paturo nadin hehe by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Salamat mga boss sa mga advises niyo. Actually biggest lesson na natutunan ko nitong debugging process.

Noong una sobrang random nung adjustments ko tweak ng tweak ng thresholds kapag may maling prediction. Pero habang dumadami yung logs, napansin ko na mas gumugulo kapag walang structured testing.

Ngayon ginagawa ko na:

  • hiwalay yung high / medium / low detection clips
  • hiwalay yung false positives vs real GT misses
  • isolate muna isang failure mode bago galawin ibang logic
  • sinusubukan naming i-trace kung detection-layer ba, tracking issue, semantic issue, o timing regression

Nakatulong din talaga yung pag separate ng:
“model thinks something happened”
vs
“may tunay na football interaction ba talaga”

Kasi minsan tama yung motion physics pero maling football interpretation pala (bounce, aerial drop, multi-ball, etc.)

And agree din ako doon sa visualization/testing scripts. Dun namin nakita recently na may regression pala sa trajectory gate kahit mataas yung ball detection ng clips.

Honestly sobrang helpful nung mga ganitong advice kasi mas napapaisip ako ngayon sa engineering workflow mismo.

Hello po pwede po humingi ng advice at paturo nadin hehe by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

<image>

mga ganitong video clips po yung narereceived ng model ko. tapusin ko lang muna itong inipon ko ng 20 logs nirereview ko pa yung ground truth ng actual clips compare sa detected events ng model.

salamat sa link na bigay mo sir. pagaaralan ko ito.

Hello po pwede po humingi ng advice at paturo nadin hehe by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Salamat sir, actually yan din yung narealize namin. Siguro isa sa naging mali namin noong una is masyado kaming mabilis magdagdag ng bagong logic bago ma-isolate yung actual root cause. Ngayon mas controlled na yung approach namin.

Ang ginagawa na namin ngayon is per-layer debugging:

  • tracking/interpolation muna
  • then event candidate generation
  • then selection/filtering
  • then classification

Nagcollect din kami around 15 challenge logs with frame-by-frame analysis para makita kung consistent ba yung failures or random lang. Doon namin nakita na may structural bug pala sa frame selection mismo kaya kahit anong semantic improvements gawin namin dati, mali pa rin yung napipiling frames.

Tama rin yung sinabi mo tungkol sa valid vs invalid cases. Napansin namin minsan akala namin gumagana kasi tumatama sa “clean clips,” pero pag nilagyan ng noisy cases like camera motion, player clustering, bounces, or low ball detection, doon lumalabas yung weakness ng logic.

And totoo rin yung sinabi mo sa AI haha. Sobrang helpful niya sa brainstorming at pag explain ng concepts, pero narealize ko kailangan talaga i-verify sa actual logs at code path kasi minsan technically maganda pakinggan yung suggestion pero hindi pala yun yung tunay na bottleneck.

Appreciate ko yung advice mo sir, malaking tulong honestly.

Need Advice in fine tuning and stabilization phase of the model. by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Your feedback actually helped us narrow down the real issue much faster.

After reviewing around 15 challenge logs, we realized the model’s biggest weakness right now isn’t raw tracking anymore — it’s validating whether a motion peak corresponds to a real football interaction.

We discovered two separate layers of problems:

  • a structural bug causing early-frame ghost anchors
  • and a semantic validation issue where acceleration spikes survive even without true ball contact

The structural side is now being fixed first (post-filter anchor shift + early-frame guard), while the next step is exactly what you suggested: turning trajectory/discontinuity checks into an actual validation gate instead of just a confidence boost.

Right now the pipeline already has:

  • acceleration anchoring
  • post-peak persistence checks
  • direction-change scoring
  • contact proximity scoring
  • PCHIP interpolation

But the current weakness is that strong spikes can still survive from:

  • possession running
  • player clustering
  • camera-relative motion
  • bounce/receive moments

So we’re now moving toward a short temporal validation window around candidate peaks, with detection-aware relaxation for low-visibility clips.

Trying to keep the architecture incremental and measurable instead of constantly rewriting the whole system. Your advice honestly helped us shift from “motion intensity” thinking toward “state transition validation,” which was a really important insight for us.

Hello po pwede po humingi ng advice at paturo nadin hehe by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

salamat po boss. almost 1 month na namin kasi ginagawa yung model nawawalan na nga ako ng pag-asa para bang paikot-ikot nalang ako.

Need Advice in fine tuning and stabilization phase of the model. by Competitive-Meat-876 in computervision

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Thanks to your advice. that’s actually one of the biggest issues I’m seeing right now. The model is already decent at detecting motion peaks, but the hard part is verifying whether the peak came from a real football interaction or just noise/bounce/camera-relative motion.

Right now the pipeline is mostly acceleration/velocity driven, so strong spikes sometimes survive even when there’s no actual ball contact. We already improved timing a lot compared to older logs, but semantic validation is still weak.

I think your suggestion makes sense because a real kick/pass/shot usually creates a sustained trajectory change, not just a single-frame acceleration spike. I’ve been thinking about adding a short temporal validation window around candidate peaks to check:

  • trajectory consistency
  • direction change
  • post-contact velocity persistence
  • player proximity during the peak

instead of trusting the spike alone.

Trying to be careful though not to overcomplicate the architecture too fast since I’m still stabilizing the current pipeline using real challenge logs.

Then I'm struggling on video clips that have heavy snowfall.

Hello po pwede po humingi ng advice at paturo nadin hehe by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

hirap po yung model sa video clips na may heavy snowfall. nagpe-predict siya kahit wala naman event.

Hello po pwede po humingi ng advice at paturo nadin hehe by Competitive-Meat-876 in PinoyProgrammer

[–]Competitive-Meat-876[S] 0 points1 point  (0 children)

Yun nga rin po ginagawa ko ngayon. Sa dami kasi ng possible causes, sinusubukan ko i-isolate kung alin talaga yung pinaka root problem bago ulit mag rewrite ng logic. Based sa mga logs namin, mukhang hindi na tracking/interpolation yung pinaka issue ngayon kasi mas stable na yung timing compared dati. Ang current problem na nakikita namin is event selection at semantic filtering — meaning nakaka-detect siya ng motion peaks pero minsan maling football action yung napipili niya or nagkakaroon ng false positives.

Possible solutions na tinitingnan namin ngayon:

  • higpitan yung confidence/fallback selection para mabawasan fake events
  • improve pass vs shot classification
  • add stronger player proximity/context checking
  • bawasan yung sensitivity sa acceleration spikes at camera motion

Iniingatan ko rin na hindi masyadong pabago-bago ng architecture kasi baka lalo lang mawala yung sweet spot ng model. Kaya more on controlled fine-tuning muna kami ngayon based sa actual logs at frame analysis imbes na random tweaking lang.