Discussion :

[Vincent PETIT]

Je viens de regarder la doc de ta caméra 1.
Ne prend pas mal cette question, c'est juste pour moi savoir si tu as exploré plusieurs solutions.

*******************
Cette caméra a un temps d'exposition réglable de 10µs à 26.8s, le temps d'exposition d'un capteur CCD correspond à la durée d'accumulation de lumière. C'est a dire que plus tu augmentes le temps d'exposition, plus tu laisses le capteur se charger en lumière et donc plus tu as de détails. En astrophotographie c'est une pratique courante, on place un appareil photo numérique sur l'objectif d'un télescope, on attend simplement que le capteur se charge avec le peu de lumière que le télescope nous donne puis on prend une photo et on recommence en ayant pris soin de modifier la position du télescope car la terre bouge. Plus on attend longtemps et plus on voit de détails, c'est comme ça que nous nous sommes aperçu que même les zones du ciel qui nous paraissent noirs, abritent en réalité un nombre impressionnant d'astre en tout genre.

Au lieu de demander à la caméra de courir avec un débit de dingue, as tu essayer de lui demander de la qualité en augmentant le temps d'exposition au détriment du nombre d'images par seconde ?

[xe4b4ct]

Bonjour Vincent,


pas de soucis pour la question. Je n'ai jamais vu cette option mais on pourrait augmenter le temps d'exposition en effet. Reste à savoir comment le paramétrer.
Cela ne résout toujours pas le MC contrôleur ou d'odroid à intercaler.

Question débit, arrivez-vous au meme débit de données? ca 200 Mo/s

Cordialement

Mathieu

[djuju]

Plus on attend longtemps et plus on voit de détails

Attention, c'est ultra simpliste comme façon de voir les choses. Le temps d'expo s'ajuste en fonction de la scène selon le triptyque expo/sensibilité/ouverture.

Si on ne prend que l'expo, trop longtemps = image surexposée donc inexploitable puisque tes pixels saturent, et à l'inverse trop court = image sous expo, donc manque de dynamique de niveau de gris (ou des composantes RGB).
Par ailleurs, si tu ouvres plus longtemps et que le drone bouge (ou des éléments de la scène), c'est un flou garanti. En assumant que tes cam ont un objectif à focale fixe (ou que tu la fixe, ce qui est sûrement le cas pour de la vision par ordi), tu dois garder ton objectif plutôt fermé pour avoir une bonne profondeur de champ, ce qui implique moins de lumière sur ton capteur. Donc, avant de ralentir l’acquisition, je jouerais sur la sensibilité, soit le gain. D'autant que si tu n'ajuste rien, à 12FPS tu dois avoir une expo d'environ 83.3ms, ce qui est très long !
Fait attention, la plupart des sensors moderne offre un premier range de gain analogique qui n'introduit pas trop de bruit (jsuqu'à un certain point), puis ils finissent sur un gain numérique qui est un simple facteur à appliquer sur les pixels et qui donc est tributaire de la discrétisation de tes valeurs avant gain. En gros, gain digital = beaucoup de bruit et aucun intérêt en CV.

Bref, tout ceci est plutôt compliqué sans question précise, mais j'ai une bonne expertise en optique/vision par ordinateur, donc si je peut t'aider avec tes cam, ça me fera plaisir.

Par ailleurs, si tu es prêt à revoir ton hardware, notamment pour ajouter des micro qui font du traitement d'image, tu peux jeter un œil au MIPI. Ca sera plus simple à gérer car tu n'as pas besoin de toutes les dépendances aux couches USB et/ou ethernet.
Par exemple, voici une carte qui peuvent gérer 2+ cam en MIPI : https://www.e-consystems.com/CX3-Ref...Design-Kit.asp
Le même fabricant offre des cam MIPI: https://www.e-consystems.com/13MP_MI...era_module.asp -- https://www.e-consystems.com/cameramodule.asp
Voir aussi les autres boards de calcul : https://www.e-consystems.com/Computer-on-modules.asp

[djuju]

ca 200 Mo/s

En comptant à la louche, la cam donne du 12b/px qui doit probablement être codé sur 16b. Avec 3384*2704 px x 2B x 13.2FPS => ~230MB/s. (sans tenir compte de l'overhead du protocole de com)

[Vincent PETIT]

Attention, c'est ultra simpliste comme façon de voir les choses. Le temps d'expo s'ajuste en fonction de la scène selon le triptyque expo/sensibilité/ouverture.

En effet, en voulant vulgariser j'ai masqué les problèmes.

En comptant à la louche, la cam donne du 12b/px qui doit probablement être codé sur 16b. Avec 3384*2704 px x 2B x 13.2FPS => ~230MB/s. (sans tenir compte de l'overhead du protocole de com)

Je trouve le même ordre de grandeur sans arrondi :

Cela ne résout toujours pas le MC contrôleur ou d'odroid à intercaler.

En jouant sur les paramètres de la caméra, il se pourrait que tu puisses réduire la quantité de données, ce qui est le plus gros de ton problème. Il se pourrait même que tu n'aies plus besoin d'insérer un microcontrôleur, entre la caméra et le PC, pour faire du prétraitement.



Je ne doute pas que tu as fait le tour de la question avant de choisir cette caméra mais moi j'ai l'impression de ne pas avoir toutes les informations.

Tu as besoin d'une grande résolution pour l'analyse d'où les 9Mpx mais pour autant tu penses pouvoir compresser l'image sans altérer l'analyse. Je m'interroge donc sur la pertinence de la résolution. Peut on la diminuer ?
L'environnement a filmer est relativement sombre ce qui implique une attention particulière au temps d'exposition à la lumière pour extraire plus de "détails lumineux" (j'écris entre parenthèses car ce n'est pas le bon terme)
Je suppose que le drone n'avance pas a une vitesse folle alors pourquoi as tu besoin d'autant d'image de cette résolution par seconde ? 13.2 images de 9Mpx/seconde c'est par exemple, pour une caméra de surveillance de grande qualité où tu pourrais suivre quelque chose en mouvement (un peu en saccade) mais en ayant la possibilité de faire un zoom pour observer des détails.

[xe4b4ct]

Bonjour Vincent,

Les ordres de grandeurs sont les memes, c'est plutôt bon signe.

La precision des données finales, i.e. utiles depend de plusieurs facteurs: la resolution, la taille des pixels et le pas d'échantillonnage le long du tronçon. Ce sont en gros les critères qui nous ont conduits au choix de cette camera.
Réduire la résolution: à focale constante, taille constante de l'objet observé, on va sérieusement diminuer la précision - on ne peut pas.
Réduire les fps: on pourrait, mais cela va ralentir le drone pour garder la meme resolution spatiale (le long de l'axe de déplacement).

Concernant la compression: on ne garde que les pixels d'intérêt, dans la couleur d'intérêt. Il ne s'agit pas vraiment d'une compression mais d'une extraction.
On se fout des bleus et verts et des pixels trop sombres: donc on les supprime, ne gardant que ce qui nous intéresse.

J'espère avoir donné plus d'infos pour vous aiguiller.

Cordialement,

Mathieu

[djuju]

Réduire la résolution: à focale constante, taille constante de l'objet observé, on va sérieusement diminuer la précision - on ne peut pas.
[...]
On se fout des bleus et verts et des pixels trop sombres: donc on les supprime, ne gardant que ce qui nous intéresse.

Ces deux phrases montrent une contradiction. Tu dis que tu ne peux pas réduire la réso, mais que tu utilise seulement les pixels rouge.
Une caméra RGB est généralement constituée d'une matrice de Bayer. Tu obtiens une valeur RGB pour chaque pixel de ta cam, mais c'est une simple interpolation (souvent bi-linéaire). En fait, seul 1px/4 a de l’intérêt pour toi, puisque tu as 1px/2 rouge en vertical et en horizontal. J'imagine que seul le rouge t'intéresses, parce que tu as un laser rouge.
Donc, tu pourrais avoir une cam B&W, avec 1/4 de la réo actuelle et avec un filtre rouge, ce qui améliorait déjà tes conditions. En effet:
- le filtre rouge te permettrait d'être à la fréquence exacte de ton laser (pas besoin de regarder tous les rouges si ton laser est à 605nm)
- Ta cam aurait une réso de 1/4, donc moins de bande passante et chaque pixel coderait 100% de sa surface sur le sensor (vs 25% actuellement car tu n'utilise pas les bleues et les 2 verts)

Tu peux aussi augmenter ta densité de points scanné en utilisant une cam B&W de même réso (9MPx) avec un filtre.

Note: Si tu utilise la composante rouge de chaque pixel de ton image RGB (de-Bayered), soit 3384x2704px, tu fais très probablement une erreur.
Note 2: Si j'ai bien visé et que tu utilises un laser rouge, passer au bleu améliorera de façon notable ton rapport signal/bruit et donc ta précision finale.

[Forthman]

ou juste virer les composantes V et B de ton image, si tu pars d'une image 32 bits, et que tu peux te satisfaire de 256 dégradés de rouge, tu divises ton volume par 4
Ajoute à cela une petite compression simple et rapide telle que le run-length encoding, et hop ! un simple Atom suffirait ! (ok, j'abuse un peu là )

[xe4b4ct]

Bonjour à tous,

@djuju: je ne comprends pas cette histoire de 1 px/4. En prennent une image de la vidéo, je trouve une matrice de 3384 x 2704 x 3 (une tranche pour chaque couleur). Pas ne pas réduire la résolution, je parle de ne pas réduire la taille des tranches (3384 x 2704) - Si on fait cela, je pers en précision. Je comprends par contra fortement l'intérêt d'avoir une camera N&B et un filtre rouge, mais à 9 MPix, pas 2.3 MPix. Du coup je ne comprends pas l'erreur décrite dans ta note.

@Forthman: merci pour le run-length encoding - une piste à creuser.

J'ai commandé un Odroid XU4 pour voir ce que l'on peut faire avec lui et la cam 1. Reste à me plonger dans cette matrice de Bayer et les images RGB pour vérifier que je ne fais pas d'erreur.

Cordialement

Mathieu

[djuju]

Bonjour,

Effectivement ce n'est pas clair et ce n'est pas facile à expliquer par écrit rapidement.
Donc, repartons du début et n'hésites pas à me demander des détails.

Un sensor de caméra ne sait voir que les nieaux de gris. Pour faire de la couleur on ajoute (dans la grande majorité des cas) une matrice de bayer.
Une matrice de Bayer est un simple filtre de couleur que l'on place au dessus des pixels de ton sensor pour filtrer les composantes RVB et ainsi reconstituer une image couleur.
Une matrice de Bayer est toujours composée de 2 pixels vert pour un bleu et un rouge. C'est simplement pour reproduire l'oeil humain, qui est plus sensible dans les verts.



Hors, si ta cam te donne 3384x2704 pixels avec pour chacun ses composantes RGB, en fait le sensor n'a pas vu 3x3384x2704 valeurs. En effet, il n'a en tout que 3384x2704 pixels, qui sont soit vert, rouge ou bleu selon la composantes du filtre de Bayer qui est au dessus.
Alors tu me diras, comment je peux avoir un triplet RGB par pixel ? En fait, on applique un algorithme de de-bayering (ou demosaicing). Pour les flux vidéos, qui doivent être traitée real-time, on utilise souvent un algo bi-linaire. L'idée est simplement que pour chaque pixel, on prend la composante qui lui ait propre et on interpole les composantes manquantes en faisant la moyenne des pixels avoisinants.



À ce point ci, tu devrais commencer à comprendre que pour chaque pixel tu n'as qu'une composante qui montre réellement la lumière qui a impactée le pixel, les autres sont estimées à partir du voisinage et donc (1) fortement bruitées et (2) déjà traitées.
Donc, prendre tous les pixels augmente la densité du nuage de points résultant, mais baisse sa précision en introduisant beaucoup de bruit. En imaginant que tu as un laser à simple ligne, cette approche te permet d'avoir 2 fois plus de points, puisque tu as deux fois plus de colonne dans ton sensor, mais 1 point / 2 aurait pu être obtenu en faisant la moyenne de ses voisins.
Donc, si seule les composantes rouge intéressent, tu ne devrais traiter que les pixels rouge, soit prendre 1 colonne / 2 et 1 ligne / 2, ce qui correspond à une réso sensor divisée par 4. Note qu'en faisant ainsi tu traites toutes les données utiles.

Maintenant, que peut-on faire ?
Bon, ce que tu veux c'est filtrer le rouge pour augmenter ton rapport signal / bruit. Dans ce cas, tu peux prendre une caméra B&W et y mettre un filtre rouge par dessus. Ça te permet:
1 - soit de prendre une cam avec un réso de 1/4 de celle que tu utilises actuellement et te retrouver avec la même quantité de données à traiter, mais:
a - Tu traites vraiment toute la surface de ton sensor et pas 1/4 puisque tu jettes 3px/4
b - De choisir un filtre à l'exacte fréquence de ton laser, ce qui améliore encore ton report signal / bruit par rapport au filtre rouge à large bande de ta matrice de Bayer
2 - soit de prendre une cam à la même réso et ainsi garder ta densité, tout en améliorant ta précision puisque chaque pixel "à vraiment vu du rouge". Comme précédemment, tu pourras choisir un filtre à la bonne fréquence.

J'espère que c'est plus clair.

[xe4b4ct]

Salut djuju,

voilà qui est parfaitement clair. Du coup, il serait bien de changer la caméra voire de l'échanger pour passer à la meme en noir et blanc.
Je comprends bien mieux avec un schémas.

Pour en revenir au flux de données: Il y aurait il un moyen de prendre que les seuls vrais pixels rouges avec la caméra actuelle? i.e. revenir à 50 Mo/s en données brutes en laissant les 50 % de vert et 25% de bleu?

Cordialement

Mathieu

[djuju]

Pour en revenir au flux de données: Il y aurait il un moyen de prendre que les seuls vrais pixels rouges avec la caméra actuelle? i.e. revenir à 50 Mo/s en données brutes en laissant les 50 % de vert et 25% de bleu?

Malheureusement, non. Enfin, j'en serais étonné.
Les sensors modernes ont bien un skip mode qui permet de sauter des colonnes ou lignes, mais sur tous les sensors couleurs que j'ai vu, la discrétisation est faite pour ne pas casser l'intégrité de ta matrice de Bayer... On ne peut sauter les colonnes (ou lignes) que par multiple de deux.
C'est d'ailleurs dommage pour toi, car d'un point de vue électro, c'est n'est pas un problème. D'ailleurs les versions B&W des sensors couleurs n'ont généralement pas cette limitation.
Anyway, même si tu avais eu le feature, il aurait fallu que le driver l'implémente aussi ou que tu es accès aux registres de ta cam, ce qui n'est pas fréquent pour une cam USB ou Ethernet. En MIPI, c'est autre chose puisque tu as plus ou moins accès à tout.

Par contre, tu peux sûrement économiser un peu de calcul coté PC en prenant l'image RAW. Tu économise ainsi le debayering et tu doit itérer sur un buffer de 1x3384x2704 valeurs, plutôt que 3x3384x2704.

[xe4b4ct]

Salut à tous,

@djuju: Et bien c'est con que l'on ne puisse pas récupérer uniquement les pixel rouge. En ayant compris un peu comment est fait un capteur, je prendrai à l'avenir des cam B&W avec un filtre.
Par centre, en récupérant le raw et, en admettant que je puisse connaitre l'emplacement des pixel R, G et B (hypothèse forte), je devrais pouvoir virer les points inutiles.

@ tous: reste à savoir quoi utiliser pour faire ce pré-traitement. Je vais commencer un peu avec l'Odroid. Je suis toujours intéressé par tester les micro-controlleurs: reste à vois le prix et comment les coder.

Cordialement,

Mathieu

[Vincent PETIT]

L'Odroid XU4 devrait faire l'affaire dans la mesure où il possède un port ethernet Gigabit et un processeur dimensionner en conséquence.

Tu peux visiblement faire tourner dessus Linux ou Android, bon c'est un peu dommage puisque ceux sont des OS multitâches aux quels tu ne donnera a faire qu'un traitement bien définie et qui a besoin de rapidité.

Il est possible ou pas que les données de la caméra arrivent plus rapidement que la durée du traitement (donc accumulation de données) mais pour voir ça il faut essayer.

A ce jour, je n'ai pas trouvé de démo-board à microcontrôleur connu (prête à l'emploi dans le genre Odroid/Raspberry etc...) avec de telles spécifications.

Je parle de micros connus dans le sens où ils n'ont pas comme seul outil de développement IAR et compagnies à 5000€ la licence

[djuju]

Par centre, en récupérant le raw et, en admettant que je puisse connaitre l'emplacement des pixel R, G et B (hypothèse forte), je devrais pouvoir virer les points inutiles.

J'ai essayé d'avoir la datasheet de ton sensor, mais je ne trouve que l'overview. La doc compète doit être sous NDA comme d'habitude... Tu as peut être une chance dans la doc de ta caméra que je n'ai pas regardé.
Soit tu peux signer un NDA avec Sony pour avoir la doc (ca peut être intéressant car tu pourra voir tous les modes de fontionnement de ton sensor). Soit tu met ta cam dans le noir avec une simple lumière rouge. Tu récupère l'image RAW, les pixels qui ont les plus fortes valeurs sont les rouges.

[xe4b4ct]

Bonjour

@Vincent: dommage, je vais essayer avec cet Odroid mais je dois découvrir linux et un autre programme de calcul. Que conseillerez-vous? python, C, C++, ...

@djuju: Signer un DNA quand on mettra le code en accès libre - cela ne passera pas. Par contre pour la lumière rouge dans le noir, il faudrait quelle soit non uniforme, non? Si elle est uniforme, 'interpolation sur les pixel V ou B ne permettra pas de voir la différence. Autre idée: je pense que les schémas de répartition des pixels sont plus ou moins connus. Par groupe de 4, 2 V, 1 B et 1 R: on pourrait tester toutes les permutations possible et tenter de reconstruire au mieux une image rouge connue. Est ce que cela pourrait marcher?

Cordialement

Mathieu

[Vincent PETIT]

Pour la mise en place de l'algorithme, il faut éviter les langages interprétés comme JAVA, Python etc... car cela ajoutera de la lenteur, préfère C ou C++ qui seront bien plus rapides.

[xe4b4ct]

Bonsoir Vincent,

Ok: C ou C++ - un des deux est il plus rapide que l'autre?
Quel logiciel pour éditer ces codes?

Je commençai Python ces derniers temps

Cordialement

Mathieu

[Vincent PETIT]

C ou C++ - un des deux est il plus rapide que l'autre?

Mathieu,
Je ne répondrai pas à cette question au risque de déclencher à nouveau une guerre. Sur un site comme developpez.com il y a de très fortes communautés C et C++ et tu apprendra que si tu attaques un empire, l'autre empire.... Contre attaque !

Prend celui que tu veux, ils sont efficaces tous les deux.

Quel logiciel pour éditer ces codes?

Une distribution Linux est souvent livrée (pour ne pas dire presque toujours) avec le compilateur GCC et tu peux prendre n'importe quel éditeur de texte pour écrire ton programme. Moi j'utilise souvent Eclipse comme environnement parce que j'ai besoin de debugguer mais sans ça un simple éditeur de texte convient parfaitement.

Le programme sera compilé en un code prévu pour le processeur du Odroid.

[xe4b4ct]

Bonjour,

OK, je ne déclencherai pas une autre guerre de paroisse. Je vais jeter un coup d'oeil à la programmation en C/C++.

A tout hasard, existe t'il des banques de codes en C/C++ (genre matlab Filex) pour:
- communiquer avec la caméra via le port ethernet
- récupérer les données
- traiter les données
- les renvoyer par l'USB
- allumer une petite LED pour afficher que le statut est Ok.

Cordialement

Mathieu