Réintroduire l’ISP sans perdre la maîtrise du signal

Peut-on utiliser le processeur de signal d’image (ISP) du Raspberry Pi pour soulager le processeur central (CPU) sans laisser une boîte noire modifier le signal à notre place ?

Un capteur couleur ne fournit pas encore une image prête à regarder. Chaque photosite mesure une seule couleur ; il faut reconstruire les autres composantes par dématriçage et préparer un rendu. Le processeur généraliste peut faire ce travail, mais le Raspberry Pi possède déjà un spécialiste de l’image : un circuit matériel conçu pour fabriquer une image couleur.

Ce circuit porte le nom d’ISP, pour Image Signal Processor : processeur de signal d’image. Rapide, oui. Libre de prendre des initiatives, non. EIP l’utilise pour accélérer la prévisualisation, tout en gardant les décisions de rendu et les données brutes (RAW) sous son contrôle.

Deux chemins de prévisualisation, un RAW scientifique à part

Le processeur d’image standard peut notamment appliquer automatiquement une balance des blancs, une matrice colorimétrique, du gamma, une réduction de bruit, la correction des pixels défectueux (DPC), de la netteté ou une correction d’illumination. Ces automatismes sont pratiques pour une photo agréable ; ils compliquent l’interprétation si leur effet n’est pas maîtrisé.

La chaîne de prévisualisation retenue est : RAW Bayer → ISP VC4 neutralisé et linéarisé → RGB888 → correction du niveau noir par EIP → balance EIP → gain, gamma, étirement, saturation et dispersion EIP. Le RAW enregistré, transporté et caractérisé reste, lui, en dehors de cette chaîne.

Une mire pour repérer les dérives, pas pour certifier les couleurs

Deux traitements, le même RAW de départ

Pour vérifier ce principe, le banc de test demande à libcamera de produire, dans une même requête, le RAW et l’image RGB issue de l’ISP. Le codec EIP développe ensuite ce même RAW. La comparaison associe donc les deux sorties d’une même requête ; elle ne compare pas deux captures indépendantes.

Le coupable était le niveau noir

Une première comparaison donnait une pente moyenne de 1,0662 entre les valeurs ISP et celles développées par EIP. Cela ne révélait pas une mystérieuse amplification couleur : l’ISP soustrayait un niveau noir de 64, puis réétalait la plage restante sur toute l’échelle 8 bits. La pente suivait cette renormalisation.

Le passage au niveau noir ISP à 0 donne une pente mesurée de 0,9993, proche de la prédiction 0,9971. Le rapport mesuré des pentes est ≈ 0,9372, contre 0,93744 prédit ; l’écart relatif est < 0,04 %. La correction de niveau noir intervient ensuite dans EIP, une seule fois.

Ce que cela change réellement sur Pi 4 et Pi 3

« Matériel plus rapide » n’est pas une règle universelle. Le bénéfice dépend du mode, de la résolution, du capteur et de l’étape qui constitue le goulot d’étranglement.

La cadence est exprimée en images par seconde (IPS). La charge du processeur central (CPU) mesure l’effort demandé au processeur ; elle peut dépasser 100 % lorsque plusieurs cœurs sont utilisés. Le temps en millisecondes correspond à la latence. Ces valeurs décrivent les machines et réglages du banc, pas une performance universelle de tous les Raspberry Pi.

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

Sur l’IMX477 en pleine résolution, la cadence est limitée par la caméra mais l’ISP libère beaucoup de temps processeur. Sur l’OV5647 du Pi 3, il réduit aussi la latence et augmente la cadence livrée. Dans certains modes regroupés de l’IMX477, le gain est beaucoup plus faible : le chemin logiciel y était déjà efficace.

Ce que l’ISP n’a pas le droit de toucher

Si le profil ISP est absent ou incompatible, le repli vers le logiciel est explicite. Les modes logiciel et ISP restent sélectionnables pour comparer les résultats. Certains modes regroupés de l’IMX477 étaient déjà efficaces côté logiciel ; l’ISP n’est donc pas systématiquement plus avantageux.