4.13. Formats de pixels

L’étape finale du pipeline ISP empaquette chaque pixel selon une disposition d’octets particulière en mémoire. Le format choisi représente un compromis entre la qualité de l’image, la taille mémoire et la manière dont le code en aval relit les octets. Une poignée de formats dominent.

4.13.1. RAW (Bayer)

La sortie par défaut est le Bayer brut – la même mosaïque à un canal par pixel que produit le capteur. Un octet par pixel, disposé selon le motif de Bayer : rouge et vert alternés sur les lignes paires, vert et bleu alternés sur les lignes impaires. Aucune débayerisation n’a été appliquée, si bien que chaque cellule ne contient encore que la valeur que son filtre de couleur a laissée passer.

Le Bayer brut occupe un tiers de la mémoire d’une image RGB finie à trois canaux – un octet par pixel contre trois – et aucun cycle ISP n’a été dépensé à le débayeriser ou à le convertir. La contrepartie est que le code utilisateur doit effectuer lui-même la débayerisation avant qu’aucun traitement tenant compte de la couleur puisse s’exécuter.

4.13.2. RGB888

RGB888 est le format fini naturel pour une image en couleur : trois octets par pixel, un pour chacun des canaux rouge, vert et bleu à 8 bits par canal. Vingt-quatre bits par pixel et un peu moins de dix-sept millions de couleurs distinctes.

RGB888 est la référence conceptuelle pour les images en couleur finies et la plupart des logiciels externes le comprennent. Sur du matériel embarqué, son principal inconvénient est la taille de pixel de 24 bits – pas un multiple de la taille de mot du processeur, peu pratique pour l’alignement mémoire, et 50 % plus volumineux que le format suivant.

4.13.3. RGB565

RGB565 empaquette chaque pixel dans deux octets : cinq bits de rouge, six bits de vert, cinq bits de bleu. Le bit de vert supplémentaire reflète la plus grande sensibilité de l’œil au vert, et il correspond au poids double du canal vert dans le motif de Bayer.

RGB565 est le format de couleur par défaut sur l’OpenMV Cam. Deux octets par pixel sont alignés sur 16 bits, ce qui correspond aux largeurs de données naturelles du MCU – les chargements, stockages et opérations arithmétiques sur les pixels s’exécutent tous à pleine vitesse, et de nombreuses opérations peuvent traiter une paire de pixels à la fois. Les pixels de 24 bits de RGB888 ne s’alignent pas ainsi et coûtent à chaque accès. L’économie de 33 % de mémoire par rapport à RGB888 s’accumule également : le QVGA (320 x 240) occupe 150 Ko en RGB565 contre 225 Ko en RGB888, et l’écart se creuse avec la résolution.

Le compromis est de 65 mille couleurs distinctes au lieu de dix-sept millions. Pour la plupart des tâches de vision industrielle, la différence est invisible, car les algorithmes réduisent la trame en représentations seuillées ou à contours détectés qui suppriment de toute façon la majeure partie du détail de couleur. Pour l’œil humain, les bits manquants apparaissent sous forme de léger bandage dans les dégradés de couleur lisses, mais sans que l’œil ne le remarque immédiatement.

4.13.4. YUV422

YUV422 sépare la couleur de chaque pixel en une valeur de luminance (Y) et deux valeurs de chrominance (U et V), puis sous-échantillonne la chrominance car la vision humaine est bien moins sensible aux variations de couleur qu’aux variations de luminosité. Chaque pixel porte son propre Y, mais les paires de pixels adjacents partagent un seul U et un seul V. La disposition d’octets pour chaque paire est de quatre octets – Y0, U, Y1, V – ce qui revient à deux octets par pixel en moyenne, identique à RGB565.

Les deux octets signifient toutefois des choses différentes de ceux de RGB565. Le canal Y à lui seul est une image en niveaux de gris 8 bits prête à l’emploi, ce que la plupart des algorithmes classiques de vision industrielle (détection de contours, mise en correspondance de modèles, analyse de blobs) consomment réellement ; les canaux U et V portent l’information de couleur pour le petit nombre d’algorithmes qui en ont besoin.

YUV422 est le bon choix lorsque le pipeline a besoin des deux – un algorithme de première étape qui ne lit que Y suivi d’une étape ultérieure qui utilise la chrominance pour des décisions de couleur plus fines – car les valeurs Y sont là, prêtes à l’emploi, sans conversion d’espace colorimétrique.

4.13.5. Niveaux de gris

Les niveaux de gris occupent un octet par pixel : la valeur de luminance seulement, aucune couleur. C’est le plus petit format fini – la moitié de la taille de RGB565 et YUV422, le tiers de la taille de RGB888.

La plupart des algorithmes classiques de vision industrielle travaillent de toute façon sur les niveaux de gris, si bien que supprimer le canal de couleur directement à la sortie du capteur est souvent le choix le plus simple et le plus économe en mémoire. La détection de contours, la recherche de lignes, l’analyse de blobs, le décodage de QR-codes, la mise en correspondance de modèles et la détection d’AprilTag s’exécutent tous sur des niveaux de gris et profitent du tampon plus petit.

4.13.6. Autres formats

Quelques formats que l’OpenMV Cam peut produire ne sortent pas du pipeline ISP dans le cadre du flux normal.

BINARY est d’un bit par pixel – la plus petite représentation possible. Utilisé pour les images seuillées, les tampons de masque et la sortie de toute opération qui ne distingue que correspondance et non-correspondance à chaque pixel.

JPEG est un format de couleur compressé. Certains capteurs intègrent un encodeur JPEG sur puce et peuvent fournir directement des trames compressées en JPEG ; pour les capteurs qui en sont dépourvus, le MCU exécute un encodeur JPEG sur une trame RGB ou en niveaux de gris finie après l’ISP. Dans les deux cas, la sortie est un flux binaire JPEG, utile pour enregistrer des trames sur un support de stockage ou les envoyer sur une liaison à bande passante limitée.

PNG est un format compressé sans perte. Les capteurs ne produisent pas de PNG directement ; le MCU compresse à la demande une trame RGB ou en niveaux de gris finie. Utile lorsque la bande passante ou le stockage importe mais que la compression avec perte appliquée par le JPEG écarterait des informations dont l’application a besoin par la suite.