WAIT — Slowing — last commit 4mo ago

• Last commit 4mo ago
• 2 active contributors
• GPL-3.0 licensed
• Tests present
• ⚠ Slowing — last commit 4mo ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 88% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

Educational deep learning repository containing production-ready implementations of CNN architectures (LeNet, AlexNet, VGG, ResNet, EfficientNet, Vision Transformer, etc.) for image classification and object detection, paired with model deployment pipelines that convert PyTorch models to ONNX, OpenVINO IR, and TensorRT formats for inference optimization. Monorepo with three main sections: (1) pytorch_classification/ and tensorflow_classification/ containing model implementations organized by architecture name (ResNet, MobileNet, etc.), (2) deploying_service/deploying_pytorch/ with subfolders for ONNX export, OpenVINO conversion, TensorRT quantization, and Flask REST service examples, (3) supporting data_set/ with dataset splitting utilities and course_ppt/ with lecture materials.

Computer vision students and practitioners learning CNN fundamentals who need working PyTorch/TensorFlow implementations with accompanying video lectures (via Bilibili links in README), plus ML engineers deploying trained models to edge devices or inference servers requiring ONNX/OpenVINO/TensorRT conversion.

Actively maintained educational project with comprehensive curriculum covering 15+ canonical architectures (LeNet through Vision Transformer) and deployment examples, but no visible CI/CD pipeline, automated tests, or versioning strategy. The extensive video tutorial index and multi-framework support (PyTorch + TensorFlow/Keras) indicate mature content, but the lack of test coverage and formal release process limits production-readiness.

Single-maintainer risk (WZMIAOMIAO) with no visible issue tracking or PR workflow documented. Dependency stack includes older pinned versions (torch==1.11.0, onnxruntime==1.8.0, openvino-dev==2022.1.0) that may have security implications; no lock file or dependency audit visible. Educational focus means breaking changes in upstream libraries (PyTorch 2.x migration) could leave code samples stale.

No commit timestamp or recent PR data available in provided file structure. The README indicates comprehensive curriculum completion (all major architectures marked as '已完成'/complete), suggesting either stable maintenance or stalled development—cannot determine from metadata alone.

git clone https://github.com/WZMIAOMIAO/deep-learning-for-image-processing.git
cd deep-learning-for-image-processing
pip install torch==1.11.0 torchvision==0.12.0 matplotlib
python pytorch_classification/resnet/train.py  # or equivalent for chosen model

Daily commands: No Makefile or startup script visible. For classification training: python pytorch_classification/{model_name}/train.py (requires dataset in data_set/ structured by split_data.py). For Flask service: cd deploying_service/deploying_pytorch/pytorch_flask_service && python main.py (expects class_indices.json and trained model weights in same directory).

• pytorch_classification/ConvNeXt/train.py — Core training pipeline for classification models; demonstrates the standard train loop pattern used across all pytorch_classification experiments
• pytorch_classification/ConvNeXt/model.py — Reference implementation of modern architecture; serves as template for understanding model structure conventions in this codebase
• deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/convert_pytorch2onnx.py — Model export pipeline; critical for understanding deployment workflow from PyTorch → ONNX → OpenVINO/TensorRT
• deploying_service/deploying_pytorch/pytorch_flask_service/main.py — Production inference service entry point; demonstrates REST API pattern for serving trained models
• pytorch_classification/ConvNeXt/my_dataset.py — Data loading abstraction; defines the dataset pipeline pattern used across all training experiments
• data_set/split_data.py — Dataset preprocessing utility; foundational for understanding how raw data is prepared for training
• README.md — Course structure and learning objectives; maps the entire educational progression across classification and detection tasks

Add a New Classification Model Architecture

1. Create a new directory under pytorch_classification/ (e.g., pytorch_classification/MyNewNet/) (pytorch_classification/ConvNeXt/)
2. Implement the model class in model.py, following the ConvNeXt pattern with nn.Module subclass (pytorch_classification/ConvNeXt/model.py)
3. Copy and adapt my_dataset.py to match your data format and preprocessing needs (pytorch_classification/ConvNeXt/my_dataset.py)
4. Copy train.py and modify hyperparameters, loss functions, and optimization strategy (pytorch_classification/ConvNeXt/train.py)
5. Create predict.py using the same inference pattern for single image prediction (pytorch_classification/ConvNeXt/predict.py)
6. Add README.md documenting the architecture, training procedure, and performance metrics (pytorch_classification/ConvNeXt/README.md)

Deploy a Trained Model to Production

1. Place your trained .pth checkpoint in deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/ (deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/model.py)
2. Run convert_pytorch2onnx.py to export the PyTorch model to ONNX format (deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/convert_pytorch2onnx.py)
3. Apply INT8 quantization to reduce model size using quantization_int8.py (deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/quantization_int8.py)
4. Update class_indices.json with your dataset class labels (deploying_service/deploying_pytorch/pytorch_flask_service/class_indices.json)
5. Modify main.py to load your model and update the Flask routes if needed (deploying_service/deploying_pytorch/pytorch_flask_service/main.py)
6. Run the Flask service locally or deploy to a cloud provider via requirements.txt dependencies (deploying_service/deploying_pytorch/pytorch_flask_service/requirements.txt)

Optimize a Model for Inference on Edge Devices

1. Convert PyTorch model to ONNX using convert_pytorch2onnx.py (deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/convert_pytorch2onnx.py)
2. Apply INT8 quantization to reduce precision and model footprint (deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/quantization_int8.py)
3. Use compare_onnx_and_ir.py to benchmark original vs. optimized model throughput (deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/compare_onnx_and_ir.py)
4. Optionally apply model pruning via train.py in pruning_model_pytorch/ for further compression (deploying_service/pruning_model_pytorch/train.py)

• PyTorch — Primary deep learning framework for model implementation and training; chosen for dynamic computation graphs and extensive ecosystem for computer vision
• ONNX — Interoperable model format enabling conversion to OpenVINO, TensorRT, and other inference runtimes without framework lock-in
• OpenVINO — Intel's inference optimization toolkit for CPU/GPU deployment with INT8 quantization support; demonstrates edge device optimization
• TensorRT — NVIDIA's inference accelerator for GPU deployment; enables low-latency inference on CUDA-capable hardware
• Flask — Lightweight web framework for REST API serving; suitable for educational purposes and small-to-medium inference services

• Multiple deployment backends (OpenVINO, TensorRT, Flask) instead of single unified service

  • Why: Educational codebase showcasing different optimization and deployment strategies across CPUs, GPUs, and cloud environments
  • Consequence: Increased maintenance surface area and code duplication, but maximum flexibility for learning different deployment paradigms

• Synchronous REST API (Flask) instead of async message queue (Celery, Kafka)

  • Why: Simplicity for demonstration and educational clarity; suitable for single-request inference scenarios
  • Consequence: Limited scalability for high-throughput production workloads; would require refactoring for production-grade services

• INT8 quantization as primary optimization strategy

  • Why: Significant latency/throughput improvements with minimal accuracy loss; widely supported across inference engines
  • Consequence: Potential 1-3% accuracy degradation depending on model; requires validation per architecture

• Separate train/predict/deploy scripts instead of unified pipeline framework

  • Why: Transparency for learners to understand each stage independently without framework abstractions
  • Consequence: Manual orchestration required; easier for educational exploration but harder for production automation

• Real-time distributed training across multiple nodes or GPUs
• Handling video streams or temporal sequence models

Hardcoded paths: Class indices mapping is stored in class_indices.json files scattered across deployment folders; must match training dataset class order exactly or predictions will be misaligned. Model weights not included: Training scripts assume ImageNet pretrained weights via torchvision.models, but fine-tuning requires manual weight placement in expected directory structure (not documented). Python 3.8+ dependency: ONNX export and TensorRT require specific PyTorch/CUDA version combinations; mixing torch==1.11.0 with CUDA 12.x will fail silently. Flask service port hardcoded: pytorch_flask_service/main.py likely hardcodes port 5000 without environment variable override—check before multi-service deployment. No validation splits: split_data.py creates train/val only; test set preparation is manual or missing entirely.

• Residual Connections (Skip Connections) — ResNet and subsequent architectures in this repo depend critically on skip connections to enable training of very deep networks; understanding this enables proper interpretation of model.py code for ResNet, ResNeXt, EfficientNet variants
• ONNX (Open Neural Network Exchange) — Core format used throughout deploying_service/ for cross-platform model portability (PyTorch → TensorRT, OpenVINO, ONNX Runtime); required to understand convert_pytorch2onnx.py scripts and inference optimization pipelines
• INT8 Quantization — Post-training quantization technique used in TensorRT and OpenVINO conversion scripts to reduce model size and latency on edge devices; essential for understanding deployment optimization trade-offs in quantization.py files
• Depthwise Separable Convolutions — Core building block of MobileNet and ShuffleNet architectures in this repo's model zoo; understanding this concept clarifies why these models are efficient enough for edge deployment in pytorch_classification/mobilenet/ and pytorch_classification/shufflenet/
• Multi-Head Self-Attention — Foundation mechanism for Vision Transformer implementation in this repo; referenced in course_ppt and video lectures; required to understand transformer-based classification alternative to CNNs
• Flops/Latency Benchmarking — Compare_fps.py and compare_onnx_and_ir.py scripts measure inference performance across frameworks; understanding how to interpret these benchmarks is critical for making deployment trade-off decisions between accuracy and speed
• Knowledge Distillation in Model Pruning — Pruning model pruning directory suggests teacher-student model compression; this concept explains how to maintain accuracy while reducing parameters for deployment constraints in deploying_service/pruning_model_pytorch/

• pytorch/vision — Official PyTorch model zoo providing pre-trained weights and canonical architecture implementations (ResNet, MobileNet, etc.) that this repo extends with training loops and deployment examples
• tensorflow/models — Official TensorFlow model collection offering the same architecture suite as companion implementation; both this repo's PyTorch and TensorFlow sections reference these for weights initialization
• openvinotoolkit/openvino — Intel OpenVINO deployment framework used extensively in deploying_service/deploying_pytorch/convert_openvino/ for model optimization and inference on CPU/edge devices
• NVIDIA/TensorRT — NVIDIA TensorRT quantization and inference engine required for deploying_service/deploying_pytorch/convert_tensorrt/ GPU acceleration examples
• ultralytics/yolov5 — YOLOv5 object detection framework with OpenVINO conversion example in deploying_service/deploying_pytorch/convert_openvino/convert_yolov5/—demonstrates deployment pipeline for detection tasks beyond classification

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for data_set/split_data.py and model conversion utilities

The repo has critical data processing and model conversion scripts (split_data.py, convert_pytorch2onnx.py, quantization scripts) but no test coverage. This is high-value because these scripts are foundational - bugs here affect all downstream training and deployment. Tests would validate data splitting logic, ONNX conversion correctness, and quantization outputs across different model architectures.

• [ ] Create tests/test_data_split.py with test cases for data_set/split_data.py (train/val/test split ratios, edge cases)
• [ ] Create tests/test_model_conversion.py to validate ONNX export works correctly for deploying_service/deploying_pytorch/convert_onnx_cls/main.py and convert_pytorch2onnx.py scripts
• [ ] Create tests/test_quantization.py to test INT8 quantization output for both ResNet34 and YOLOv5 in deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/quantization_int8.py
• [ ] Add pytest configuration and GitHub Actions workflow to run tests on PR

Create unified requirements.txt and dependency version pinning strategy

The repo has fragmented requirements.txt files across multiple subdirectories (convert_resnet34/, convert_yolov5/, pytorch_flask_service/, etc.) with inconsistent or missing version constraints. This causes reproducibility issues. Consolidating with clear dependency matrices by use-case (classification vs detection, training vs deployment) helps new contributors quickly set up the correct environment.

• [ ] Audit all requirements.txt files: deploying_service/deploying_pytorch/convert_onnx_cls/, convert_openvino/convert_resnet34/requirements.txt, convert_openvino/convert_yolov5/requirements.txt, pytorch_flask_service/requirements.txt
• [ ] Create a root requirements/ directory with: requirements-base.txt (torch, torchvision, core deps), requirements-classification.txt, requirements-detection.txt, requirements-deployment-openvino.txt, requirements-deployment-tensorrt.txt
• [ ] Update each subdirectory's requirements.txt to reference the consolidated files with pip -r syntax or update README with setup instructions
• [ ] Add dependency conflict checking in CI and document Python version support (e.g., 3.8-3.10)

Add integration tests for deploying_service Flask app and model serving pipelines

The pytorch_flask_service in deploying_service/deploying_pytorch/pytorch_flask_service/main.py provides web service capability but has no automated tests. This is high-value for a deployment-focused repo because it validates the end-to-end serving pipeline (model loading, inference, response formatting). Tests would catch regressions when model architecture or class_indices.json changes.

• [ ] Create tests/test_flask_service.py with fixtures that start the Flask app from deploying_service/deploying_pytorch/pytorch_flask_service/main.py
• [ ] Add test cases for: model loading correctness, image upload/prediction endpoint with sample images, response JSON format validation, class label mapping from class_indices.json
• [ ] Create tests/test_model_inference.py to validate inference results match between PyTorch, ONNX, OpenVINO IR, and TensorRT formats using the same test images
• [ ] Add pytest markers and GitHub Actions workflow to run integration tests (separate from unit tests, since they require model downloads)

• Add automated unit tests for model forward pass in pytorch_classification/{model_name}/test_model.py—currently no test files exist; easy wins: test output shape correctness for ResNet, MobileNet, EfficientNet with dummy batch inputs of shape (B, 3, H, W).
• Document exact dataset directory structure required by each training script (CIFAR-10 vs ImageNet folder layout)—currently ambiguous in README; add data_set/DATASET_FORMAT.md with examples and clarify expectations in training script docstrings.
• Create unified inference wrapper class in deploying_service/common/inference_engine.py to abstract ONNX Runtime, OpenVINO, and TensorRT backends—eliminates duplicate model loading logic across three conversion folders and improves maintainability.

• High · Outdated and Vulnerable Dependencies — requirements.txt / dependency specifications. Multiple dependencies have known vulnerabilities. Specifically: torch==1.11.0 (latest is 2.x), torchvision==0.12.0 (outdated), protobuf==3.19.5 (has known CVEs), onnxruntime==1.8.0 (significantly outdated with potential security patches missing). These versions lack critical security patches and bug fixes. Fix: Update all dependencies to their latest stable versions: torch>=2.0.0, torchvision>=0.15.0, protobuf>=4.23.0, onnxruntime>=1.16.0, openvino-dev>=2023.2.0. Implement automated dependency scanning with tools like Dependabot or Snyk.
• High · Flask Service Without Security Headers — deploying_service/deploying_pytorch/pytorch_flask_service/main.py. The Flask service at deploying_service/deploying_pytorch/pytorch_flask_service/main.py likely lacks critical security headers (CSRF protection, CSP, X-Frame-Options, etc.). This could expose the application to common web attacks. Fix: Implement security headers using Flask-Talisman or equivalent. Add CSRF protection with Flask-WTF. Enable CORS only for trusted domains. Use secure session configuration with secure=True, httponly=True, samesite='Strict'.
• High · Potential Arbitrary File Upload Vulnerability — deploying_service/deploying_pytorch/pytorch_flask_service/main.py and templates/up.html. The Flask service accepts file uploads (up.html template suggests image upload functionality). Without proper validation, this could lead to arbitrary file upload, path traversal, or malicious file execution attacks. Fix: Implement strict file validation: check MIME types, file extensions (whitelist), file size limits, store uploads outside webroot, rename files with UUIDs, use antivirus scanning for uploaded files. Never execute or serve uploaded files directly.
• Medium · Potential Path Traversal in Model/Data Loading — Various model.py files across deploying_service and pytorch_classification directories. Multiple scripts load models and data from file paths that could potentially be user-controlled without proper validation (e.g., model.py files, data loading utilities). This could allow attackers to read arbitrary files or load malicious models. Fix: Implement strict path validation using os.path.abspath() and os.path.commonpath() to ensure paths don't escape intended directories. Use allowlists for model and data file locations. Never load files from user input without validation.
• Medium · Missing Input Validation in Image Processing — Various prediction and inference scripts across the codebase. Image processing scripts may not validate input image properties (dimensions, format, color space) before processing, potentially causing DoS through malformed images or resource exhaustion. Fix: Validate image dimensions, format, and file size before processing. Implement resource limits (timeout, memory limits). Use try-catch blocks for image loading operations. Reject suspicious image properties.
• Medium · Hardcoded Model Paths and Configurations — Various main.py and model.py files, class_indices.json references. Multiple scripts likely contain hardcoded model paths, class indices files, and configuration values. This reduces security through obscurity and makes the code inflexible for secure deployment. Fix: Use environment variables or secure configuration management for all paths and settings. Never hardcode sensitive configurations. Use Python-dotenv or similar for configuration management. Implement secure defaults.
• Medium · Potential Serialization Attack Vector — Model loading functions across model.py files. The codebase uses pickle/torch model loading without validation (e.g., torch.load()). Pickle is known to be unsafe with untrusted data and can lead to arbitrary code execution. Fix: Use torch.load() with weights_only=True parameter (PyTorch 1.13+). Never load model files from untrusted sources. Validate model checksums using cryptographic hashes (SHA-256). Consider using ONNX format for model distribution instead of pickle-based formats.
• Low · Missing Error Handling and Information Disclosure — undefined. Lack of proper error handling could leak sensitive Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/WZMIAOMIAO/deep-learning-for-image-processing shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live WZMIAOMIAO/deep-learning-for-image-processing repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/WZMIAOMIAO/deep-learning-for-image-processing.

What it runs against: a local clone of WZMIAOMIAO/deep-learning-for-image-processing — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in WZMIAOMIAO/deep-learning-for-image-processing | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 158 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of WZMIAOMIAO/deep-learning-for-image-processing. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/WZMIAOMIAO/deep-learning-for-image-processing.git
#   cd deep-learning-for-image-processing
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of WZMIAOMIAO/deep-learning-for-image-processing and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "WZMIAOMIAO/deep-learning-for-image-processing(\\.git)?\\b" \\
  && ok "origin remote is WZMIAOMIAO/deep-learning-for-image-processing" \\
  || miss "origin remote is not WZMIAOMIAO/deep-learning-for-image-processing (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "pytorch_classification/ConvNeXt/train.py" \\
  && ok "pytorch_classification/ConvNeXt/train.py" \\
  || miss "missing critical file: pytorch_classification/ConvNeXt/train.py"
test -f "pytorch_classification/ConvNeXt/model.py" \\
  && ok "pytorch_classification/ConvNeXt/model.py" \\
  || miss "missing critical file: pytorch_classification/ConvNeXt/model.py"
test -f "deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/convert_pytorch2onnx.py" \\
  && ok "deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/convert_pytorch2onnx.py" \\
  || miss "missing critical file: deploying_service/deploying_pytorch/convert_openvino/convert_resnet34/convert_pytorch2onnx.py"
test -f "deploying_service/deploying_pytorch/pytorch_flask_service/main.py" \\
  && ok "deploying_service/deploying_pytorch/pytorch_flask_service/main.py" \\
  || miss "missing critical file: deploying_service/deploying_pytorch/pytorch_flask_service/main.py"
test -f "pytorch_classification/ConvNeXt/my_dataset.py" \\
  && ok "pytorch_classification/ConvNeXt/my_dataset.py" \\
  || miss "missing critical file: pytorch_classification/ConvNeXt/my_dataset.py"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 158 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~128d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/WZMIAOMIAO/deep-learning-for-image-processing"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.