EyeAI: AI Ocular Diagnosis & Assistance

• EyeAI is an AI-enabled system integrating CNN-based retinal screening and multimodal assistive tech for visually impaired users, enhancing early disease detection and accessibility.
• The system employs a custom CNN architecture to analyze 150×150 RGB retinal images, delivering a binary classification with high recall yet low specificity.
• Deployment strategies include a Flask-powered web app for diagnostics and distributed pipelines for assistive eyewear, addressing low-cost, real-time inference in underserved settings.

EyeAI denotes a class of AI-enabled systems for visual assistance and ocular health, instantiated in the supplied literature by two distinct implementations: a web-based retinal fundus screening system for ocular disease detection and assistive platforms for visually impaired users that combine computer vision, speech, and multimodal interaction (Garg et al., 27 Jul 2025). In the ocular screening formulation, EyeAI is presented as “AI-Assisted Ocular Disease Detection for Equitable Healthcare Access,” a publicly accessible Flask-powered application that accepts a retinal fundus photograph and returns a binary classification of “Diseased” or “Healthy” using a custom convolutional neural network trained on the Retinal Fundus Multi-Disease Image Dataset (RFMID) (Garg et al., 27 Jul 2025). In the assistive-technology formulations embodied by AIris and AIDEN, EyeAI is used more broadly to describe AI-enabled perception systems that translate camera input into spoken or haptic guidance for blind or low-vision users through distributed, cloud-assisted pipelines (Brilli et al., 2024, Marquez-Carpintero et al., 8 Nov 2025). Taken together, these usages place EyeAI at the intersection of medical image analysis, accessible human–computer interaction, and deployment-oriented AI.

1. Clinical and assistive motivation

The ocular disease detection version of EyeAI is explicitly situated against a global ophthalmic access problem. The paper states that an estimated 2.2 billion individuals live with visual impairment and that more than 1 billion cases were preventable with earlier diagnosis and treatment (Garg et al., 27 Jul 2025). It further identifies several converging drivers of rising burden: diabetes is projected to affect 643 million people by 2030; diabetic retinopathy will rise by an estimated 48% by 2030; more than 75% of diabetic adults live in low- to middle-income countries; and the share of people over 60 will nearly double between 2015 and 2050, with 80% of older adults in low- and middle-income communities by 2050 (Garg et al., 27 Jul 2025).

Workforce and cost constraints are central to the system rationale. The mean global ophthalmologist density is reported as 31.7 per million people, with 3.7 per million in low-income countries versus 76.2 per million in high-income countries (Garg et al., 27 Jul 2025). Ophthalmology appointments can cost up to 200 USD, physician salaries average approximately 320,000 USD per year, and retinal fundus imaging machines can cost roughly 5,000 USD while requiring minimal training (Garg et al., 27 Jul 2025). Within that framing, EyeAI is intended to facilitate low-cost, remote, and real-time diagnosis, especially in underserved and rural areas.

A separate but related motivation appears in the assistive-vision literature associated with EyeAI. AIris is described as an AI-enabled eyewear concept for people who are blind or have low vision, designed to provide environmental awareness through “human-like” conversational exchanges and to remain cost-effective, upgradeable, and comfortable enough for daily use (Brilli et al., 2024). AIDEN similarly targets users with low vision to total blindness and integrates object identification and description, text reading, and environmental question answering in a smartphone application (Marquez-Carpintero et al., 8 Nov 2025). These systems address a different problem than retinal screening, but they share the EyeAI theme of expanding equitable access through low-cost, remote, and multimodal AI assistance.

2. System definition and operational workflow

In its retinal screening instantiation, EyeAI is a web-based application that takes a retinal fundus photograph as input and returns an AI-assisted diagnosis indicating whether the retina is diseased or healthy (Garg et al., 27 Jul 2025). The workflow is deliberately minimal. Patients obtain fundus images using standard retinal imaging machines, upload the image through a publicly accessible Flask-powered web application, and receive a binary classification generated by a pre-trained CNN (Garg et al., 27 Jul 2025). The application is available at https://eyeai-ci7emj7x5a-uc.a.run.app/, and the reported deployment objective is low-cost, remote, real-time inference (Garg et al., 27 Jul 2025).

The intended clinical role is explicitly assistive rather than substitutive. Results can be shared with clinicians and integrated into electronic medical records, and the system is framed as a secondary diagnostic opinion that augments ophthalmologist care (Garg et al., 27 Jul 2025). The paper also identifies intended deployment settings: underserved and rural areas, community clinics, wellness centers, and ophthalmology practices seeking productivity gains through triage and early detection (Garg et al., 27 Jul 2025).

In the assistive-technology usage of EyeAI, the operational workflow differs substantially. AIris uses a distributed pipeline in which a user issues a voice command, a Raspberry Pi converts speech to text and selects an appropriate module, the eyewear-mounted camera captures an image, a server performs ML inference, and the result is returned for local text-to-speech delivery through earphones (Brilli et al., 2024). AIDEN follows an analogous client–server architecture on smartphones: the mobile app performs sensing and user interaction, while LLaVA or YOLOv8 inference runs on a remote server, after which speech, haptics, and accessible visuals are presented on-device (Marquez-Carpintero et al., 8 Nov 2025). This suggests that “EyeAI” functions as an umbrella label across both diagnostic and assistive systems, with the common denominator being AI-mediated interpretation of visual input under accessibility constraints.

3. Model architecture and learning setup in ocular disease detection

The retinal screening EyeAI model is a custom CNN for binary classification of “any disease present” versus “healthy,” spanning 45 ocular diseases (Garg et al., 27 Jul 2025). Input images are resized to $150 \times 150$ pixels with 3 RGB channels, yielding tensors of shape $150 \times 150 \times 3$ (Garg et al., 27 Jul 2025). The network contains five convolutional blocks, each composed of a Conv2D layer with ReLU activation followed by $2 \times 2$ max pooling. The blocks use 16, 32, 64, 64, and 64 filters respectively, all with $3 \times 3$ kernels (Garg et al., 27 Jul 2025).

After the convolutional stack, feature maps are flattened and passed to a fully connected layer with 512 units and ReLU activation, followed by a single-unit sigmoid output layer that produces a probability of disease (Garg et al., 27 Jul 2025). Training uses binary cross-entropy with RMSprop at a learning rate of 0.001, with the objective

$$L = -[\, y \log(\hat{y}) + (1-y)\log(1-\hat{y}) \,].$$

Preprocessing uses TensorFlow/Keras ImageDataGenerator for augmentation, both to enrich variability and to partially mitigate class imbalance (Garg et al., 27 Jul 2025). The paper states that the exact augmentation operations, batch size, number of epochs, steps per epoch, validation steps, regularization, early stopping policy, and explicit thresholding strategy were not specified (Garg et al., 27 Jul 2025). The model is saved in HDF5 format and served via Python/Flask (Garg et al., 27 Jul 2025).

The authors emphasize that the architecture is not a named backbone such as ResNet or EfficientNet, but rather a straightforward CNN tailored to the dataset and deployment constraints (Garg et al., 27 Jul 2025). A plausible implication is that the design prioritizes implementation simplicity and lightweight deployment over architectural novelty.

4. Dataset, disease coverage, and label structure

EyeAI is trained and evaluated on the Retinal Fundus Multi-Disease Image Dataset, created in 2021 by medical professionals and researchers (Garg et al., 27 Jul 2025). The dataset contains 3,200 retinal fundus images across 46 categories: 1 healthy class and 45 disease classes (Garg et al., 27 Jul 2025). Diseases represented include diabetic retinopathy, media haze, optic disc cupping, tessellation, drusen, myopia, age-related macular degeneration, central serous retinopathy, vein and artery occlusions, and chorioretinitis (Garg et al., 27 Jul 2025).

The study uses a $60/20/20$ split: 1,920 images for training, 640 for validation, and 640 for testing (Garg et al., 27 Jul 2025). The validation set is explicitly described as imbalanced, with 90 healthy and 550 diseased images (Garg et al., 27 Jul 2025). The paper identifies this skew, together with broader dataset heterogeneity, as a key limitation for generalization (Garg et al., 27 Jul 2025). No additional bias mitigation strategies such as class weighting or resampling are described as part of the final training procedure (Garg et al., 27 Jul 2025).

Several clinically important metadata dimensions are not specified. The paper does not report labeling protocols such as grader counts or adjudication, device diversity, image quality control criteria, or patient demographics including age, sex, geography, and comorbidities (Garg et al., 27 Jul 2025). It also does not formally assess robustness to artifacts, domain shift across devices or populations, or cross-clinic variability (Garg et al., 27 Jul 2025). For a research audience, these omissions are consequential because they bear directly on transportability, external validity, and failure analysis.

The disease representation is also compressed into a single binary outcome. EyeAI collapses 45 disease categories into one “Diseased” label (Garg et al., 27 Jul 2025). The paper notes that this binary framing may obscure disease-specific decision support and increase false positives when subtle findings are present (Garg et al., 27 Jul 2025). This suggests a tension between broad disease coverage and clinically granular interpretability.

5. Evaluation metrics and empirical performance

The paper reports held-out performance using accuracy, AUROC, precision, recall, specificity, and F1-score (Garg et al., 27 Jul 2025). EyeAI achieved an accuracy of 80%, AUROC of 0.698, precision of 85.88%, recall of 91.82%, specificity of 7.78%, and F1-score of 0.8876 (Garg et al., 27 Jul 2025). Metric definitions are provided directly in the paper:

• $P = \frac{TP}{TP+FP}$
• $R = \frac{TP}{TP+FN} = TPR =$ sensitivity
• $F1 = \frac{2PR}{P+R}$
• $TPR = \frac{TP}{TP+FN}$
• $150 \times 150 \times 3$0

AUROC is described as summarizing discrimination across all thresholds and can be defined as

$150 \times 150 \times 3$1

or equivalently by the Wilcoxon–Mann–Whitney statistic (Garg et al., 27 Jul 2025).

The reported profile is asymmetric. The model detects disease aggressively, with high recall, but exhibits very low specificity, indicating many false alarms (Garg et al., 27 Jul 2025). The paper explicitly associates this pattern with the severe class imbalance and remarks that a predicted “Healthy” is a strong indicator of true health, whereas “Diseased” predictions may correspond to either healthy or diseased inputs (Garg et al., 27 Jul 2025). The practical implication, as stated, is increased unnecessary referrals and patient anxiety (Garg et al., 27 Jul 2025).

Several standard evaluation components are absent. Exact confusion-matrix counts were not provided, despite conceptual inclusion of a confusion matrix (Garg et al., 27 Jul 2025). No confidence intervals, calibration analysis, or formal comparisons to baselines or prior work on identical tasks are reported (Garg et al., 27 Jul 2025). Consequently, although the reported recall is high, the statistical stability and relative competitiveness of the model cannot be determined from the paper alone.

6. Deployment pathway, interpretability, and operational constraints

EyeAI’s deployment is centered on a Flask-based web application backed by a Python inference service that loads the HDF5 CNN model (Garg et al., 27 Jul 2025). The frontend uses HTML/CSS for image upload and result display, and the application is intended to run on commodity infrastructure without specialized client-side software (Garg et al., 27 Jul 2025). The deployment concept emphasizes accessibility, remote access, and real-time inference, especially in low-resource settings (Garg et al., 27 Jul 2025).

The paper also describes envisioned integration into clinical workflows. Outputs can be incorporated into electronic medical records to streamline documentation and referrals, and the system is positioned as a triage tool and secondary diagnostic opinion rather than a standalone replacement for ophthalmologist care (Garg et al., 27 Jul 2025). This placement is consistent with the reported operating point: high sensitivity may be acceptable in triage settings, whereas low specificity constrains autonomous screening utility.

Interpretability is notably underdeveloped. The paper does not report the use of Grad-CAM, saliency maps, occlusion sensitivity, feature attribution, or clinician-facing visual overlays (Garg et al., 27 Jul 2025). Visual explanations are not described and are implicitly identified as a future enhancement (Garg et al., 27 Jul 2025). For medical imaging systems, this omission limits inspection of whether predictions localize to plausible retinal structures or lesions.

Operational details are similarly incomplete. The paper does not specify inference latency, throughput, hardware requirements, scaling strategy, privacy and security measures, data retention policies, or offline and low-bandwidth modes (Garg et al., 27 Jul 2025). Regulatory considerations are addressed only at a high level: images are noted as FDA-approved for use, and HIPAA-related constraints in data collection are acknowledged, but no comprehensive regulatory roadmap or bias monitoring plan is detailed (Garg et al., 27 Jul 2025). This suggests that EyeAI is best understood as a deployment-oriented prototype rather than a fully operational clinical device.

7. Limitations, misconceptions, and prospective development

The principal limitations identified by the authors are dataset imbalance and heterogeneity, binary aggregation across 45 diseases, restricted data access due to HIPAA and related regulations, unspecified training details, and untested robustness across devices, populations, and imaging artifacts (Garg et al., 27 Jul 2025). These are not minor implementation caveats; they shape the observed metric profile and delimit the system’s present clinical utility. In particular, the heavy overrepresentation of diseased images likely contributes to the model’s high recall and very low specificity (Garg et al., 27 Jul 2025).

A common misconception would be to interpret the system’s broad disease coverage as disease-specific diagnostic competence. The paper does not support that reading. EyeAI does not classify among 45 diseases; it performs binary classification of “any disease present” versus “healthy” (Garg et al., 27 Jul 2025). Another misconception would be to treat the web application as a replacement for ophthalmologist care. The paper states the opposite: EyeAI is intended as a secondary diagnostic opinion that augments clinical care (Garg et al., 27 Jul 2025).

Future work proposed by the authors is concrete. They recommend expanding and rebalancing the dataset, particularly by increasing healthy examples and underrepresented diseases and sourcing additional FDA-approved images (Garg et al., 27 Jul 2025). They also propose class weighting or focal loss to penalize false positives and improve specificity, hierarchical classification to better discriminate subtle differences among disease subtypes before binary aggregation, alternative architectures and hyperparameters, potential integration directly on retinal imaging machines for instantaneous on-device diagnosis, explainability enhancements such as Grad-CAM, privacy and security hardening, and broader validation across settings (Garg et al., 27 Jul 2025).

The assistive-technology papers suggest parallel design directions under the broader EyeAI label. AIris emphasizes a modular, upgradeable, cloud-assisted architecture with face recognition, scene description, OCR, object recognition, money counting, note-taking, and barcode scanning (Brilli et al., 2024). AIDEN extends this pattern with LLaVA-based scene description and OCR, YOLOv8-based object finding with haptic and voice guidance, and a privacy-by-design stance in which user data are not stored (Marquez-Carpintero et al., 8 Nov 2025). Although these systems address visual assistance rather than retinal diagnosis, they indicate a recurring EyeAI trajectory: integrating perception, accessibility, and practical deployment rather than optimizing only benchmark accuracy.