MIRA — Day 8: The Invisible Boxes (and Why Two Models Were Lying to Me)

BUGS

After hours of digging through Ultralytics internals with AI assistance, I found not one but three separate bugs all stacking on top of each other.

Bug #1: Tracker

Ultralytics 8.4.84 silently switched the default tracker from ByteTrack to something called TRACKTRACK. I never asked for this. Nobody told me.

TRACKTRACK has internal confidence thresholds that are absurdly high:
track_high_thresh: 0.6 # Only detections >= 0.6 are “real” new_track_thresh: 0.7 # New objects need >= 0.7 to be tracked
Here’s the problem: INT8 quantization drops confidence scores by 20-40%. So a detection that would score 0.55 in the original PyTorch model now scores ~0.35 after quantization. TRACKTRACK looks at 0.35, says “too low,” and silently throws it away. No error. No warning. Just… gone.

Bug #2: The Double Filter

Even if TRACKTRACK somehow kept a box, my drawing function had its own confidence filter set to 0.5. So a box at conf=0.4 that survived the tracker got killed again at the drawing stage.

Bug #3: Nothing Stopped the User from Loading the Wrong Model

Nothing in the code prevented me from loading mira_classifier_int8.tflite — a classification model — into the detection pipeline. Which i failed to realise. The code just checked if the file ended in .tflite and said “sure, load it as a detector.” It would’ve failed silently or produced garbage.

live_detection.py — The Big One

I rewrote the core inference loop. Three major changes:

Forced ByteTrack everywhere. PyTorch models now explicitly use tracker="bytetrack.yaml" instead of whatever Ultralytics defaults to. No more silent tracker swaps.

Bypassed the tracker entirely for INT8 models. TFLite INT8 now uses model.predict() instead of model.track(). No tracker = no threshold filtering = boxes actually appear. Conf is auto-overridden to 0.25 at startup because INT8 models need lower thresholds.

Added model validation. If you try to load a classifier model into the detection pipeline, you now get a clear error:
ERROR: ‘mira_classifier_int8.tflite’ is a CLASSIFIER model, not a detector. Live detection requires a detection model (.pt or detection .tflite). Use ’mira eval-class –model mira_classifier_int8.tflite –exp ’ instead.
No more silent failures.

dashboard.py — Same Story, Streamlit Edition

The Streamlit dashboard had the exact same tracker and threshold bugs. Fixed identically: ByteTrack forced, INT8 models use predict(), classifier models filtered from the sidebar before you can even select them.

cli.py — First Line of Defence

Updated cli.py and added mutiple new commands to make it easier to use also made it possible to use in the termnail through a bat file so u can run the scripts in powershell if you want if you just add .\mira and then commands. Also Added validation in the live subcommand so classifier models get rejected before the subprocess even spawns. Faster error, cleaner output.

Folder Cleanup Reality

Checked the project size today: 17.3 GB. That’s absurd for a recycling classifier. Most of it is:

• Failed experiment outputs
• Raw dataset images that should’ve been gitignored
• Multiple copies of the same model in different formats
• Private test data that never should’ve been committed

Need to do a serious cleanup before pushing anything.

What’s Next

Downloading three new datasets to retrain on:

• SortWaste (WACV 2026) — real conveyor belt images, 87k bounding boxes
• TACO — waste in wild environments (forests, streets, beaches)
• NAVER Recycle Trash — 21k images, indoor + outdoor

Target: Combine everything into ~20,000 images, retrain with YOLO11n, hit 80%+ mAP50 with actual real-world robustness.