DermReady

• 

• 

• 

• 

• 

Inspiration

A photograph can be easy to take and difficult to interpret. Blur, poor lighting, and lost detail can make it harder to communicate a skin concern remotely. Yet people often have little guidance on whether to retake a photograph or what to change.

We built DermReady around a simple question: Can we help people take a clearer photograph before they share it with a clinician?

Our goal was to turn capture-quality signals into understandable guidance while being honest about what those signals can—and cannot—tell us.

What it does

DermReady is a web application for exploring the capture quality of dermatology photographs. It lets users:

• Check a photograph: Review measurable indicators such as focus and brightness.
• Find a next step: Receive practical capture guidance alongside a research assessment.
• Compare a retake: Compare two independently captured photographs to see how their measurable indicators changed.
• Explore the evidence: Read the system’s evaluation results, uncertainty, and limitations.

The research assessment can return suitable, retake, or uncertain. These describe the system’s capture-quality assessment; they do not establish that an image is clinically adequate.

DermReady does not diagnose skin conditions or enhance photographs. It helps users explore their original captures and decide what to try next.

How we built it

We built the image-processing pipeline in Python, using OpenCV, NumPy, and Pillow to process photographs and calculate capture indicators. We used Gradio for the interactive interface and deployed the application on Render, with source code maintained on GitHub.

Our research workflow used the SCIN dataset, with separate training, validation, and held-out test splits at the case level. We explored both a convolutional neural network and a fitted baseline based on image-quality features. We selected the baseline on validation data and froze the model and decision policy before evaluating the test set.

The deployed application uses that fitted baseline, with checks to verify that its model and policy artifacts match the published evaluation artifacts.

We also designed the interface around three steps: check your capture, find your next step, and compare a retake. We kept the language accessible and made the evidence visible within the application.

Challenges we faced

Defining what “quality” means

A sharp, well-lit image is not automatically useful for a clinical assessment. Framing, context, the condition being photographed, and a clinician’s requested views also matter.

We therefore kept our claims focused on measurable capture indicators. The dataset’s case-level labels serve as a weak proxy for individual image quality, which limits what our evaluation can establish.

Handling uncertainty honestly

The baseline returned uncertain on 61 of 107 held-out cases. That challenged us to make uncertainty useful rather than hide it.

We kept the uncertain outcome visible, explained its meaning, and paired the assessment with practical capture guidance. We did not adjust thresholds after seeing the test results to make the system appear more decisive.

Understanding potential bias

Brightness depends on skin tone, lighting, background, and camera settings. It is not a measurement of skin tone. A quality system that treats brightness too simplistically could give misleading guidance.

We documented these risks and made clear that performance across skin tones, ages, conditions, and devices has not been established.

Making the deployed interface readable

Testing across devices revealed a theme conflict: browsers using dark mode displayed some dark controls beneath dark text in our light layout. We corrected the theme and verified the live interface in both light and dark modes.

Managing uploads responsibly

Photographs can contain sensitive information. We added upload limits, configured temporary-file cleanup, and made the upload-handling limitations visible. The public demo encourages synthetic examples or photographs users have permission to share.

What we learned

We learned that building a useful research prototype requires more than producing a prediction. Users need to understand the result, the evidence behind it, and the action they can take next.

We also learned the value of separating model selection from final evaluation, preserving the original photograph, testing the deployed experience across environments, and treating uncertainty as meaningful information.

Most importantly, capture quality and clinical usefulness are different questions. Keeping that distinction clear shaped both our technical decisions and our interface.

What we’re proud of

We turned a research pipeline into a deployed, interactive application with understandable guidance, retake comparison, and accessible evidence.

DermReady brings the assessment and its limitations into the same experience. Users can explore measurable changes without having their photographs altered or being given unsupported diagnostic claims.

What’s next

We want to strengthen DermReady through:

• Clinician-reviewed labels for individual photographs.
• Larger, more diverse evaluation datasets.
• Subgroup evaluation across skin tones, devices, and capture settings.
• Better assessment of framing and requested photographic views.
• User testing to determine whether the guidance helps people capture more useful photographs.

Our long-term goal is to support clearer communication between people and clinicians through better photographs and more understandable capture guidance.

Built With

• ai
• computervision
• datascience
• gradio
• healthcare
• imageai
• machine-learning
• mobilenetv3
• opencv
• python
• pytorch
• responsibleai
• scindataset
• webapp