Muhammad Ariel Shakaramiro

That's a genuinely cheap way to get a real signal instead of an assumption, thanks. Sampling the hard cases specifically (dusk, rain, the tightest cluster) rather than a random 20 frames makes sense too — that's exactly where a mask is most likely to fall apart first. I don't have a concrete timeline for it right now, but it's a solid, low-effort follow-up candidate if I revisit this project.

Thanks for this, Ahmet.. both points are sharp. On the occlusion/IoU point: completely agree, and it's actually visible in my own validation numbers even before touching the CCTV footage. Mask mAP50-95 came out at 0.604 versus 0.668 for box mAP50-95 the gap is exactly the kind of signal you'd expect if mask quality (which has to get the boundary right, not just the general region) degrades faster than plain detection does. On expanding the Yogyakarta section: fair critique, and I'll be honest about the gap what I tracked live was frame-level car counts, not a systematic check of mask edge quality against ground truth on the CCTV footage itself (I don't have labeled masks for that feed to compare against, only the counts). So I can say recall stayed reasonable, but I can't actually back up a claim about mask quality holding up out there the same way I can for the validation set. That's a real blind spot in what I measured, not something I checked and found fine. Appreciate you pointing at exactly where the write-up glosses over it.

Ahmet, I added a confusion matrix to the notebook based on your comment — and the data confirms exactly what you predicted. Trouser, Bag, Sandal, and Ankle boot all hit 95%+ recall (unique enough silhouettes). Shirt is the worst performer at 67.7% recall, getting confused with T-shirt/top (98 images) and Coat (103 images) most often. Pullover and Coat also swap with each other constantly — 169 Pullovers misclassified as Coat alone. The aggregate 87% accuracy completely hid this. Really appreciate you pointing me toward looking at it this way — it's a habit I'll carry into future projects. The updated notebook (confusion matrix in the last section) is linked from the GitHub repo mentioned in the post above.

Hey Ahmet, appreciate you coming back with more. on the sample size thing, you're completely right and I should've flagged it. did the math: at n=30, one sample is 3.33 points of accuracy, so standard error is around 3.3 points, meaning a rough 95% CI is something like ±6.4 points on any single accuracy number here. that's a genuinely useful thing to sit with, small differences between models on iris are basically noise, and it's another reason the cross-validation fix from your last comment matters even more than I framed it. on the train/test gap, mostly agree but checked the actual numbers and there's a nuance worth mentioning. the tree in the post is capped at max_depth=3, and that one gets 98.33% train vs 96.67% test, a 1.67 point gap, not dramatic. the "100% on train" thing you're describing shows up if you let the tree grow unrestricted (max_depth=None), which in my case hits exactly 100% train vs 93.33% test, a 6.67 point gap. so the principle is dead on, just wanted to be precise about which version of the tree actually does that. added a note on the test set size to the post, since that one directly changes how much trust to put in the numbers already there. leaving the train/test gap as something to carry forward rather than folding it into the post itself, it's a good diagnostic but this one's meant to stay intro-level and I don't want to stack on more than it needs. appreciate you pushing on both points though.

Hey Ahmet, thanks for this, genuinely. you're right about the validation split thing, and it actually calls out something I got wrong in part 2. the mini practice section literally has people sweep test_size and max_depth and pick whatever scores best on the test set. that's the leak you're talking about basically. once you pick anything based on the test number, that number isn't clean anymore. should've had readers tune on a validation split instead and only touch test once at the end. gonna fix that. on the clustering side, small pushback: ARI actually does use ground truth to compute, so it's not quite the same trap as something like silhouette score which is purely internal. but yeah your point still holds in general, iris is kind of a special case because we happen to have labels to check against. most real clustering you don't get that, so you're stuck with internal metrics and "tight clusters" can absolutely not mean anything useful. appreciate you actually writing this out instead of just dropping a generic comment. going back to rework that section.