Looking for Technical Feedback on My Deep Learning Project

[PrahitViraajReddy]

🏷️ Discussion Type

Question

Body

Hi everyone!

I'm a final-year B.Tech AI & Data Science student working on an experimental computer vision project: Autism Image Classification Using Deep Learning.

The project uses PyTorch and DenseNet-169 to explore binary image classification on facial images labelled as Autistic and Non-Autistic. It also includes a Streamlit interface for experimental predictions, probability visualisation, model comparisons, and research-related interaction.

Technical implementation

• PyTorch and Torchvision for deep learning
• DenseNet-169 with pretrained weights
• Image preprocessing and data augmentation
• Model evaluation using classification reports and confusion matrices
• Streamlit for the interactive interface
• Qwen3 1.7B for a separate research-assistant feature

I'd appreciate feedback on three areas:

1. Model development: Are there important methodological issues I should investigate in the training and evaluation pipeline?
2. Software engineering: How could I improve the project structure, reproducibility, and integration between the model and the Streamlit interface?
3. Project quality: What would you improve to make this a stronger computer vision portfolio project?

I'm particularly interested in specific, actionable technical feedback rather than general suggestions.

Repository: https://github.com/PrahitViraajReddy/Autism-Detection

This is an experimental educational project, not a clinically validated diagnostic system. Its predictions should not be used for medical decisions.

Thanks for your time and feedback!

Guidelines

• I have read and understood this category's guidelines before making this post.

[SIDHIMUSIC]

Great project! I’d focus on a few improvements to make the results more reliable and the project easier to reproduce.

1. Model development and evaluation

• Use a patient-level train/validation/test split, if multiple images can belong to the same patient, to reduce data leakage.
• Report precision, recall, F1-score, and a confusion matrix alongside accuracy. For an imbalanced dataset, consider ROC-AUC and PR-AUC as well.
• Apply augmentation only to the training set, and evaluate the final model on a held-out test set.
• Compare DenseNet-169 against a simple baseline and document the preprocessing and hyperparameters.

2. Software engineering

• Separate the project into modules for data loading, preprocessing, training, evaluation, and Streamlit inference.
• Store configuration values and random seeds centrally, and document the Python and PyTorch versions.
• Save the model weights and class mapping together so that inference uses the same label order and preprocessing as training.
• Add a "requirements.txt", setup instructions, and a small test for the prediction pipeline.

3. Streamlit and project quality

• Validate uploaded image formats and dimensions, and handle invalid inputs gracefully.
• Display class probabilities with a clear explanation that these are model outputs, not calibrated medical probabilities unless calibration has been evaluated.
• Include dataset provenance, limitations, and known failure cases in the README.
• Add example screenshots and clear steps for reproducing the reported metrics.

Because this is an autism image-classification project, I’d also make the limitations especially explicit: image-based predictions should not be presented as a clinically validated diagnostic method without appropriate clinical evidence.

Overall, I’d prioritize leakage-resistant evaluation and reproducibility before adding more model complexity. Those changes would make the project much stronger as an educational computer-vision portfolio piece.

[KPriyanshuCodes]

Good README, especially the limitations section. SIDHIMUSIC covered the basics, so here are some points specific to this pipeline. I've only read the README, so treat these as things to verify in the code.

1. Model development

• Test-set contamination through model comparison. You compare several architectures (DenseNet-169, RegNet, MobileNet, ViT, AlexNet) and save the best checkpoint by a validation criterion. If any choice (architecture, epoch, learning rate, augmentation) was made by looking at test results, the test metric is optimistic. Pick everything on validation, then evaluate each final model on the test set once.
• Duplicates and near-duplicates across splits. README mentions possible leakage. This dataset comes from Kaggle, so I'd check it directly: compute perceptual hashes (for example with imagehash) or embedding similarity, and count matches between train, validation and test. Also check whether images of the same person appear in more than one split.
• Shortcut checks. (a) Train with randomly shuffled labels. Accuracy well above chance means leakage. (b) Evaluate on crops with the face masked out, or on background-only regions. If performance stays high, the model isn't using the face. (c) Run Grad-CAM on correct and incorrect predictions. (d) Look at simple image statistics (resolution, file size, brightness) by class, since scraped datasets often differ by source.
• Augmentation. Make sure the validation and test transforms are deterministic (resize, center crop, normalise) and that random flips, rotations and colour jitter are train-only. Colour jitter on faces can also hide or create cues, so I'd test its effect in an ablation.
• Reporting. Add a results table with per-class precision and recall, ROC-AUC, and a confidence interval (bootstrap, or mean and standard deviation over several seeds or stratified folds). One run on a small test set is a noisy estimate.

2. Software engineering

• One preprocessing module imported by both train.py and app.py, so inference can't drift from training. Save class_to_idx, the image size and the normalisation values in the checkpoint file together with the weights.
• Pinned dependencies in requirements.txt (including the Torch and Torchvision versions), a config file for hyperparameters, and seeds set for random, numpy and torch.
• Streamlit. Load the model once with st.cache_resource. Validate uploads (format, size, corrupted files). The model will return a confident class for any image, including a photo of a dog or a blank picture. Add a face-detection step or reject low-confidence or out-of-distribution inputs.
• Calibration. Softmax scores are usually over-confident. Check a reliability diagram or expected calibration error, and consider temperature scaling before showing "probabilities".
• Basic tests and CI. A small test that loads the model, runs one image and checks the output shape and class order. Add a GitHub Actions workflow that runs it.

3. Project quality

• Add a model card and dataset card to the repo: source, labelling method, class counts, splits, known issues.
• Add an error-analysis section with example failures.
• Consider framing the project as a study of dataset bias and shortcut learning, with the checks above as the main result, rather than as a classifier. Facial-image autism prediction is scientifically contested, so a negative or cautionary result would be more credible than a high accuracy number.
• For the public demo, state clearly what happens to uploaded images (not stored or logged), and keep the disclaimer next to every prediction.
• Keep the Qwen3-1.7B assistant visibly separate and label its answers as possibly wrong.

If you do only two things first: run the duplicate check and the shuffled-label control. They tell you whether the current metrics mean anything.

[maxmos2222]

w

[christoferpedrosanchezzuzunaga-eng]

Hi @PrahitViraajReddy,

Solid project choice. DenseNet-169 works great for facial features due to feature reuse across layers, but working with medical/behavioral facial datasets has a few common traps to watch out for:

1. Subject-level data leakage: Make sure images from the same person don't end up in both your train and validation sets. If you use a random split, the model will just memorize specific identities instead of learning generalizable cues. Use GroupKFold on subject IDs if possible.
2. Streamlit inference bottleneck: Don't load the PyTorch weights inside your button click handler. Wrap your model loading inside @st.cache_resource so the model stays in memory across UI reruns, and remember to call model.eval() with torch.no_grad() during inference.
3. Interpretability: Facial classification for conditions like this is prone to learning spurious correlations (like background, lighting, or hair). Running Grad-CAM on your test samples will give you visual proof of which facial regions the network is actually focusing on.

[christoferpedrosanchezzuzunaga-eng]

Hi @PrahitViraajReddy,

Solid project choice. DenseNet-169 works great for facial features due to feature reuse across layers, but working with medical/behavioral facial datasets has a few common traps to watch out for:

1. Subject-level data leakage: Make sure images from the same person don't end up in both your train and validation sets. If you use a random split, the model will just memorize specific identities instead of learning generalizable cues. Use GroupKFold on subject IDs if possible.
2. Streamlit inference bottleneck: Don't load the PyTorch weights inside your button click handler. Wrap your model loading inside @st.cache_resource so the model stays in memory across UI reruns, and remember to call model.eval() with torch.no_grad() during inference.
3. Interpretability: Facial classification for conditions like this is prone to learning spurious correlations (like background, lighting, or hair). Running Grad-CAM on your test samples will give you visual proof of which facial regions the network is actually focusing on.