Forem: HydraBytes

Building a 3-Class Lung Cancer Image Classifier with TensorFlow and Flask

HydraBytes — Tue, 14 Apr 2026 17:26:35 +0000

Medical imaging is one of the most rewarding spaces to apply deep learning. Pathologists spend years learning to distinguish subtle visual patterns in tissue samples, and even then, fatigue and caseload pressure can creep into decisions. A well-trained CNN does not replace that expertise, but it can serve as a useful second opinion, especially in triage workflows.

In this post we will walk through how we built a lung cancer image classifier that sorts tissue images into three classes: Adenocarcinoma, Benign, and Squamous Cell Carcinoma. The model runs behind a Flask API with a simple upload-and-predict web interface, so anyone can drop in an image and see the prediction in real time.

Full code and dataset links are on GitHub.

Why these three classes

Lung cancer is commonly divided into small cell and non-small cell types. Within non-small cell lung cancer, adenocarcinoma and squamous cell carcinoma are the two most prevalent subtypes, together making up the majority of cases. Correctly separating them matters because treatment pathways can differ meaningfully.

Adding a benign class gives the model a "nothing to worry about" option so it does not force every input into a cancer label. That three-class setup reflects the kind of decision a real classifier would need to make in a triage tool.

The dataset

We used a public Kaggle lung cancer histopathology dataset, organized into three balanced classes with separate training and testing folders. The directory structure looked like this:

dataset/
├── train/
│   ├── adenocarcinoma/
│   ├── benign/
│   └── squamous_cell_carcinoma/
└── test/
    ├── adenocarcinoma/
    ├── benign/
    └── squamous_cell_carcinoma/

Keras' ImageDataGenerator made it trivial to load images directly from these folders and apply augmentation on the fly. Data augmentation matters a lot for medical imaging because real datasets are almost always smaller than what a fresh CNN would prefer. We used random flips, small rotations, and zoom to expand the effective training set without collecting new samples.

Model architecture

We went with a custom CNN instead of a pretrained backbone like ResNet or VGG. The reasoning: histopathology images have different statistics from natural photographs (no sky, no faces, strong staining colors), so the features learned on ImageNet are not always the best starting point. A purpose-built network with fewer parameters also trains faster and is easier to reason about.

The architecture is intentionally simple:

Layer	Details
Conv2D + ReLU	32 filters, 3x3 kernel
MaxPooling2D	2x2 pool
Conv2D + ReLU	64 filters, 3x3 kernel
MaxPooling2D	2x2 pool
Flatten
Dense + ReLU	128 units
Dropout	0.5
Dense + Softmax	3 output units

Two convolutional blocks are enough to capture the low and mid-level texture patterns that distinguish tumor tissue from benign tissue. The dropout layer before the final dense block is doing heavy lifting: without it, the model happily memorized the training set and validation accuracy plateaued much earlier.

Here is the model definition in Keras:

from tensorflow.keras.models import Sequential
from tensorflow.keras.layers import Conv2D, MaxPooling2D, Flatten, Dense, Dropout

model = Sequential([
    Conv2D(32, (3, 3), activation='relu', input_shape=(224, 224, 3)),
    MaxPooling2D((2, 2)),
    Conv2D(64, (3, 3), activation='relu'),
    MaxPooling2D((2, 2)),
    Flatten(),
    Dense(128, activation='relu'),
    Dropout(0.5),
    Dense(3, activation='softmax'),
])

model.compile(
    optimizer='adam',
    loss='categorical_crossentropy',
    metrics=['accuracy'],
)

Training

Training ran for a modest number of epochs with early stopping watching validation loss. Adam as the optimizer, categorical cross-entropy as the loss, and a 70/15/15 train/validation/test split. Nothing exotic. The trained weights are saved to models/lung_cancer_model.h5 so the Flask app can load them at startup instead of retraining every time.

A lesson we learned early: always shuffle within each class before splitting. Our first split was sequential and it put nearly all adenocarcinoma images from one subfolder into the training set and the rest into validation, which tanked validation accuracy for that class. Shuffling fixed it in one line.

Flask integration

The serving side is a tiny Flask app with a single route that handles both the GET (render upload page) and POST (accept image, run prediction) flows:

from flask import Flask, request, render_template
from tensorflow.keras.models import load_model
from PIL import Image
import numpy as np

app = Flask(__name__)
model = load_model('models/lung_cancer_model.h5')
CLASSES = ['Adenocarcinoma', 'Benign', 'Squamous Cell Carcinoma']

@app.route('/', methods=['GET', 'POST'])
def upload_and_predict():
    if request.method == 'POST':
        file = request.files['image']
        img = Image.open(file).resize((224, 224)).convert('RGB')
        arr = np.expand_dims(np.array(img) / 255.0, axis=0)
        preds = model.predict(arr)[0]
        predicted = CLASSES[np.argmax(preds)]
        confidence = float(np.max(preds))
        return render_template(
            'index.html',
            prediction=predicted,
            confidence=f'{confidence:.1%}',
            image_path=file.filename,
        )
    return render_template('index.html')

Loading the model once at startup (instead of per request) is a small detail that matters a lot for response times. The first prediction warms up TensorFlow, and everything after that returns in well under a second on CPU.

The front-end

The user-facing interface is plain HTML, CSS, and a sprinkle of Bootstrap. No React, no framework overhead. A big drop zone for the image, a preview, and a result card that renders the predicted class with its confidence score. The goal was to keep the whole experience friction-free so someone without technical background can still use it.

Results

After training, our numbers landed at:

Training accuracy: around 95%
Validation accuracy: around 96%
Test accuracy: around 97%

The validation accuracy sitting slightly above training is a little unusual and usually a sign that dropout is doing its job, regularizing the model enough that it generalizes cleanly. We also checked per-class precision and recall to make sure the model was not gaming its accuracy by over-predicting the majority class. All three classes came back balanced.

Limitations and honest caveats

A few things we want to be upfront about:

This is not a clinical tool. Public histopathology datasets are carefully curated and do not capture the full range of tissue variation you would see in a real lab. High test accuracy on a clean dataset does not translate to clinical-grade reliability.
Stain variation is the biggest gap. The model has not been tested against images with different staining protocols, scanners, or magnifications.
Three classes is a simplification. Real pathology has many more subtypes and gradings. A production version would need a much deeper label space.

These caveats are part of the reason we picked a custom CNN instead of pretending a ResNet fine-tune on Kaggle data is "ready for deployment". The architecture, training pipeline, and Flask wrapper are all meant to be a solid starting point that a team could extend into a real diagnostic aid with the right dataset partnerships and regulatory path.

Wrapping up

Building this project was a great exercise in the full loop: curating data, designing a CNN small enough to train on a single GPU, wiring it up behind a web interface, and making predictions available in a form anyone could use. The accuracy numbers are strong for a public dataset, but the bigger win was shipping something end to end, from raw images to a working upload-and-predict app.

If you want to try it yourself, clone the repo, drop in the dataset, train the model, and start the Flask server:

python train_model.py
python app.py

The code, architecture diagrams, and screenshots are all on GitHub. Feedback and pull requests are welcome.

At HydraBytes, we love projects like this one: real-world AI problems where the challenge is not just model accuracy but shaping the pipeline so the end result is useful. If you are exploring medical imaging, computer vision, or any ML use case, let's talk at Hydrabytes.tech.

Building an AI-Based Student Stress Management System with Python, ML, and RAG

HydraBytes — Mon, 13 Apr 2026 23:04:32 +0000

Student mental health has become a genuine crisis in universities worldwide. Stress, anxiety, and depression are among the leading causes of academic dropout yet most campuses lack accessible, real-time tools to help students recognize and address what they're experiencing.

We built the AI-Based Student Stress Management System to tackle exactly that. It's a full-stack web platform that uses machine learning to detect stress, anxiety, and depression from questionnaire inputs, then provides instant severity scoring, personalized coping recommendations, and a conversational AI chatbot all in one place.

This post walks through the architecture, the ML pipeline, and the design decisions we made building it.

Repo: TheHydraBytes/AI-based-student-stress-mangement

The Problem

The standard approach to student mental health support is: fill out a form, wait for a counselor to follow up, get an appointment weeks later. By that point, a student in mild-to-moderate distress may have already spiraled.

We wanted something that:

Gave students an immediate, private assessment of where they stood
Offered actionable coping tools they could use right now
Connected them to a professional when needed

Architecture Overview

React Frontend
     |
  Flask Backend (Python)
     |          |           |
   SQL Server   ML Models   AI Chatbot
  (pyodbc)    (scikit-learn) (LangChain + Groq + Qdrant)

The backend is a Flask application. The ML models (three separate classifiers) run as in-process Python objects. The chatbot uses a RAG (Retrieval-Augmented Generation) pipeline backed by Qdrant as the vector store and Groq (LLaMA 3.1) as the LLM.

The ML Pipeline

Three Separate Models

We trained three independent classifiers, one each for stress, anxiety, and depression. Each model:

Takes a questionnaire response as input (Likert-scale answers covering behavioral, cognitive, and physiological symptoms)
Outputs a severity label: Minimal / Mild / Moderate / Severe
Was trained on a labeled clinical survey dataset (PSS, GAD-7, PHQ-9 style)

All three follow the same training pattern:

from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import LabelEncoder, StandardScaler
from sklearn.model_selection import train_test_split
import joblib

df = pd.read_csv("stress.csv")

label_encoder = LabelEncoder()
df["Stress Label"] = label_encoder.fit_transform(df["Stress Label"])

X = df.drop(["Stress Value", "Stress Label"], axis=1)
y = df["Stress Label"]

scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)

X_train, X_test, y_train, y_test = train_test_split(X_scaled, y, test_size=0.2, random_state=42)

model = LogisticRegression(max_iter=500, random_state=42)
model.fit(X_train, y_train)

joblib.dump(model, "logistic_regression_stress.pkl")
joblib.dump(scaler, "scaler.pkl")
joblib.dump(label_encoder, "label_encoder.pkl")

We chose Logistic Regression deliberately. For clinical classification tasks where interpretability and reliability matter more than marginal accuracy gains, it outperforms black-box alternatives like neural networks. We can understand exactly why a sample was classified the way it was.

Real-Time Prediction

When a student submits the questionnaire, all three models run simultaneously and the results are bundled into a single response object:

results_data = {
    'stress_score': stress_score,
    'stress_prediction': stress_label,
    'anxiety_score': anxiety_score,
    'anxiety_prediction': anxiety_label,
    'depression_score': depression_score,
    'depression_prediction': depression_label,
    'demographic_info': demographic_info,
}

The results page shows all three severity scores at once, letting students see the full picture rather than a single-dimension reading.

The RAG Chatbot

The conversational layer is where the system goes beyond a static form. Students can ask the chatbot anything related to their mental health — and it responds using actual clinical knowledge, not just generic LLM hallucinations.

Stack

Embeddings: sentence-transformers/all-mpnet-base-v2 via HuggingFace
Vector store: Qdrant (cloud-hosted)
LLM: LLaMA 3.1 8B Instant via Groq API (fast, low-latency)
Orchestration: LangChain

The chatbot was trained on a curated mental health knowledge base (embedded as a PDF via embed_documents.py). When a user sends a message, the system retrieves the top relevant chunks from Qdrant, then passes them as context to the LLM.

Crisis Detection

One design decision we're particularly careful about: if a student types something that suggests a suicidal crisis, the chatbot does not attempt to respond as a therapist. It immediately surfaces emergency contact information.

crisis_triggers = [
    "i want to die", "i want to end it all", "i don't want to live",
    "i'm done with everything", "ending my life",
    "i think about suicide", "i have no reason to live"
]

The system detects these triggers before the RAG pipeline even runs. Automated AI responses should never substitute for human intervention in a genuine crisis.

Features Beyond Assessment

A questionnaire and a chatbot are the core, but the system includes several additional tools students can use day-to-day.

Mindfulness Games

Two browser-based games built to reduce acute stress:

Bubble Pop Game: Timed focus exercise. Simple, but effective for grounding.
Puzzle Game: Cognitive engagement that shifts attention away from anxiety spirals.

Game session data is stored and shown in the user's progress dashboard.

Guided Breathing Exercises

An animated breathing guide with session tracking. The /breathing route stores per-session stats so students can track consistency over time.

Progress Dashboard

Every student gets a personal dashboard showing:

Historical assessment results (trend over time)
Breathing and game session stats
Upcoming counselor appointments

Doctor Appointment Booking

Students can browse available counselors, check open slots via the /api/available_slots endpoint, and book appointments directly through the platform. Admins can accept, reschedule, or cancel bookings through a separate admin dashboard.

Admin Panel

The /admin_dashboard gives university mental health staff a full view of the system:

User management: view/delete student accounts
Assessment history: aggregate submissions across all students
Chatbot ratings: feedback on response quality
Appointment management: approve, reschedule, cancel appointments

This matters because the platform is designed to integrate with, not replace, existing campus counseling infrastructure.

Security Decisions

A mental health platform handles particularly sensitive data. A few things we made sure to get right:

Security headers on every response:

@app.after_request
def after_request(response):
    response.headers['X-Frame-Options'] = 'DENY'
    response.headers['X-Content-Type-Options'] = 'nosniff'
    response.headers['X-XSS-Protection'] = '1; mode=block'
    response.headers['Referrer-Policy'] = 'strict-origin-when-cross-origin'
    return response

Cache prevention on protected routes: The @require_login decorator adds no-cache, no-store, must-revalidate headers so assessment results cannot be retrieved from browser cache by a shared device user.

Password reset via security questions instead of email-only, reducing dependency on email deliverability for account recovery.

What We'd Do Differently

Switch to PostgreSQL properly. The app currently uses SQL Server via pyodbc with a local SSMS connection string hardcoded for development. Moving to PostgreSQL on a hosted provider (Supabase, Neon) would make deployment portable.

Add model versioning. The .pkl files are committed directly to the repo. As the training data grows, we'd want MLflow or a similar registry to track model versions alongside accuracy metrics.

Upgrade the chatbot to streaming. The current Groq integration waits for the full response before sending it. Streaming tokens to the frontend would make the chatbot feel significantly more responsive.

Try It Yourself

The full source is on GitHub under the HydraBytes organization:

github.com/TheHydraBytes/AI-based-student-stress-mangement

git clone https://github.com/TheHydraBytes/AI-based-student-stress-mangement.git
cd AI-based-student-stress-mangement
pip install flask scikit-learn pandas numpy langchain-huggingface langchain-groq langchain-qdrant
npm install
cd flask_app && python app.py

You'll need to set QDRANT_HOST, QDRANT_API_KEY, and GROQ_API_KEY environment variables for the chatbot to work. The ML models and Flask routes function independently without them.

Built by HydraBytes — a digital solutions agency based in Pakistan.

If you're building something in the mental health tech space and want to talk architecture, drop a comment below.

How We Built an AI-Powered Retinal Disease Detector

HydraBytes — Sat, 11 Apr 2026 12:50:33 +0000

Early detection of retinal diseases like diabetic retinopathy can prevent blindness in millions of patients worldwide. Yet access to specialist ophthalmologists remains limited, especially in developing countries. That's the problem we set out to solve with OptiPro.

- What is OptiPro?

OptiPro is an AI-powered retinal disease detection system that analyzes fundus images and classifies retinal conditions with high accuracy giving clinicians a fast, reliable second opinion.

- How It Works

The core model is a convolutional neural network (CNN) trained on labeled fundus image datasets. The pipeline looks like this:

Image ingestion — fundus photos uploaded via web interface
Preprocessing — resizing, normalization, contrast enhancement
Inference — CNN classifies the image across multiple disease categories
Result — confidence score + condition label returned to the clinician

- Tech Stack

Model: Python, TensorFlow, OpenCV
Backend: FastAPI
Frontend: Next.js
Deployment: Docker

- What We Learned

Training on imbalanced medical datasets is hard. We used weighted loss functions and aggressive augmentation (flips, rotations, brightness shifts) to prevent the model from overfitting to the majority class.

- What's Next

OptiPro is currently in beta. We're working on expanding the disease categories and integrating it into clinical workflows.

We build projects like this at https://www.hydrabytes.tech - a web, mobile, and AI development agency based in Islamabad. If you're working on something ambitious, let's talk.