manishkumarsingh41/luminapath-ai-retinal-disease-detection

Purpose and Runtime Entry Point

LuminaPath is a local Python/Streamlit application for classifying retinal OCT images with a trained CNN, presenting confidence and explanatory text, and producing downloadable medical PDF reports. The operational entry point is frontend/app.py, launched with streamlit run frontend/app.py.

Presentation and Interaction Layer

The Streamlit UI orchestrates the user workflow: scan upload, language selection, prediction display, explanation display, and report download. Its principal composition root is frontend/app.py, with feature-level UI boundaries in:

• frontend/components/upload_section.py

• frontend/components/prediction_view.py

• frontend/components/report_download.py

Styling is locally supplied through frontend/assets/styles.css; no browser SPA, separate API server, or cloud frontend is indicated.

Image Intake Boundary

Uploaded OCT images are accepted by the frontend and passed into backend inference/reporting flows. The accepted image formats are JPG, JPEG, and PNG. Upload handling is isolated in frontend/components/upload_section.py, providing a natural boundary for validation, image-size limits, and future patient-data handling.

Model Inference Pipeline

The CNN inference subsystem loads and evaluates the packaged Keras HDF5 model at models/retinal_cnn_model.h5. backend/model_inference.py is the core model boundary and is responsible for preprocessing input images, invoking TensorFlow/Keras prediction, and returning disease prediction plus confidence information.

The model artifact is versioned in-repository rather than fetched from a model registry or external inference service.

Application Service/API Layer

backend/api.py is the backend-facing integration layer between UI orchestration and domain services. It is the likely contract boundary for prediction-related calls, insulating Streamlit components from model implementation details. The repository is a single-process application structure: “backend” modules are Python modules consumed by the Streamlit process, not evidence of a separately deployed HTTP API.

Explanation and Localization Stage

Prediction results feed an explanation view, with language choice handled independently from rendering:

• frontend/components/language_selector.py

• frontend/components/explanation_view.py

This stage converts raw classification output into practitioner-facing explanatory content and supports multi-language presentation. It should remain downstream of inference so localization does not affect model inputs or outputs.

Report Generation and Delivery

backend/report_generator.py produces structured PDF reports from the uploaded scan context and inference result. frontend/components/report_download.py exposes the generated artifact to the user. The README states report generation can trigger automatic prediction, so report creation depends on, or can initiate, the inference pipeline rather than trusting only a displayed UI result.

Material Dependencies and External Boundaries

Core runtime technologies are Python, Streamlit, TensorFlow/Keras, and PDF-generation dependencies declared in requirements.txt. The only supplied ML infrastructure is the local .h5 model artifact. No database, authentication provider, cloud storage, hospital integration, remote model endpoint, or external API is documented. As a medical-support workflow, image uploads, predictions, and generated reports are the sensitive data boundaries.