The problem you will solve
A fictional catalogue accepts product photos, but very dark, blurred or empty images create downstream errors. Build an intake gate that explains why an image needs retaking. Avoid face recognition, identity inference and medical or safety-critical judgments.
Before you start
Image dimensions, pixel arrays and classification metrics.
Suggested tech stack
Data plan
Photograph your own non-personal objects, with permission, in several sessions. Label usable versus retake, then add controlled blur and darkening. Keep all variants of the same original in one split to avoid leakage.
Hardware and cost
Resolution and brightness rules run on CPU. An optional small image classifier can be explored with MediaPipe examples, subject to its supported platform and model format. No large training run is required.
Define the input and output
Use this illustrative contract as a starting point, then specify required fields, validation and error responses in your own implementation. It is not a complete API schema.
Input: image bytes with size and format limits
Output: {"decision":"retake","reasons":["too_dark"],"width":640,"height":480,"pipeline_version":"v1"}Your five build milestones
Finish and test one milestone before extending the system. Keep an experiment log with the decision, the alternative you rejected and the evidence behind the choice.
Define acceptable images
Write a labeling rubric with examples of blur, darkness and absent product content. Record ambiguous cases instead of forcing a label that another reviewer could not reproduce.
Build deterministic checks
Validate file type and decoded dimensions before processing. Add brightness and simple blur scores, with thresholds tuned on development images only.
Split by capture session
Keep near-duplicates and transformed images together. Reserve a later capture session with different backgrounds to test whether thresholds generalize beyond the development setup.
Compare a classifier
Optionally adapt a small classifier after the rule baseline works. Compare on the same held-out images and show whether the extra model improves retake decisions.
Make a failure gallery
Display permitted examples with predicted decision, reason and reference label. Include false rejections and missed bad images; document upload limits and avoid publishing private photos.
How to evaluate your project
Set your acceptance criteria before looking at the final test results. The checks below are proposed experiments, not measured outcomes or a guarantee that a particular model will pass.
- Report retake precision and recall, plus usable-image false rejection rate.
- Break results down by lighting and background; show sample counts with each rate.
- Test corrupt files, extreme dimensions and repeated originals so preprocessing failures are not confused with model errors.
Save your test cases, run command, dependency versions and results together. Compare on identical inputs, retain failures in the denominator and report sample sizes. If a change improves one metric but harms another, explain which trade-off fits your use case.
Failure modes worth demonstrating
- Putting augmented copies of a test image in training.
- Treating brightness as a complete measure of quality or collecting people's photos without consent.
Optional extension
Let a reviewer override a decision with a reason and analyse disagreements before changing thresholds.
Turn the build into portfolio evidence
Your repository should let another person understand the problem and reproduce the core evaluation without needing your private credentials.
- A README with problem, intended user, architecture, setup commands and a small input/output example.
- A permitted sample dataset, its origin or generator, a frozen test split and a single evaluation command.
- A results table comparing your baseline with your final approach, including failures and sample counts.
- A short demo or screenshots, a limitations section and one decision you would change with more time.
- Environment-variable names without secret values, a dependency list and attribution/license notices for any reused code or datasets.
Resume framing
Describe this as a personal or educational project. State what you implemented, how you tested it and what your measured results were. Replace placeholders with your own evidence; do not claim employer impact, production traffic or accuracy you did not measure.
Built image intake quality gate using Python, NumPy, Pillow; evaluated against [baseline] on [N held-out cases], documented [measured result] and [important limitation].Be ready to explain your decisions
- Which error matters more: rejecting a good photo or accepting a bad one?
- How did you prevent near-duplicate leakage?
Answer with a concrete failure from your implementation, the options you considered, your measured evidence and the limitation that remains.
Google documentation and GitHub references
The project scope, milestones and evaluation plans above are original AIJobFever educational material. These official Google resources offer background or implementation examples; they are not finished implementations of this blueprint. No Google endorsement is implied. Review repository licenses, supported platforms and current costs before reusing code or provisioning services.
Our editorial policy