CI : Génération d'image
Dans ce TP2, vous allez manipuler un modèle de diffusion en inférence (pas d’entraînement) pour générer et modifier des images dans un contexte “produit e-commerce”. L’objectif est de comprendre, par l’expérimentation, comment les paramètres (seed, nombre d’étapes, guidance/CFG, scheduler, strength, etc.) influencent la qualité, la diversité et la fidélité au prompt, et comment transformer cette compréhension en un mini-outil utilisable.
Vous travaillerez dans le même dépôt que le TP1, en créant un dossier TP2/. L’exécution est recommandée sur le cluster SLURM (GPU 11GB) avec port forwarding pour Streamlit, mais une exécution locale reste possible (plus lente). Les livrables doivent rester légers : évitez de committer des fichiers volumineux (modèles, gros outputs) et privilégiez des captures d’écran dans rapport.md.
- Charger et exécuter un pipeline de diffusion (text-to-image, image-to-image) avec Hugging Face Diffusers, en exploitant le GPU quand disponible.
- Rendre une génération reproductible (seed, configuration) et documenter précisément les paramètres utilisés.
- Explorer systématiquement l’impact des paramètres clés : num_inference_steps, guidance_scale, scheduler, et strength (img2img).
- Construire un mini-produit Streamlit orienté e-commerce, permettant text2img et img2img avec paramètres configurables.
- Produire un rapport Markdown pragmatique (captures, commandes, observations, courte réflexion) sans livrer de fichiers trop volumineux.
Mise en place & smoke test (GPU + Diffusers)
L’exécution est recommandée sur le cluster SLURM (GPU 11GB). Faites l’installation des dépendances après avoir obtenu une allocation GPU. En local, cela fonctionne aussi mais la génération sera nettement plus lente.
Dans TP2/, installez (ou mettez à jour) les dépendances nécessaires dans l’environnement Python que vous utilisez déjà. Vous n’avez pas besoin de documenter cette étape dans le rapport.
Dépendances minimales : diffusers, transformers, accelerate, safetensors, torch, pillow.
Réalisez un smoke test sur GPU en générant une seule image (512×512) avec Stable Diffusion v1.5 via un script Python. Créez un fichier TP2/smoke_test.py avec le contenu ci-dessous, puis exécutez-le.
Si vous êtes sur le cluster : exécutez ce script sur le nœud GPU. Le premier lancement télécharge le modèle (temps variable).
Si le smoke test échoue (OOM, erreurs CUDA, etc.), appliquez au moins une des actions ci-dessous, puis relancez le script jusqu’à obtenir une image. Documentez uniquement le diagnostic utile (pas les commandes triviales).
- Réduire num_inference_steps (ex: 15–20).
- Vérifier que torch_dtype est bien en float16 sur GPU.
- Activer pipe.enable_attention_slicing() (déjà fait ici).
- Fermer d’autres jobs/process GPU, si applicable.
À mettre dans le rapport pour cet exercice : une capture (ou export léger) de l’image smoke.png et, si vous avez eu un souci, une phrase sur la cause et le correctif (ex: “OOM résolu en passant de 50 à 20 steps”).
Factoriser le chargement du pipeline (text2img/img2img) et exposer les paramètres
Pour garder le TP simple et reproductible, on va centraliser le chargement du modèle et la gestion des paramètres (device/dtype, scheduler, seed) dans un module utilitaire. Cela évite de “copier-coller” du code partout et facilite le debug.
Créez le fichier TP2/pipeline_utils.py et complétez les trous (_______) pour obtenir :
- un chargement text2img (StableDiffusionPipeline) avec choix du scheduler,
- un chargement img2img qui réutilise les composants du pipeline text2img,
- un générateur reproductible basé sur la seed.
Modèles suggérés (sans authentification) :
- stable-diffusion-v1-5/stable-diffusion-v1-5 (512×512, bon compromis)
- sd2-community/stable-diffusion-2-1-base (512×512, alternative SD2.1 “mirror”)
Sur GPU 11GB : commencez en 512×512, fp16 sur CUDA, et gardez enable_attention_slicing().
Créez le fichier TP2/experiments.py (script d’exécution minimal) et complétez les trous pour produire une image text2img “baseline” (512×512) avec des paramètres explicitement définis. Vous devez sauvegarder l’image dans TP2/outputs/.
Ce script sera réutilisé ensuite pour lancer vos expériences sans dépendre de Streamlit. Gardez-le volontairement simple : une exécution = une génération = un fichier image.
À mettre dans le rapport pour cet exercice : une capture de baseline.png + la configuration affichée (model_id, scheduler, seed, steps, guidance). Ne mettez pas de détails trivials.
Text2Img : 6 expériences contrôlées (paramètres steps, guidance, scheduler)
Dans cet exercice, vous allez mener des expériences contrôlées : on change un seul paramètre à la fois, on conserve le même prompt et la même seed, et on compare visuellement les résultats. L’objectif est de comprendre l’effet des paramètres num_inference_steps, guidance_scale et scheduler.
Dans TP2/experiments.py, ajoutez une fonction run_text2img_experiments() qui génère automatiquement 6 images (512×512) selon le plan ci-dessous, et les sauvegarde dans TP2/outputs/.
Plan imposé (même prompt, même seed) :
- Run 01 : baseline — steps=30, guidance=7.5, scheduler=EulerA
- Run 02 : steps bas — steps=15
- Run 03 : steps haut — steps=50
- Run 04 : guidance bas — guidance=4.0
- Run 05 : guidance haut — guidance=12.0
- Run 06 : scheduler différent — scheduler=DDIM (steps=30, guidance=7.5)
- Gardez une convention de nommage claire, par exemple t2i_run01_baseline.png, etc.
- Affichez dans le terminal (print) la configuration de chaque run (au moins : scheduler/seed/steps/guidance).
- Ne changez pas la seed entre les runs (sinon l’analyse est biaisée).
Exécutez TP2/experiments.py de façon à lancer ces 6 générations. Vous devez obtenir 6 fichiers outputs/t2i_*.png.
Si vous avez déjà une fonction main(), appelez run_text2img_experiments() depuis main(). Ne créez pas de nouveau script complet.
Faites une comparaison qualitative des 6 résultats (sans métrique). Dans votre rapport.md, produisez :
- une grille de captures (ou 6 captures séparées) montrant les résultats,
- un court commentaire (bullet points) décrivant l’effet de steps, guidance et scheduler.
Exemple d’axes d’analyse : netteté, artefacts (mains/texte/logos), respect du prompt, diversité de composition, lumière/ombres.
Img2Img : 3 expériences contrôlées (strength faible/moyen/élevé)
L’objectif ici est de comprendre le paramètre strength en image-to-image : plus strength est élevé, plus le modèle s’éloigne de l’image d’entrée (créativité augmente, fidélité structurelle diminue).
Dans TP2/experiments.py, ajoutez une fonction run_img2img_experiments() et complétez les trous pour générer 3 images à partir d’une image source (à fournir par vous). L’image source doit être une image “produit e-commerce” (photo personnelle ou trouvée sur internet).
- Placez votre image source dans TP2/inputs/ (ne pas committer si trop lourde ; sinon préférez une image légère).
- Conservez la même seed, le même scheduler, le même steps et le même guidance entre les 3 runs.
- Utilisez le même prompt pour les 3 runs.
Exécutez vos 3 générations Img2Img (les runs 07–09) et obtenez les fichiers outputs/i2i_*.png. Assurez-vous d’avoir aussi une capture “avant” (image source) pour la comparaison.
Si vous avez déjà une fonction main(), appelez run_img2img_experiments() depuis main().
Dans rapport.md, comparez qualitativement les résultats pour strength=0.35, 0.60 et 0.85 (captures + bullet points). Votre analyse doit inclure :
- ce qui est conservé (forme globale, identité du produit, cadrage),
- ce qui change (textures, arrière-plan, éclairage, détails),
- un commentaire sur l’utilisabilité e-commerce (risque “trop loin” à strength élevé).
Pour les livrables : ne committez pas l’image source si elle est trop lourde. Les captures dans rapport.md suffisent.
Mini-produit Streamlit (MVP) : Text2Img + Img2Img avec paramètres
Objectif : assembler un mini-outil “e-commerce” minimal mais utilisable. Vous devez pouvoir (i) générer en text2img, (ii) transformer une image en img2img, (iii) piloter les paramètres (seed/steps/guidance/scheduler/strength), et (iv) afficher la configuration utilisée pour la reproductibilité.
Créez (ou complétez) TP2/app.py en ajoutant un bloc “imports + chargement caché (cache)” ci-dessous. Complétez les trous (_______).
- Le cache Streamlit évite de re-télécharger / re-charger le modèle à chaque interaction.
- Le pipeline doit être rechargé si model_id ou scheduler_name changent.
Ajoutez maintenant un bloc “UI” (sidebar + zones de texte) qui permet de sélectionner :
- le mode (Text2Img / Img2Img),
- les paramètres : seed, steps, guidance, scheduler,
- le prompt et le negative_prompt,
- pour Img2Img : upload de l’image + strength.
Ajoutez le bloc “génération” : au clic sur Generate, exécutez soit text2img soit img2img, affichez l’image de sortie et affichez la configuration (paramètres) sous forme lisible. Complétez les trous.
- Pour la reproductibilité : recréez le générateur (make_generator) à chaque génération (seed fixe).
- Si Img2Img est sélectionné, refusez de générer si aucune image n’est uploadée.
À mettre dans le rapport pour cet exercice : deux captures de l’application (une en Text2Img, une en Img2Img) montrant l’image générée et le bloc Config affiché.
Évaluation (léger) + réflexion (à finir à la maison)
La génération d’images n’a pas de “bonne réponse unique”. L’objectif ici est de définir une évaluation simple, répétable, et utile en contexte e-commerce, puis de prendre du recul sur les limites et risques. Pour garder l’implémentation Streamlit minimale (et éviter des changements importants liés au rechargement de l’UI), l’évaluation sera faite dans le rapport, sans code.
Dans rapport.md, définissez et utilisez la grille d’évaluation “light” suivante (scores entiers 0–2), puis calculez un total sur 10.
- Prompt adherence (0–2)
- Visual realism (0–2)
- Artifacts (0–2) — 2 = aucun artefact gênant
- E-commerce usability (0–2) — 2 = publiable après retouches mineures
- Reproducibility (0–2) — 2 = paramètres suffisants pour reproduire
Cette évaluation est humaine. Elle sert surtout à structurer votre analyse et à comparer des runs. Vous n’avez pas besoin d’un tableau sophistiqué : des bullet points avec le calcul du total suffisent.
Évaluez au moins 3 images parmi vos générations :
- une text2img baseline,
- une text2img avec un paramètre “extrême” (guidance haut ou steps bas/haut),
- une img2img à strength élevé.
Rédigez un paragraphe de réflexion (8–12 lignes) à la fin de rapport.md. Il doit obligatoirement couvrir les 3 points suivants :
- Le compromis quality vs latency/cost quand on ajuste steps/scheduler.
- La reproductibilité : quels paramètres sont nécessaires et ce qui peut casser.
- Les risques en e-commerce : hallucinations, images trompeuses, conformité (logos/texte), et ce que vous feriez pour limiter ces risques.
Appuyez-vous sur un exemple concret observé pendant le TP (ex : “à strength=0.85, le produit dérive trop”).
Rappel : évitez de committer des fichiers volumineux. Les captures d’écran dans rapport.md suffisent.