MastoLens AI: From Computer Vision Models to a Web Demo for Mammography Analysis

Started as mammography experiments with Google Coral, ended as a functional live demo

Over recent months, I worked on a line of projects focused on AI-assisted mammography analysis, generating several tangible artifacts I want to share. What began as an exploratory research effort training models on public datasets developed into a much broader system: data preparation pipelines, comparative architecture benchmarks, edge optimization, and a functional live demo published as part of my portfolio.

This post chronicles that trajectory, the practical engineering hurdles encountered, and the architectural choices that carried the project from initial experiments to a production-ready demonstration.

The Real Challenge Began Before the Model

In computer vision discussions, the spotlight is often on model training, overshadowing the heaviest lift: acquiring, cleaning, organizing, and normalizing raw medical data.

In this project, I worked with multiple public mammography datasets. This meant wrangling disparate formats, inconsistent directory hierarchies, 16-bit DICOM files, JPEG conversions, and fragmented metadata. I developed custom scripts and notebook workflows to automate large-scale dataset downloads, as manual retrieval quickly incurs high storage penalties, wasted time, and operational errors.

This groundwork proved essential for two reasons: it enabled standardized data feeding into diverse training approaches, and it compelled me to architect the project as a reproducible system rather than an isolated notebook script.

The primary datasets leveraged were:

1) CBIS-DDSM

• Official Source: The Cancer Imaging Archive (TCIA).
• Description: A curated, standardized benchmark of the Digital Database for Screening Mammography (DDSM). Includes normal, benign, and malignant cases verified by pathology.
• Approximate Size: 2,620 studies, 6,775 DICOM series, and 10,239 images.
• Project Role: Primary dataset for model training, object detection, and computer-aided diagnosis tasks.

2) ViNDR-Mammo

• Official Source: PhysioNet.
• Description: A full-field digital mammography screening dataset collected by Vinmec and the Vietnam National Cancer Hospital, tailored for cross-population benchmarking against Western cohorts.
• Approximate Size: 20,000 DICOM images from 5,000 patients.
• Project Role: Secondary validation dataset for model comparison and cross-population generalizability testing.

3) RSNA Breast Cancer Detection

• Official Source: Kaggle Competitions (RSNA).
• Description: A competition dataset featuring expert annotations and clinical screening studies.
• Approximate Size: 54,706 DICOM images from 11,913 patients.
• Project Role: Large-scale benchmarking and stress-testing under extreme class imbalance.

Public Technical Documentation

To serve as a robust portfolio case study, I published comprehensive technical documentation on GitHub detailing system architecture, machine learning methodology, security posture, and engineering lessons.

The repository structure:

docs/
├── 00-overview/
│   └── System overview, demo scope, and responsible AI notes.
├── 01-datasets/
│   └── Ingestion and pre-processing for CBIS-DDSM, ViNDR-Mammo, and RSNA.
├── 02-data-pipeline/
│   └── DICOM ingestion and 16-to-8-bit normalization pipeline.
├── 03-modeling/
│   └── Model comparisons, target metrics, and class balancing strategies.
├── 04-edge-and-coral/
│   └── INT8 quantization and Coral Edge TPU compilation.
├── 05-demo-web/
│   └── Web architecture with Flask, Redis, and RQ Worker.
├── 06-security-and-privacy/
│   └── STRIDE threat modeling, JWT auth, CSRF, rate limiting, and sandbox isolation.
├── 07-engineering-lessons/
│   └── System design tradeoffs and GPU/CUDA deployment challenges.
├── 08-repository-map/
│   └── Repository ecosystem mapping and data flow.
└── 09-appendix/
    └── Command reference, glossary, and operational troubleshooting.

templates/
├── dataset-card.md
├── decision-record.md
└── experiment-card.md

assets/
└── diagrams/
    ├── architecture.mmd
    ├── data-pipeline.mmd
    ├── inference-flow.mmd
    ├── security-flow.mmd
    └── repository-map.mmd

Highlights from the documentation include:

• System architecture diagrams and request lifecycles.
• Medical image processing pipeline converting 16-bit DICOM to normalized 8-bit RGB representations.
• Contrast enhancement using CLAHE (Contrast Limited Adaptive Histogram Equalization).
• Asynchronous background inference decoupling Flask, Redis, and RQ workers.
• Patient-level split methodology to eliminate data leakage across train/validation sets.
• INT8 post-training quantization for Google Coral Edge TPU acceleration.
• Threat modeling based on STRIDE.
• Mitigations against Path Traversal, CSRF, and image upload abuse.
• Email OTP verification paired with short-lived JWTs.
• Architecture Decision Records (ADRs) tracking engineering choices.
• Pragmatic lessons in TensorFlow, CUDA runtime matching, and containerized deployment.

From Experimental Code to Modular Architecture

The project evolved through distinct phases visible across the repositories. The earliest phase focused on exploratory training, format conversions, and evaluating baseline architectures, resulting in YOLO- and COCO-compatible annotation pipelines and an initial inference prototype.

Next came modularization: separating configuration, data ingestion, training harnesses, and deployment runtimes. During this stage, I explored edge deployment paths, including INT8 quantization for Google Coral Edge TPU using TensorFlow Lite.

This pivot was pivotal. Rather than chasing raw architectural complexity for marginal metric gains, I prioritized viable architectures for production demos operating under resource constraints.

Why the Production Demo Landed on YOLO

While the project explored several families of vision models, the end-to-end production demo converged on YOLO.

This was a deliberate engineering decision: for a live interactive demo, ecosystem maturity, straightforward containerization, inference latency, and clear documentation outweigh cutting-edge research prototypes. YOLO provided a robust path from weights to reproducible, containerized inference with responsive output visualization.

Additionally, the live demo deploys an ensemble strategy utilizing two complementary models to improve detection consistency.

The Demo Is More Than an Interface

The highest technical value of this portfolio project lies in turning machine learning inference into a fully functional product workflow.

The application implements email OTP access codes, usage credit throttling, asynchronous job queues preventing web worker exhaustion, isolated per-analysis file sandboxes, PDF report generation, and curated public samples so evaluators can test the system without uploading sensitive medical data.

These features rarely capture the spotlight like raw benchmark metrics, but they represent the difference between an isolated Jupyter notebook and an operable system addressing authentication, security, concurrency, persistence, and UX.

Hardest Engineering Challenges

Several hurdles deserve mention because they illustrate production realities seldom seen in polished demos:

1. Medical Dataset Volume and Transfer

Transferring large medical datasets involves authenticating against repositories, handling corrupted downloads, retrying interrupted transfers, and architecting directory layouts that survive container rebuilds.

2. Format Heterogeneity

Navigating varying DICOM transfer syntaxes, photometric interpretations, and disparate annotation coordinates required a dedicated normalization step before any model evaluation could begin.

3. ML Environment and CUDA Dependencies

Matching CUDA drivers, PyTorch/TensorFlow versions, and edge compiler toolchains caused significant friction. When targeting Coral Edge TPU, tooling compatibility with newer Python versions proved challenging, underscoring the value of stable, pinned toolchains during early prototyping.

4. Hardening the Live Demonstration

Transitioning from an internal experiment to a publicly accessible web demo demanded application-layer security: email verification with rate-limited OTPs, input sanitization on DICOM headers, isolated image directories, strict HTTP headers, and worker isolation. Balancing open demonstration with defensive engineering was a core engineering lesson.

Key Takeaways

Four primary engineering lessons emerged:

1. In applied AI, modeling is only one component; dataset pipelines, deployment runtimes, inference queuing, and security carry equal weight.
2. The latest research architecture is not always the best engineering choice for a reliable demo. Pragmatic stability and end-to-end integration often deliver superior outcomes.
3. Early documentation and modularization prevent costly refactors as system complexity scales.
4. A strong portfolio project does not need to masquerade as an approved clinical device. Transparently detailing what works, current limitations, and technical learnings carries far greater credibility.

Current State and Next Steps

Today, this project delivers a unified demonstration encompassing:

• Medical dataset ingestion and DICOM normalization.
• Model evaluation and benchmark logging.
• Edge deployment exploration with Google Coral.
• Asynchronous inference architecture in a production container.
• Security controls, session handling, and PDF export generation.

Future exploration includes refining evaluation protocols, streamlining automated reproducibility scripts, and evaluating emerging lightweight architectures as toolchain support matures.

Closing Thoughts

MastoLens AI began as a technical investigation and culminated in a functional live demonstration connecting computer vision, backend engineering, containerized deployment, and user experience into a cohesive case study.

It encapsulates the complete cycle of translating applied artificial intelligence research into an operable, explainable, and production-tested system.