Building a Core ML Poker Dataset Workflow on macOS
A durable Core ML dataset workflow separates capture, labeling, validation, conversion, and model evaluation. The process should make data quality visible before any model score is trusted.
Who this guide is for
ML builders, indie macOS developers, research teams, and technical poker students who need repeatable dataset operations.
Start with consistent capture
Core ML experiments are only as useful as the examples used to train and validate them. For poker table analysis, that means consistent captures, stable class names, clear bounding boxes, and representative examples across table themes, screen sizes, animations, and partial visibility states.
A screen-based tool can help by collecting repeatable samples from the same layout and preserving metadata about source window, resolution, capture time, and model configuration. That metadata becomes important when a detector fails and the user needs to explain why.
Separate labels from assumptions
Good dataset work keeps labels explicit. Card areas, board positions, player zones, text regions, and table containers should be correctable before they become training data.
Automated pre-labeling can speed up the process, but it should not be treated as ground truth. The workflow still needs human review, especially for small objects, overlapping elements, animation frames, and table themes that differ from the training set.
Design the dataset around failure modes
Poker screenshots create predictable failure modes: duplicate near-identical frames, partially visible cards, dimmed inactive seats, anti-aliased text, theme-specific icons, and regions that move when the table changes size.
Instead of collecting random examples, build a coverage plan. Include ordinary cases, rare visual states, and known weak spots. Tag those categories so validation can reveal which conditions are improving and which are only hidden by aggregate scores.
Convert only after cleanup
Conversion to Create ML or object detection formats should happen after deduplication, label cleanup, and train-validation splitting. Converting too early makes errors harder to locate because the original context can get separated from the exported file.
LumiGap includes converter and visualizer workflows so dataset builders can move from capture to review to export without stitching together unrelated tools for every experiment.
Evaluate models against real review needs
The best model metric is not always the most impressive number. For a study workflow, missed board cards, unstable player-area detection, and low-confidence text regions may matter more than a single aggregate score.
Keep evaluation tied to the review task. If users need to inspect decision points, the dataset should measure whether the model captures the table state at those moments accurately enough to support later analysis.
Practical checklist
- Define class names and bounding-box rules before collecting a large dataset.
- Keep source captures linked to annotations and exported records.
- Remove near-duplicate leakage between training and validation splits.
- Tag edge cases such as partial cards, animation states, and unusual table themes.
- Compare model versions on practical review failures, not only aggregate scores.
Common mistakes to avoid
- Collecting more images before defining what each label actually means.
- Mixing near-identical frames across train and validation sets.
- Exporting to model format before cleaning labels and preserving audit context.
Key takeaways
- Capture consistency is the first requirement for Core ML dataset quality.
- Labels need review before conversion.
- Validation should measure real table conditions and known failure modes.
FAQ
What should be captured with each dataset example?
At minimum, keep the image, annotation, source context, class rules, and split assignment. Model version and capture settings are also useful for later audits.
Is dataset size more important than label quality?
No. A smaller dataset with consistent labels and honest validation is usually more useful than a larger dataset with unclear or contradictory annotations.