Intégration mesurée de l’ISP Raspberry Pi dans EIP

Un processeur de signal d’image (ISP) neutralisé peut-il produire des couleurs rouge-vert-bleu (RGB) sur 8 bits, radiométriquement cohérentes avec EIP, tout en réduisant le coût de la prévisualisation ?

Question, objet et périmètre

EIP doit conserver un chemin RAW (données brutes du capteur) pour l’enregistrement et la mesure, tout en produisant une prévisualisation couleur avec une charge compatible avec les Raspberry Pi les moins puissants. L’objectif est d’utiliser l’ISP du Raspberry Pi pour le dématriçage, puis de réappliquer les corrections EIP de façon explicite.

Le périmètre de cette validation est la prévisualisation RGB, rouge-vert-bleu, sur 8 bits encodée en MJPEG. Le transport RAW, les captures scientifiques et les enregistrements RAW ne passent pas par l’ISP. L’intégration ne cherche donc pas à transformer le buffer ISP en donnée scientifique équivalente au RAW.

Architecture des deux chemins

Le serveur expose trois choix : software, isp et auto. Le mode automatique sélectionne l’ISP lorsqu’un profil validé est disponible et se replie explicitement vers le logiciel dans le cas contraire. Le choix manuel reste disponible pour les comparaisons A/B.

L’ISP est déclaré inéligible lorsque le rendu demandé est brut, lorsqu’une région d’intérêt ou un empilement est actif, lorsque la source n’est pas libcamera ou lorsqu’aucun profil linéaire compatible n’est validé.

Contrat de neutralisation ISP

Chaque profil de production ne se contente pas de désactiver l’exposition ou la balance des blancs automatiques. Il impose un ensemble cohérent de blocs neutres, contrôlé au chargement. Toute déviation fait refuser le profil.

Pour ce chemin, AwbEnable est forcé à faux et ColourGains=(1,1). Ces contrôles ne constituent pas à eux seuls la neutralisation : elle résulte de l’ensemble du profil. La balance manuelle et la saturation des couleurs EIP sont appliquées après le buffer ISP.

Contexte visuel de mise au point

Une mire colorée artisanale a servi pendant le développement à faire apparaître immédiatement les dérives grossières et à vérifier le basculement A/B dans PiNox. Cette observation reste qualitative : la validation de la linéarité radiométrique décrite ci-dessous repose sur des pixels appairés issus de la même requête, et non sur des couleurs de référence certifiées.

Protocole appairé IMX477

Le banc isp_linear_bench configure une requête libcamera contenant deux flux simultanés :

• RAW SBGGR12_CSI2P, 2028 × 1520 ;
• flux de prévisualisation (Viewfinder) RGB888, 2028 × 1520 ;
• exposition demandée 20 000 µs, mesurée 19 999 µs ;
• gain analogique demandé 3,5, mesuré 3,49488 ;
• 10 trames par condition ;
• gains de balance des blancs égaux à 1.

Le codec de production EIP développe le RAW de la même requête. L’analyse recalcule les statistiques hors du binaire de capture, tient compte des strides, remet les composantes RGB dans leur ordre logique, exclut une bordure de 24 pixels et retire les pixels saturés.

Renormalisation du niveau noir

Dans l’expérience de diagnostic avec le niveau noir ISP à 64, la régression ISP = pente × EIP + offset donne une pente moyenne de 1,0662. L’ISP soustrait le noir puis réétale la plage utile sur 0 à 255, tandis que le codec EIP divise l’échelle 10 bits par quatre.

Dans la condition de diagnostic avec niveau noir ISP à 0, la pente moyenne mesurée vaut 0,9993. Le rapport mesuré entre les deux conditions vaut environ 0,9372, contre 0,93744 prédit. L’écart relatif est inférieur à 0,04 %. La chaîne EIP de production conserve le niveau noir ISP à 0 et applique ensuite la correction du niveau noir une seule fois dans EIP.

Les coefficients de détermination (R²) vont de 0,99587 à 0,99988. L’écart initial est donc expliqué par la renormalisation de plage, pas par une amplification colorimétrique inconnue.

Validation radiométrique, spatiale et fréquentielle

L’alignement ISP/EIP conserve l’orientation, sans retournement ni décalage mesurable. Les diagnostics haute fréquence donnent une pente comprise entre 0,9998 et 0,9999 et un rapport de variance locale de 1,000 à 1,006 selon le canal. Aucun lissage ou renforcement de contours mesurable n’apparaît dans les contrôles effectués avec le profil neutralisé.

Le rapport spatial ISP/modèle reste centré autour de 1,0002, avec un écart-type inférieur ou égal à 0,0014. Ce résultat est compatible avec la désactivation de la correction d’illumination.

Sur des captures serveur séquentielles, l’écart des moyennes globales par canal reste inférieur ou égal à 0,11 DN. L’écart absolu moyen pixel à pixel est voisin de 2,29 DN, avec un percentile 99 à 9. Cette mesure inclut les différences de dématriçage, le bruit temporel et le fait que les images ne sont alors plus simultanées.

Performances Pi 4 / IMX477 et Pi 3 / OV5647

Le benchmark serveur utilise une exposition de 8 ms, un gain analogique 4, le rendu couleur MJPEG et un seul client. Les valeurs ci-dessous proviennent du CSV archivé avec la validation. La charge du processeur central (CPU) du processus peut dépasser 100 % lorsqu’il utilise plusieurs cœurs.

La cadence est exprimée en images par seconde (IPS), la charge en pourcentage de CPU et la latence en millisecondes.

En bin1, la cadence est déjà bornée par l’acquisition mais la charge processeur chute fortement. En modes regroupés ou recadrés, l’ISP augmente parfois la cadence livrée, mais le gain CPU devient faible parce que les passes EIP postérieures et l’encodage dominent.

Le même protocole, sans compteurs matériels perf, a été exécuté sur Pi 3 avec l’OV5647. Tous les modes demandés ont effectivement utilisé l’ISP, sans repli.

Sur cette plateforme, l’ISP améliore les trois indicateurs dans tous les modes mesurés. Le coût processeur par trame est divisé par environ deux à trois en bin1. La correspondance colorimétrique OV5647 entre les deux chemins a été validée visuellement ; elle ne dispose pas encore du même banc radiométrique appairé que l’IMX477.

Ces mesures comparent les deux chemins sur chaque machine, pas le Pi 3 au Pi 4 : les capteurs et les modes diffèrent.

Intégration, sélection et repli

Chaque profil ISP est associé à un modèle de capteur précis. Le serveur vérifie sa structure, son empreinte et son niveau noir avant de l’activer. L’interface de programmation (API) publie le mode demandé, le mode effectivement résolu, la disponibilité du profil, son chemin, son empreinte et les compteurs de repli.

Un mode ISP explicitement demandé est refusé si le profil n’est pas conforme. Le mode automatique revient au logiciel et expose la raison. Aucun repli silencieux n’est accepté. Le changement de chemin recrée la session libcamera afin que l’IPA relise le profil, sans nécessiter le redémarrage du serveur.

Limites

• La validation radiométrique appairée porte sur une scène, une exposition et un gain de l’IMX477.
• Le RAW12 est normalisé dans le domaine 10 bits avant la comparaison au RGB8 ; ces nombres décrivent la profondeur numérique.
• L’ISP et EIP utilisent des algorithmes de dématriçage différents ; la texture fine peut donc différer.
• Le gain numérique interne éventuel n’a pas été mesuré séparément.
• Le profil OV5647 est validé visuellement et par les performances, pas encore par une régression appairée complète.
• Les régions d’intérêt, l’empilement et le rendu RAW restent logiciels.
• Les résultats de performance décrivent les versions, réglages et machines du banc ; ils ne constituent pas une propriété universelle de l’ISP.

État des résultats

Conclusion

L’ISP VC4 peut être intégré à EIP comme accélérateur borné du dématriçage, sans modifier le RAW ni déléguer les réglages scientifiques au pipeline automatique de libcamera. La mesure appairée montre qu’une différence initialement attribuable au chemin matériel provenait en réalité de la renormalisation du niveau noir. Une fois ce mécanisme neutralisé, la pente ISP/EIP revient à 0,9993.

Le bénéfice pratique est particulièrement fort sur les prévisualisations pleine résolution et sur le Pi 3 associé à l’OV5647. Il reste plus modeste lorsque le développement logiciel regroupé est déjà efficace. Cette dépendance justifie le maintien des modes automatique, logiciel et ISP explicite, ainsi que la publication du chemin réellement utilisé dans l’API.