Fundus Photo Quality Gate for Diabetic Eye Screening Camps

The problem screening camps have with image quality

Diabetic retinopathy screening works by photographing the back of the eye and having a trained grader, or an approved AI system, read the image later. Outreach camps in rural areas and small towns use portable or handheld cameras operated by technicians who may have had little training. The weak link is often the photo, not the reading. If an image is blurred, too dark or off-centre, the grader cannot use it, and by the time anyone finds out the patient has gone home and may never come back.

Published studies show how much this varies: one screening study with portable cameras found 17.6 percent of images could not be graded by the specialist reader, and the same paper cites a rural India experience of 34 percent. A quality check at the moment of capture, while the patient is still in the chair, directly reduces lost screenings.

What already exists and the gap

• Eyenuk's EyeArt and Digital Diagnostics' LumineticsCore (formerly IDx-DR) are regulated autonomous diagnostic systems; they report ungradable images, but as part of a paid diagnostic workflow, usually after upload.
• Remidio makes smartphone-based fundus cameras with built-in AI, tied to its own hardware.
• Academic image quality models such as those trained on the EyeQ dataset (28,792 EyePACS images labelled Good, Usable or Reject) are published as research code, not as a tool an operator can use offline in a camp.

The gap is a hardware-independent, offline, explainable quality gate that tells the operator what to fix. It deliberately does not diagnose anything.

What you build

A quality model and a capture companion app. The model takes a fundus image and returns a quality grade plus one or more reasons. You can train reasons in two ways: label a few hundred images yourself with reason tags and add small classification heads, or compute simple image measures (brightness histogram, blur via Laplacian variance, optic disc position) and combine them with the learned grade. Comparing the two is a good experiment.

The app runs the model on the phone. The operator photographs, sees "Retake: image too dark, increase illumination" or "Good", and moves on. Images are stored with their grade for later upload.

The technically interesting part

Generalising across cameras. EyeQ comes from desktop cameras in the EyePACS programme. Handheld and smartphone cameras produce different colours, fields of view and artefacts. Your key experiment is domain shift: train on EyeQ, test on an external set from a different camera (several public fundus datasets exist, or partner with an eye hospital for a small anonymised set under their approval), measure the drop, then try mitigations such as colour augmentation, histogram normalisation or fine-tuning on a small labelled set. Report how many target-domain labels you need to recover most of the lost accuracy. That answer is exactly what a real deployment needs to know.

Also show your evaluator why the model decides what it does, using Grad-CAM overlays reviewed by at least one optometrist or ophthalmology resident.

How to evaluate it

• Accuracy and macro F1 on the EyeQ test split, and the confusion between Usable and Reject.
• Performance on the external camera set before and after adaptation.
• Reason tag precision on a labelled sample of at least 200 images.
• On-device latency and model size on a named mid-range phone.
• A simulated capture session with volunteers (using a teaching fundus model eye or recorded images) measuring retakes and time per patient with and without the gate.

Suggested plan

1. Month 1: literature review, EyeQ download, baseline training.
2. Month 2: reason labelling and reason heads versus hand-made measures.
3. Month 3: external set and domain adaptation experiments.
4. Month 4: model export and on-device testing.
5. Month 5: capture app and saliency review with a clinician.
6. Month 6: simulated session, write-up and ethics section.

Path to a product

The first customer is an NGO or hospital outreach programme that runs screening camps with mixed camera hardware. Offer it free for pilots and charge an annual licence per device for programmes, or sell it to camera makers as an SDK. Because the tool is non-diagnostic and does not give clinical findings, it sits in a lighter regulatory position than diagnostic AI, but check local rules with your partner before any real deployment and never present it as a diagnosis.

Scope warning

Do not detect or grade retinopathy, and do not show any disease output to operators or patients. Do not use real patient images without formal approval from the partner institution. Do not build camera hardware. The project is a quality gate, measured well.

Learn what you need on Sefism

• Machine Learning roadmap : transfer learning, augmentation and evaluation under distribution shift.
• Mobile roadmap : building the capture app and running a model on device.
• Machine Learning cheat sheet : metrics and confusion matrices for a three-class problem.
• Google Colab : free GPUs for training the quality model.
• Google Research Blog : background reading on medical imaging research and its evaluation.

Get help with this idea

Health projects need extra care on ethics, data approval and wording. A mentor can help you set a safe, non-diagnostic scope and plan the external test set. Bring your draft scope, the dataset you plan to use and your evaluation table, and we can look at them together. The build is yours; the guidance is on scope, stack and how to measure it. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session