Votre raisonnement sur la segmentation cellule par cellule est scientifiquement cohérent. Pour les défauts que vous ciblez — encrassement/poussière, fientes d’oiseaux, délamination visible et éventuellement dommages physiques visibles — je ne considérerais pas la segmentation des cellules individuelles comme une étape obligatoire. Je la traiterais comme une hypothèse expérimentale à tester, et je m’attendrais même à ce qu’elle soit inutile, voire défavorable, dans certaines configurations.

Il y a cependant deux points sur lesquels je modifierais votre raisonnement initial : l’homographie n’est pas absolument obligatoire non plus, et CLAHE n’est pas une normalisation de l’éclairage au sens strict. Les trois traitements doivent idéalement être justifiés par une étude d’ablation.

1. Il faut d’abord distinguer trois niveaux de traitement

Dans votre projet, on peut travailler à trois échelles différentes :

Échelle panneau

« Ce panneau est-il sain, encrassé ou délaminé ? »

C’est typiquement le problème adapté à MobileNetV2 ou YOLOv8n-cls.

Échelle région du défaut

« Où se trouve la fiente ? Où est la zone délaminée ? Où est la cassure ? »

C’est un problème de détection d’objets ou éventuellement de segmentation de défaut, donc YOLOv8n-détection, par exemple.

Échelle cellule

« Quelle cellule précise possède une microfissure, un finger interruption, une zone inactive ou une anomalie EL ? »

C’est là que la segmentation des cellules devient extrêmement pertinente.

Et c’est précisément cette différence d’échelle qui explique votre intuition.

---

2. Pour vos défauts RGB, la cellule n’est généralement pas l’unité naturelle d’analyse

Prenons vos classes une par une.

Encrassement / poussière

La poussière peut couvrir :

• une fraction du module ;
• plusieurs cellules simultanément ;
• presque tout le panneau ;
• des régions qui ne respectent absolument pas les frontières des cellules.

Découper systématiquement un panneau en 60, 72 ou davantage de cellules peut donc transformer un phénomène global en dizaines de petits exemples partiels.

Des travaux sur l’encrassement utilisent justement des images RGB du panneau et localisent les zones affectées sans imposer une segmentation préalable en cellules. DeepSolarEye, par exemple, prend des images RGB de panneaux et effectue notamment une localisation de l’encrassement à partir de l’image du panneau. (arXiv)

Fientes d’oiseaux

C’est encore plus évident.

Une fiente peut :

• occuper une partie d’une cellule ;
• chevaucher deux ou quatre cellules ;
• couvrir un busbar ;
• être beaucoup plus grande qu’une cellule ;
• présenter une forme totalement indépendante de la grille photovoltaïque.

La frontière physique entre cellules n'est donc pas une frontière sémantique pertinente pour le défaut.

Di Tommaso et al. ont justement réalisé une détection sur des images UAV visibles et thermiques avec des anomalies comprenant bird dropping, soiling et delamination, sans que la tâche soit reformulée en classification systématique de cellules individuelles. Leur modèle atteint, pour les anomalies visibles, environ 70 % de [email protected] dans des conditions réelles sur deux grandes installations PV. (ScienceDirect)

C’est une référence particulièrement importante pour votre projet parce que le problème étudié est très proche du vôtre : inspection UAV + images visibles + défauts visibles du panneau.

Délamination visible

Même raisonnement.

Lorsque la délamination est suffisamment prononcée pour être perceptible en RGB, elle peut présenter :

• un changement de couleur ;
• des zones blanchâtres ;
• des bulles ;
• une perte d’adhérence ;
• des motifs étendus sur plusieurs cellules.

Si vous coupez cette zone suivant une grille de cellules, vous risquez de supprimer une partie du contexte spatial global permettant justement de reconnaître qu’il s’agit d’une délamination.

La littérature RGB/UAV montre qu'il est possible de détecter directement la délamination au niveau module/région. (ScienceDirect)

Verre cassé ou dommages physiques

Même chose : une fissure mécanique importante peut traverser plusieurs cellules.

Dans ce cas, découper indépendamment les cellules revient parfois à transformer :

une grande fissure structurelle clairement reconnaissable

en

dix fragments de lignes dont chacun est beaucoup plus ambigu.

C’est l’inverse de ce que vous cherchez.

---

3. Pourquoi la segmentation cellule-par-cellule est tellement utilisée dans les articles EL ?

Parce que le problème physique est différent.

En électroluminescence, les défauts étudiés sont très fréquemment :

• microfissures ;
• cracks ;
• finger interruptions ;
• cellules électriquement isolées ;
• dark areas ;
• busbar anomalies ;
• interconnection failures.

Ces phénomènes sont effectivement attachés à la structure d’une cellule individuelle.

C’est pourquoi des travaux comme celui de Su et al. segmentent d’abord les cellules d’une image EL du module puis effectuent la détection/classification sur chacune d’elles. Leur système extrait des cellules de taille uniforme avant classification et obtient de très bonnes performances sur ce problème EL particulier. (MDPI)

De même, des travaux récents utilisant des dizaines de milliers, voire des millions de cellules EL, construisent explicitement leur problème autour de la cellule parce que les classes étudiées comprennent microcracks, finger defects, interconnection defects, etc. (MDPI)

Et des approches de segmentation beaucoup plus fines localisent directement cracks, dark areas et busbars au niveau pixel dans les images EL. (arXiv)

Donc il faut éviter de tirer cette conclusion :

« La segmentation des cellules améliore la détection des défauts PV. »

La conclusion scientifiquement plus correcte est :

La segmentation des cellules améliore certains problèmes de diagnostic PV lorsque l’unité physique pertinente du défaut est la cellule.

Ce n'est pas la même affirmation.

---

4. Dans votre cas, l'unité sémantique pertinente est plutôt le panneau ou la région du défaut

C’est le point fondamental.

Imaginez :

text
Panneau complet
┌──────────────────────────────────────┐
│ ░░░░░░ poussière ░░░░░░░░░░░░░░░    │
│ ───┬───┬───┬───┬───┬───┬───         │
│    │   ● fiente       │               │
│ ───┼───┼───┼───┼───┼───┼───         │
│       zone délaminée                  │
│ ───┼───┼───┼───┼───┼───┼───         │
└──────────────────────────────────────┘

Si vous découpez suivant la grille :

text
Cellule 1 : un peu de poussière
Cellule 2 : un peu de poussière
Cellule 3 : un bout de fiente
Cellule 4 : un autre bout de fiente
Cellule 5 : moitié d'une délamination
...

Vous avez potentiellement perdu l’information :

« Cette région irrégulière et étendue constitue un même défaut. »

Un CNN ou un détecteur multiscale peut justement exploiter simultanément texture locale + contexte global.

---

5. Et surtout : la littérature RGB montre qu'on peut se passer de cette segmentation

C’est probablement l’argument expérimental le plus fort.

Une étude récente de détection visible utilise un dataset de 6493 images, avec les classes :

• bird_drop
• cracked
• dusty
• panneau normal

annotées par bounding boxes et comparées avec YOLOv5, YOLOv8 et YOLOv11. L'approche traite les anomalies directement sur les panneaux sans introduire une segmentation systématique en cellules comme prérequis. (MDPI)

Un autre travail UAV visible évalue YOLOv3, Faster R-CNN, RetinaNet, EfficientDet et Swin Transformer sur des défauts et contaminants comprenant poussière, saleté et fientes, là encore sous forme de détection d'objets, pas comme classification obligatoire de cellules isolées. (arXiv)

Cela ne prouve pas que la segmentation cellule sera toujours mauvaise. Cela démontre quelque chose de plus important pour votre question :

elle n'est pas une condition nécessaire pour résoudre ce type de problème RGB.

---

6. Votre homographie : oui, mais je ne l'appellerais pas « indispensable »

Votre justification est bonne.

Avec un drone, vous allez avoir :

• yaw ;
• pitch ;
• roll ;
• distance variable ;
• panneau vu en trapèze ;
• variations de taille apparente.

La rectification permet de ramener approximativement le panneau dans un repère canonique :

text
Avant                        Après homographie

    __________
   /         /               ┌─────────────┐
  /         /       →        │             │
 /_________/                 │             │
                             └─────────────┘

Cette idée est bien établie dans l’inspection PV. Des travaux spécifiques ont été consacrés à l’estimation et à la correction de la distorsion perspective des modules photovoltaïques, et d'autres pipelines d'inspection rectifient explicitement le module avant les étapes suivantes. (IEEE Xplore)

Mais je n'irais pas jusqu'à écrire dans votre mémoire :

« L'homographie est indispensable. »

Je dirais plutôt :

La rectification perspective constitue une étape de standardisation géométrique pertinente lorsque la variabilité du point de vue est importante.

Parce qu'un CNN entraîné avec suffisamment de variations géométriques peut apprendre une certaine invariance.

Et l'homographie a également un prix : elle effectue un rééchantillonnage de l'image. Si la transformation est importante ou si les quatre coins sont mal estimés, vous pouvez déformer ou interpoler les détails.

Pour vos défauts relativement macroscopiques, c'est probablement acceptable. Pour une microfissure de quelques pixels, ce serait beaucoup plus problématique.

---

7. CLAHE : ici, je veux corriger une idée importante

CLAHE ne fait pas exactement une normalisation de l'éclairage.

CLAHE signifie :

Contrast Limited Adaptive Histogram Equalization.

Il agit sur le contraste local en divisant l'image en régions et en redistribuant localement les intensités, tout en limitant l'amplification du contraste. C'est justement la variante conçue pour éviter les problèmes d'amplification excessive associés à l'égalisation adaptative classique. (DOI)

Donc :

CLAHE ≠ véritable illumination normalization.

Il peut atténuer certains effets d'éclairage parce qu'il homogénéise localement le contraste, mais son rôle principal est contrast enhancement.

---

8. Et CLAHE n'est pas nécessairement indispensable non plus

Il existe des preuves que CLAHE peut être bénéfique dans l'imagerie PV, particulièrement lorsqu'il existe des défauts faiblement contrastés.

Par exemple, une étude publiée dans Solar Energy utilise CLAHE avant un détecteur EfficientNet-B0 précisément pour rendre les défauts plus distinguables dans des images EL à faible contraste. (ScienceDirect)

Mais remarquez quelque chose :

c'est de l'EL.

Votre cas est RGB extérieur.

C'est beaucoup plus compliqué parce que la couleur elle-même peut contenir de l'information utile :

• brun/blanc pour certaines contaminations ;
• changement de teinte associé à une dégradation ;
• couleur de la poussière ;
• couleur et texture d'une fiente ;
• reflets du verre.

CLAHE pourrait donc aider, mais une transformation trop agressive pourrait également modifier certaines signatures.

Je le conserverais donc comme candidat, pas comme dogme.

---

9. Si vous utilisez CLAHE en RGB, évitez de le faire naïvement sur R, G et B séparément

Une stratégie plus raisonnable est :

text
RGB
 ↓
LAB
 ↓
L ── CLAHE
a ── inchangé
b ── inchangé
 ↓
LAB → RGB

ou éventuellement HSV en travaillant principalement sur la luminance/valeur.

Des travaux appliqués à l'inspection PV ont justement utilisé CLAHE après passage dans un espace permettant de manipuler séparément la luminosité et la chromaticité. (MDPI)

Cela vous permet d'améliorer le contraste sans déformer autant la relation entre les couleurs.

---

10. Pour moi, votre pipeline devrait plutôt être celui-ci

Je proposerais :

text
IMAGE RGB CAMÉRA / DRONE
        │
        ▼
Détection / extraction du panneau
        │
        ▼
Correction perspective
(Homographie)
        │
        ▼
Redimensionnement
        │
        ├───────────────┐
        │               │
        ▼               ▼
 RGB normal          CLAHE léger
 baseline            sur luminance
        │               │
        └──────┬────────┘
               ▼
         MODÈLE IA

et pas :

text
Panneau
   ↓
60 / 72 cellules
   ↓
Classification de chaque cellule

comme pipeline par défaut.

---

11. Pour MobileNetV2, votre formulation est correcte pour la classification

Vous pourriez avoir :

text
Image rectifiée du panneau
         ↓
      MobileNetV2
         ↓
┌───────────────────────┐
│ Sain                  │
│ Encrassé              │
│ Délamination          │
└───────────────────────┘

MobileNetV2 a justement été conçu avec des blocs résiduels inversés, bottlenecks linéaires et convolutions depthwise pour conserver un coût calculatoire réduit, ce qui en fait un candidat logique pour du matériel embarqué. (CVPR Open Access)

Mais cela vous donnera uniquement :

« le panneau est délaminé »

et pas :

« la délamination est à cet endroit précis ».

---

12. Attention au mot « YOLOv8-nano pour la classification »

Il existe une nuance très importante pour votre cahier des charges.

Un modèle de classification attribue une classe à toute l'image. Il ne fournit pas la position du défaut. La documentation officielle Ultralytics définit explicitement la classification comme l'attribution d'une classe et d'un score à l'image entière, sans localisation de l'objet. (Ultralytics Docs)

Donc :

text
YOLOv8n-cls

et

text
YOLOv8n detect

ne remplissent pas exactement la même fonction.

Pour votre objectif initial :

détecter + classifier + localiser

je préférerais nettement expérimenter avec :

text
YOLOv8n detection

et des bounding boxes.

Par exemple :

text
┌─────────────────────────────────────────┐
│                                         │
│      ┌──── bird_dropping ──────┐        │
│      │                         │        │
│      └─────────────────────────┘        │
│                                         │
│ ┌──── delamination ────────────────┐    │
│ │                                  │    │
│ └──────────────────────────────────┘    │
│                                         │
└─────────────────────────────────────────┘

La littérature récente sur les panneaux utilise précisément des détecteurs YOLO légers pour ce type de compromis précision/coût calculatoire. (ScienceDirect)

---

13. Je modifierais même légèrement vos classes

Vous proposez :

text
Encrassement
Délamination
Cellule saine

Pour un détecteur YOLO, je n'utiliserais probablement pas :

text
cellule_saine

comme une classe de défaut.

Je ferais plutôt :

text
dust
bird_dropping
delamination
physical_damage

et :

text
absence de détection = panneau probablement sain

ou bien un premier classificateur :

text
healthy
defective

suivi d'un détecteur.

Parce qu'une zone saine n'est pas réellement un objet localisable de la même manière qu'une fiente.

---

14. J'éviterais également de fusionner forcément poussière et fientes

Vous pouvez conceptuellement les mettre sous la famille :

text
Encrassement

mais garder des sous-classes :

text
encrassement
 ├── dust
 └── bird_dropping

peut être très utile.

Pourquoi ?

Parce que leur géométrie est extrêmement différente :

text
Poussière       → diffuse / texture
Fiente          → objet localisé / contour irrégulier

De plus, leur intérêt opérationnel peut être différent.

Les travaux RGB distinguent souvent explicitement dust et bird_drop, ce qui montre qu'il existe une motivation visuelle suffisante pour les considérer comme des classes distinctes. (MDPI)

---

15. Il existe un autre problème avec votre classification 3 classes : un panneau peut avoir deux défauts simultanément

Imaginez :

text
panneau poussiéreux + zone délaminée

Quelle classe attribuez-vous ?

text
Encrassement ?
Délamination ?

Une classification softmax classique vous force à choisir l'une des deux.

Or, dans une installation réelle, plusieurs anomalies peuvent coexister.

La détection d'objets résout naturellement le problème :

text
dust              confidence 0.91
delamination      confidence 0.83
bird_dropping     confidence 0.00

La littérature d'inspection multi-défauts utilise justement ce type d'approche pour traiter plusieurs types d'anomalies simultanément. (ScienceDirect)

---

16. Et pour le Raspberry Pi, la segmentation des cellules introduirait une étape supplémentaire

Votre contrainte hors connexion change fortement le raisonnement.

Un pipeline :

text
Panel detection
→ Homography
→ CLAHE
→ Cell segmentation
→ 60 × classification

est nettement plus complexe que :

text
Panel detection
→ Homography
→ enhancement léger
→ YOLOv8n

ou :

text
Panel crop
→ MobileNetV2

Chaque étape supplémentaire :

• consomme du CPU ;
• consomme de la mémoire ;
• introduit une latence ;
• introduit un nouveau point de défaillance.

Et surtout, avec 72 cellules :

text
1 panneau
→ 72 crops
→ jusqu'à 72 inférences

si vous utilisez réellement un classificateur cellule par cellule.

Ce n'est pas très attractif pour un Raspberry Pi alors que vos défauts ne justifient pas forcément cette granularité.

Les architectures comme MobileNetV2 ont justement été conçues dans une logique de calcul embarqué limité. (CVPR Open Access)

---

17. Une remarque très importante : prétraiter le dataset ne rend pas automatiquement l'inférence plus rapide

Vous avez écrit en substance :

appliquer ces traitements au dataset afin d'avoir plus de rapidité pendant l'entraînement et plus de précision.

Pour l'entraînement, oui, si vous pré-calculez les images rectifiées/CLAHE et les stockez sur disque, vous évitez de refaire les opérations à chaque epoch.

Mais pour le déploiement réel, vous aurez toujours :

text
nouvelle image caméra
     ↓
homographie
     ↓
CLAHE
     ↓
réseau

si votre réseau a été entraîné exclusivement sur ce type d'images.

Donc le coût n'a pas disparu : vous l'avez seulement déplacé.

C'est particulièrement important pour votre Raspberry Pi.

---

18. L'expérience scientifiquement correcte : une étude d'ablation

Je vous recommande fortement de ne décider aucun prétraitement par intuition seule.

Faites cinq expériences.

Expérience A — Baseline

text
crop panneau
+ resize
+ normalisation réseau

Expérience B

text
Baseline
+ Homographie

Expérience C

text
Baseline
+ CLAHE

Expérience D

text
Baseline
+ Homographie
+ CLAHE

Expérience E

text
Baseline
+ Homographie
+ CLAHE
+ segmentation cellules

Puis comparez exactement les mêmes splits.

Pour MobileNet :

text
Macro F1
Precision / classe
Recall / classe
Confusion matrix
Accuracy
latence Raspberry Pi

Pour YOLO :

text
mAP50
mAP50-95
Precision
Recall
F1
latence / image
RAM

Là, vous pourrez écrire scientifiquement :

« La segmentation cellule-par-cellule a entraîné une variation de −X % du macro-F1 et une augmentation de Y ms de la latence ; elle a donc été écartée. »

C'est beaucoup plus solide qu'une justification uniquement théorique.

---

19. Attention également à votre séparation train/validation/test

C'est extrêmement important avec des vidéos/drone.

Ne faites surtout pas :

text
frame 001 → train
frame 002 → train
frame 003 → test
frame 004 → validation

si ces frames représentent le même panneau quelques millisecondes plus tard.

Le réseau retrouverait presque exactement le même panneau dans train et test.

Les travaux récents insistent justement sur la séparation des données avant augmentation/prétraitement afin de ne pas introduire des images identiques ou transformées d'un même original dans plusieurs partitions. (MDPI)

Dans votre projet, j'irais encore plus loin :

text
split par panneau physique

voire idéalement :

text
train       → panneaux / journées / zones A
validation  → panneaux / journées / zones B
test        → panneaux / journées / zones C

Pour un objectif de déploiement réel, un très bon test final serait même :

text
site solaire jamais rencontré pendant l'entraînement

---

20. Donc : est-ce un manque d'expérience de votre part ?

Non.

Votre intuition vient d'un principe essentiel de computer vision :

la résolution spatiale de l'analyse doit correspondre à l'échelle du phénomène que l'on cherche à reconnaître.

Pour une microfissure EL :

text
module entier
 ↓
cellule
 ↓
microfissure

La segmentation en cellules peut être excellente.

Pour une fiente visible :

text
module entier
 ↓
région contaminée

La cellule n'apporte pas nécessairement une information sémantique supplémentaire.

Pour de la poussière :

text
module entier
 ↓
distribution spatiale / texture

la segmentation en cellules peut même être artificielle.

Pour une délamination macroscopique :

text
module / grande région

vous souhaitez souvent conserver le contexte global.

---

21. Ma recommandation pour votre projet

Je construirais le premier prototype ainsi :

text
                      IMAGE RGB
                          │
                          ▼
                Détection du panneau
                          │
                          ▼
              Crop + Homographie
                          │
                          ▼
         ┌─────────────────────────┐
         │ CLAHE léger optionnel   │
         │ sur luminance           │
         └───────────┬─────────────┘
                     ▼
              RGB standardisé
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
    MobileNetV2              YOLOv8n
  classification             detection
          │                     │
          ▼                     ▼
 Sain / Encrassé       type + localisation
 / Délamination

Je n'ajouterais pas la segmentation des cellules dans V1.

Je garderais toutefois l'algorithme de détection de grille/cellules comme une extension éventuelle :

text
V2 / futurs travaux :
microcracks EL
hotspots IR
cell damage
finger defects
interconnection failures

Là, elle deviendrait réellement justifiée par la nature des défauts. Les travaux EL et thermographiques vont précisément dans cette direction. (ScienceDirect)

---

Conclusion

Votre hypothèse peut donc être formulée scientifiquement de cette manière :

Dans une approche fondée exclusivement sur des images RGB conventionnelles visant la détection d'anomalies macroscopiques telles que l'encrassement, les fientes d'oiseaux, la délamination visible et les dommages physiques, la segmentation systématique du module photovoltaïque en cellules individuelles ne constitue pas a priori une étape nécessaire. Contrairement aux défauts microscopiques ou électriques observés en électroluminescence ou en thermographie, ces anomalies présentent souvent une extension spatiale indépendante des limites des cellules et peuvent couvrir plusieurs cellules simultanément. Une segmentation cellulaire pourrait alors fragmenter les motifs caractéristiques et réduire le contexte spatial disponible pour le réseau. Son intérêt doit par conséquent être déterminé expérimentalement au moyen d'une étude d'ablation plutôt que supposé a priori.

Et j'ajouterais exactement le même principe pour CLAHE et l'homographie : très bons candidats, mais leur bénéfice réel doit être mesuré, pas présumé.

Parmi les références les plus directement pertinentes à mettre dans votre état de l'art, je retiendrais surtout Di Tommaso et al., Renewable Energy 2022 pour UAV + RGB/IR + soiling/bird droppings/delamination ; Mehta et al., DeepSolarEye, WACV 2018 pour l'encrassement RGB ; les travaux de segmentation EL de Su et al. pour montrer pourquoi la segmentation cellule est pertinente dans un autre contexte ; et le papier original MobileNetV2, CVPR 2018 pour justifier le choix d'une architecture embarquée. (ScienceDirect)