Spaces:
Sleeping
Guide Complet — Projet 8 : Déploiement d'un Modèle de Segmentation d'Images
Contexte : Tu es ingénieur IA chez Future Vision Transport. Tu conçois le module de segmentation d'images dans une chaîne de vision embarquée pour véhicules autonomes. Le dataset est Cityscapes, le framework imposé est Keras, et tu dois livrer un modèle + API + application web déployés sur le Cloud.
Phase 0 — Mise en place de l'environnement
0.1 Créer un environnement virtuel Python dédié
python -m venv venv_projet8
source venv_projet8/bin/activate
pip install tensorflow keras numpy pandas matplotlib opencv-python albumentations flask fastapi uvicorn streamlit
- Why : Isoler les dépendances évite les conflits entre projets. C'est une pratique professionnelle standard.
- Notions : virtual environments, gestion de dépendances avec
pip,requirements.txt.
0.2 Structurer le répertoire de travail
Projet_8/
├── data/ # Données Cityscapes (déjà présent)
├── notebooks/ # Notebooks d'exploration et d'entraînement
├── src/ # Code source réutilisable (data generator, model, utils)
├── api/ # Code de l'API Flask/FastAPI
├── app/ # Code de l'application web Streamlit/Flask
├── models/ # Modèles sauvegardés (.h5, .keras)
├── docs/ # Note technique + supports de présentation
└── requirements.txt
- Why : Une structure claire rend le projet "industrialisable" (critère évalué dans les livrables) et facilite la collaboration.
- Notions : project scaffolding, bonnes pratiques d'organisation de projets ML.
0.3 Initialiser un dépôt Git
git init
echo "venv_projet8/\ndata/\nmodels/*.h5\n__pycache__/" > .gitignore
- Why : Le versionnement est indispensable pour tracer l'évolution du code, revenir en arrière, et montrer ta démarche.
- Notions : Git, versionnement,
.gitignore.
Phase 1 — Comprendre les données Cityscapes
1.1 Télécharger le jeu de données complet
Observation : Ton dossier data/ contient actuellement uniquement les annotations gtFine (masks de segmentation), pas les images brutes. Tu dois télécharger les images
leftImg8bitdepuis cityscapes-dataset.com.
- Why : Ton modèle prend en entrée les images caméra (leftImg8bit) et doit prédire les masks de segmentation (gtFine). Sans les images, tu ne peux pas entraîner.
- Notions : supervised learning, notion d'images d'entrée vs. ground truth / labels.
1.2 Comprendre la structure des fichiers
Pour chaque image, Cityscapes fournit :
| Fichier | Description |
|---|---|
*_leftImg8bit.png |
Image caméra brute (1024×2048) |
*_gtFine_labelIds.png |
Mask avec label ID par pixel (0-33) |
*_gtFine_color.png |
Mask coloré (visualisation) |
*_gtFine_instanceIds.png |
Mask d'instances |
*_gtFine_polygons.json |
Annotations polygonales |
- Why : Comprendre ce que chaque fichier représente est crucial avant de construire ton pipeline de données. Tu utiliseras principalement
leftImg8bit+labelIds. - Notions : semantic segmentation, instance segmentation, label maps, correspondance pixel-classe.
1.3 Comprendre les 8 catégories principales vs les 32 sous-catégories
Le projet demande de travailler avec les 8 catégories principales :
| ID Cat. | Catégorie | Sous-catégories incluses |
|---|---|---|
| 0 | void | unlabeled, ego vehicle, rectification border, out of roi, static, dynamic |
| 1 | flat | road, sidewalk, parking, rail track |
| 2 | construction | building, wall, fence, guard rail, bridge, tunnel |
| 3 | object | pole, polegroup, traffic light, traffic sign |
| 4 | nature | vegetation, terrain |
| 5 | sky | sky |
| 6 | human | person, rider |
| 7 | vehicle | car, truck, bus, caravan, trailer, train, motorcycle, bicycle |
- Why : C'est une contrainte explicite du projet (Franck). Tu dois mapper les 32 sous-catégories vers ces 8. Cela simplifie le problème et rend le modèle plus robuste.
- Notions : label remapping, category grouping, dictionnaire de correspondance Cityscapes.
1.4 Explorer visuellement les données (EDA)
Dans un notebook, afficher côte à côte :
L'image brute
Le mask coloré (
gtFine_color)Le mask labelIds remappé vers les 8 catégories
Distribution des classes par image (histogrammes)
Why : L'EDA permet de détecter le class imbalance (par exemple, "road" et "building" dominent, "rider" est rare). Cela guidera tes choix d'augmentation de données et de loss function.
Notions : Exploratory Data Analysis, class imbalance, visualisation de masks de segmentation,
matplotlib.imshow().
Phase 2 — État de l'Art et Recherche Bibliographique
2.1 Étudier les architectures de segmentation sémantique
Architectures incontournables à comprendre et comparer :
| Architecture | Principe clé | Avantage |
|---|---|---|
| FCN (Fully Convolutional Network) | Remplace les couches FC par des convolutions | Premier modèle end-to-end pour la segmentation |
| U-Net | Encoder-decoder avec skip connections | Excellent pour les détails fins, idéal pour les données limitées |
| SegNet | Encoder-decoder avec pooling indices | Plus léger en mémoire que U-Net |
| DeepLab v3+ | Atrous convolutions + ASPP + encoder-decoder | State-of-the-art, capture multi-échelle |
| PSPNet | Pyramid Pooling Module | Capture le contexte global |
- Why : La note technique demande une "présentation des différentes approches et une synthèse de l'état de l'art". Tu dois comprendre les forces/faiblesses de chaque architecture pour justifier ton choix.
- Notions : encoder-decoder architecture, skip connections, atrous/dilated convolutions, feature pyramid, receptive field.
2.2 Étudier les métriques de segmentation
| Métrique | Formule/Description |
|---|---|
| Pixel Accuracy | % de pixels correctement classifiés |
| Mean IoU (mIoU) | Intersection over Union moyenné sur toutes les classes |
| Dice Coefficient | 2×TP / (2×TP + FP + FN) |
| Per-class IoU | IoU calculé pour chaque classe individuellement |
- Why : Le pixel accuracy est trompeur sur des données déséquilibrées. Le mIoU est la métrique standard en segmentation sémantique et sera celle que l'évaluateur attend.
- Notions : IoU (Intersection over Union), Dice score, confusion matrix pixel-level, mean IoU.
2.3 Étudier les loss functions adaptées
Categorical Cross-Entropy : Standard, mais sensible au class imbalance
Weighted Cross-Entropy : Pondération inversement proportionnelle à la fréquence de la classe
Dice Loss : Optimise directement le Dice Coefficient
Focal Loss : Réduit la contribution des exemples bien classifiés
Combinaison : Dice Loss + Cross-Entropy souvent utilisée en pratique
Why : Le choix de la loss function a un impact direct sur les performances, surtout avec des classes déséquilibrées (road vs rider).
Notions : loss functions, class weighting, focal loss, dice loss.
Phase 3 — Pipeline de Données
3.1 Créer un Data Generator Keras
class CityscapesGenerator(tf.keras.utils.Sequence):
def __init__(self, image_paths, mask_paths, batch_size, img_size, augment=False):
...
def __getitem__(self, idx):
# Charge batch d'images + masks
# Remapping 32 → 8 catégories
# Resize
# Augmentation (si train)
# One-hot encoding du mask
...
- Why : Les images Cityscapes (1024×2048) sont trop volumineuses pour tout charger en RAM. Un generator charge les données par batch à la volée. C'est un critère du livrable ("caractère industrialisable").
- Notions :
tf.keras.utils.Sequence, batch loading, lazy loading, one-hot encoding de masks, yield vs return.
3.2 Implémenter le label remapping (32 → 8 catégories)
# Dictionnaire de mapping utilisant la documentation Cityscapes
LABEL_TO_CATEGORY = {
0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, # void
7: 1, 8: 1, 9: 1, 10: 1, # flat
11: 2, 12: 2, 13: 2, 14: 2, 15: 2, 16: 2, # construction
17: 3, 18: 3, 19: 3, 20: 3, # object
21: 4, 22: 4, # nature
23: 5, # sky
24: 6, 25: 6, # human
26: 7, 27: 7, 28: 7, 29: 7, 30: 7, 31: 7, 32: 7, 33: 7 # vehicle
}
- Why : Franck (le collègue en charge du traitement d'images) a spécifié que seules les 8 catégories principales sont nécessaires. Ce remapping doit être fait dans le pipeline de données, pas manuellement.
- Notions : label encoding, numpy vectorized mapping (
np.vectorizeou table de lookup), correspondance Cityscapes.
3.3 Implémenter l'augmentation de données
Techniques à appliquer :
- Flip horizontal (le plus commun pour la conduite)
- Rotation légère (±10°)
- Variations de luminosité/contraste
- Random crop + resize
- Ajout de bruit gaussien
L'augmentation doit être appliquée identiquement à l'image ET au mask !
- Why : Le livrable demande explicitement des "gains obtenus avec les approches d'augmentation des données". L'augmentation permet de régulariser le modèle et d'augmenter virtuellement la taille du dataset.
- Notions : data augmentation, bibliothèque
albumentations(applique les mêmes transformations géométriques à l'image et au mask), overfitting prevention.
3.4 Gérer le redimensionnement des images
Réduire les images de 1024×2048 à une taille gérable :
256×512 : bon compromis vitesse/qualité pour les premiers tests
512×1024 : meilleure résolution si ressources GPU suffisantes
Why : Les images originales sont très grandes. Entraîner en pleine résolution nécessite un GPU puissant (32+ Go VRAM). Le redimensionnement est un compromis nécessaire.
Notions : image resizing, interpolation bilinéaire vs nearest-neighbor (pour les masks !), aspect ratio preservation.
Phase 4 — Entraînement du Modèle
4.1 Commencer avec un modèle simple (baseline)
Entraîner un U-Net simple depuis zéro comme baseline :
Encoder : blocs Conv2D + BatchNorm + ReLU + MaxPool
Decoder : UpSampling2D + Concatenate (skip connections) + Conv2D
Sortie : Conv2D(8, (1,1), activation='softmax')
Why : Un modèle simple permet de valider que tout le pipeline fonctionne (data loading, training loop, évaluation) avant d'investir du temps dans des architectures plus complexes.
Notions : U-Net architecture, encoder-decoder, skip connections, softmax pour classification multi-classe pixel-level.
4.2 Utiliser le Transfer Learning
Utiliser un backbone pré-entraîné sur ImageNet :
- MobileNetV2 : léger, idéal pour l'embarqué
- ResNet50 : bon compromis performance/poids
- EfficientNet : état de l'art en efficacité
base_model = tf.keras.applications.MobileNetV2(input_shape=(256, 512, 3), include_top=False, weights='imagenet')
- Why : Le transfer learning permet d'obtenir de bien meilleures performances avec moins de données et moins de temps d'entraînement. Les features bas-niveau (contours, textures) apprises sur ImageNet sont transférables.
- Notions : transfer learning, feature extraction vs fine-tuning, backbone freezing/unfreezing,
keras.applications.
4.3 Implémenter un modèle avancé (DeepLab v3+ ou similaire)
Options :
Utiliser
segmentation_modelslibrary :pip install segmentation-modelsImplémenter DeepLab v3+ manuellement avec Keras
Utiliser TensorFlow Hub pour charger un modèle pré-entraîné
Why : La comparaison entre un modèle simple (baseline) et un modèle avancé est attendue dans la note technique. DeepLab v3+ est souvent le meilleur choix pour Cityscapes.
Notions : ASPP (Atrous Spatial Pyramid Pooling), dilated convolutions, multi-scale feature extraction.
4.4 Configurer l'entraînement
model.compile(
optimizer=tf.keras.optimizers.Adam(learning_rate=1e-4),
loss='categorical_crossentropy', # ou dice_loss + CE combinée
metrics=['accuracy', MeanIoU(num_classes=8)]
)
callbacks = [
tf.keras.callbacks.ModelCheckpoint('best_model.keras', save_best_only=True, monitor='val_mean_iou', mode='max'),
tf.keras.callbacks.EarlyStopping(patience=10, monitor='val_mean_iou', mode='max'),
tf.keras.callbacks.ReduceLROnPlateau(factor=0.5, patience=5),
tf.keras.callbacks.TensorBoard(log_dir='./logs')
]
- Why : Les callbacks automatisent la sauvegarde du meilleur modèle, l'arrêt précoce (évite l'overfitting), et l'ajustement du learning rate. C'est une démarche professionnelle.
- Notions : callbacks Keras, early stopping, learning rate scheduling, model checkpointing, TensorBoard.
4.5 Entraîner et comparer les modèles
Pour chaque modèle, documenter :
Architecture utilisée
Hyperparamètres (lr, batch size, epochs, augmentation)
Courbes train/val loss et mIoU
Per-class IoU sur le validation set
Prédictions visuelles (image / ground truth / prédiction)
Why : La soutenance demande la "comparaison des modèles" (10 min dédiées). Tu dois montrer une démarche itérative et justifier le modèle final retenu.
Notions : hyperparameter tuning, learning curves analysis, overfitting vs underfitting diagnosis, model selection.
4.6 Évaluer sur le jeu de test
Calculer les métriques finales sur le test set (Berlin, Bielefeld, Bonn, Leverkusen, Mainz, Munich) :
mIoU global
IoU par classe
Matrice de confusion pixel-level
Visualisations qualitatives
Why : L'évaluation sur le test set (jamais vu pendant l'entraînement) donne une estimation non biaisée des performances. C'est la norme en ML.
Notions : train/val/test split, generalization, qualitative vs quantitative evaluation.
Phase 5 — Développement de l'API de Prédiction
5.1 Choisir entre Flask et FastAPI
| Critère | Flask | FastAPI |
|---|---|---|
| Facilité | Plus simple | Async concepts |
| Performance | Synchrone | Asynchrone natif |
| Documentation auto | Swagger/OpenAPI inclus | |
| Typing | Pydantic intégré |
Recommandation : FastAPI — la doc auto est un vrai plus pour Laura et la soutenance.
- Why : Laura veut une "API simple à utiliser". FastAPI génère automatiquement une documentation interactive (Swagger UI) qui permet de tester l'API sans code client.
- Notions : REST API, endpoints, HTTP methods (POST), content types (multipart/form-data, JSON).
5.2 Concevoir l'endpoint de prédiction
from fastapi import FastAPI, File, UploadFile
import numpy as np
from PIL import Image
import io
app = FastAPI(title="Cityscapes Segmentation API")
# Charger le modèle au démarrage
model = tf.keras.models.load_model('best_model.keras')
@app.post("/predict")
async def predict(file: UploadFile = File(...)):
# 1. Lire l'image uploadée
image = Image.open(io.BytesIO(await file.read()))
# 2. Prétraiter (resize, normalisation)
# 3. Prédire le mask
# 4. Post-traiter (argmax, resize au format original)
# 5. Retourner le mask (encodé en base64 ou en JSON)
return {"mask": mask_as_list, "classes": class_names}
- Why : Cet endpoint est le cœur du livrable 2. Il prend une image et retourne le mask prédit. Il sera consommé par l'application web (livrable 3).
- Notions : API endpoint design, image I/O (bytes → PIL → numpy), model inference pipeline, base64 encoding.
5.3 Ajouter des endpoints utilitaires
GET /: Infos sur l'API (version, modèle utilisé, classes)GET /health: Health checkGET /classes: Liste des 8 catégories et leurs couleursWhy : Des endpoints d'information facilitent l'intégration et le monitoring. C'est une bonne pratique d'architecture API.
Notions : API design patterns, health checks, API versioning.
5.4 Tester l'API en local
uvicorn api.main:app --reload --host 0.0.0.0 --port 8000
# Tester sur http://localhost:8000/docs (Swagger UI)
- Why : Toujours tester en local avant de déployer. La Swagger UI permet de tester visuellement l'upload d'image et la réponse.
- Notions : local development server, API testing, Swagger/OpenAPI.
Phase 6 — Développement de l'Application Web
6.1 Concevoir l'application Streamlit (ou Flask)
L'application doit permettre :
- Afficher la liste des IDs des images disponibles (test set)
- Sélectionner un ID → lancer la prédiction via l'API
- Afficher 3 images côte à côte : image réelle | mask réel | mask prédit
import streamlit as st
import requests
st.title("Segmentation d'Images - Future Vision Transport")
# Liste des images disponibles
image_ids = get_available_image_ids()
selected_id = st.selectbox("Sélectionner une image :", image_ids)
if st.button("Lancer la prédiction"):
# Appel à l'API
response = requests.post(API_URL + "/predict", files={"file": image_bytes})
predicted_mask = decode_response(response.json())
col1, col2, col3 = st.columns(3)
col1.image(original_image, caption="Image réelle")
col2.image(ground_truth_mask, caption="Mask réel")
col3.image(predicted_mask, caption="Mask prédit")
- Why : Cette application est l'interface de démonstration (livrable 3). Elle doit consommer l'API, pas faire la prédiction directement — cela prouve que l'architecture est bien découplée.
- Notions : Streamlit, API consumption (
requests), image display, UI/UX pour une démo, client-server architecture.
6.2 Ajouter des fonctionnalités bonus
Palette de couleurs pour les classes (légende)
Overlay du mask sur l'image originale (transparence)
Métriques affichées (IoU par classe vs ground truth)
Upload d'une image personnelle (pas du dataset)
Why : Ces fonctionnalités impressionnent l'évaluateur et montrent une maîtrise au-delà du minimum requis.
Notions : image compositing, alpha blending, color mapping.
Phase 7 — Déploiement sur le Cloud
7.1 Choisir une plateforme Cloud
| Plateforme | Coût | Difficulté | GPU |
|---|---|---|---|
| Render | Gratuit (limité) | ⭐⭐ | |
| Railway | Gratuit ($5 crédit) | ⭐⭐ | |
| Azure Web App | Free tier disponible | ⭐⭐⭐ | Option payante |
| Google Cloud Run | Free tier généreux | ⭐⭐⭐ | |
| PythonAnywhere | Gratuit (très limité) | ⭐ | |
| AWS (EC2/Lambda) | Free tier 12 mois | ⭐⭐⭐⭐ | Option payante |
- Why : Le déploiement Cloud est obligatoire pour la soutenance. Tu dois faire une démo en live et l'enregistrer. Choisis en fonction de ton budget et de ta familiarité.
- Notions : cloud deployment, PaaS vs IaaS, containerization concepts.
7.2 Containeriser avec Docker
# API
FROM python:3.10-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
- Why : Docker garantit que l'environnement est identique en local et en production. La plupart des plateformes Cloud supportent Docker nativement.
- Notions : Docker, Dockerfile, containers vs VMs, image build, port mapping.
7.3 Déployer l'API et l'application
Deux déploiements séparés :
- API : déploiement du service de prédiction
- App web : déploiement de l'interface Streamlit (pointe vers l'URL de l'API)
- Why : Séparer l'API de l'application web est une architecture microservices. Cela prouve la modularité de ton système.
- Notions : microservices architecture, environment variables pour l'URL de l'API, CORS configuration.
7.4 Enregistrer la démo pendant la soutenance
Important : Le sujet précise que l'évaluateur et l'étudiant doivent enregistrer la démo pendant la soutenance pour que le jury puisse la visionner. Tu pourras ensuite couper le service Cloud pour éviter les coûts.
- Why : C'est une exigence explicite du sujet. Prépare un outil d'enregistrement d'écran (OBS, QuickTime, etc.).
- Notions : screen recording, préparation de démo.
Phase 8 — Rédaction de la Note Technique (~10 pages)
8.1 Structure recommandée
| Section | Contenu | ~Pages |
|---|---|---|
| 1. Introduction | Contexte (Future Vision Transport), objectifs, contraintes | 1 |
| 2. État de l'Art | Revue des architectures (FCN, U-Net, SegNet, DeepLab), métriques | 2 |
| 3. Dataset et Préparation | Cityscapes, 8 catégories, EDA, augmentation | 1.5 |
| 4. Modèle Retenu | Architecture détaillée, hyperparamètres, justification du choix | 2 |
| 5. Résultats | Comparaison des modèles, mIoU, courbes, gains de l'augmentation | 2 |
| 6. Mise en Production | Architecture API + App, déploiement Cloud | 1 |
| 7. Conclusion | Bilan, limites, pistes d'amélioration | 0.5 |
- Why : La note technique est un livrable clé (livrable 4). Elle doit démontrer ta rigueur scientifique et ta capacité à synthétiser.
- Notions : technical writing, scientific methodology, results presentation.
8.2 Points clés à inclure
Comparaison explicite des modèles (tableau mIoU)
Gains de l'augmentation : comparer modèle sans augmentation vs avec
Visualisations : courbes de loss, exemples de prédictions, matrice de confusion
Pistes d'amélioration : Real-time inference, quantization, pruning, TensorRT
Why : Ces éléments sont explicitement demandés dans le descriptif des livrables.
Notions : ablation study, model comparison, scientific rigor.
Phase 9 — Support de Présentation (max 30 slides)
9.1 Structure calquée sur le timing de soutenance
| Bloc | Durée | Slides | Contenu |
|---|---|---|---|
| Contexte & Objectifs | 5 min | 5-7 | Entreprise, chaîne de vision, ton rôle, métriques |
| Modèles & Résultats | 10 min | 12-15 | Architectures, comparaisons, visualisations, augmentation |
| Mise en Production | 5 min | 5-8 | Architecture API/App, déploiement, démo live |
- Why : La soutenance est strictement chronométrée (20 min ±5). Une présentation trop courte (<15 min) ou trop longue (>25 min) peut être refusée.
- Notions : presentation skills, storytelling technique, demo preparation.
9.2 Préparer la démo live
Préparer un script de démo :
- Ouvrir l'application web déployée
- Sélectionner une image du test set
- Lancer la prédiction
- Montrer image / mask réel / mask prédit côte à côte
- Éventuellement tester avec une image uploadée
Tester la démo plusieurs fois avant la soutenance !
- Why : La démo est le moment fort de la soutenance. Un bug en live est très pénalisant. Prépare aussi des screenshots de backup au cas où le Cloud tombe.
- Notions : demo rehearsal, fallback plan.
Checklist des Livrables
| # | Livrable | Format | Nommage |
|---|---|---|---|
| 1 | Scripts/Notebooks (pipeline complet) | .ipynb / .py |
Nom_Prénom_1_scripts_mmaaaa |
| 2 | API de prédiction (déployée sur le Cloud) | Flask/FastAPI | Nom_Prénom_2_API_mmaaaa |
| 3 | Application web (déployée sur le Cloud) | Streamlit/Flask | Nom_Prénom_3_application_Flask_mmaaaa |
| 4 | Note technique (~10 pages) | Nom_Prénom_4_note_technique_mmaaaa |
|
| 5 | Présentation (max 30 slides) | PPTX/PDF | Nom_Prénom_5_presentation_mmaaaa |
Tout doit être dans un zip nommé
Titre_du_projet_nom_prénom.
Notions Clés à Maîtriser (Résumé)
| Domaine | Notions |
|---|---|
| Computer Vision | Semantic segmentation, encoder-decoder, skip connections, dilated convolutions |
| Deep Learning | Transfer learning, data augmentation, loss functions (Dice, Focal, CE), callbacks |
| Keras/TensorFlow | tf.keras.utils.Sequence, keras.applications, custom training loops, MeanIoU |
| MLOps | Docker, API REST, déploiement Cloud, CI/CD basique |
| Data Engineering | Data generators, label remapping, preprocessing pipelines |
| Évaluation | mIoU, Dice, pixel accuracy, confusion matrix, per-class metrics |
| Communication | Note technique, présentation de résultats, démo live |