je ne sais pas si je dois vous féliciter ou pas pour cette étape, car ce que vous présentez n'est qu'un discours de commerciaux. Je trouve que la démarche de recherche de financements et de partenariats est légitime, mais il est temps de revenir un peu sur la technique.
Il y a beaucoup de choses à revoir sur l'ergonomie et les aspects bas niveaux de la Elphel et je trouve dommage que vous n'expliquiez pas votre chaîne de traitement : du capteur au pc.
Il y a plusieurs points que je vais soulever, je vais donc le faire ici de manière à ce soit public.
1 ) Le système de caméra Elphel est complexe à trigger, car la caméra se désynchronise lorsque le trig externe n'est pas utilisé. Nous avons réussi à contrer ce problème en utilisant des μcontroller pour envoyer un trig périodique lorsque rien n'est reçu, mais ce n'est qu'un hack et il faudrait que cela soit fait au niveau FPGA.
2 ) Le binning par moyenne de photosites n'est pas possible lorsque l'on redimensionne la taille de capteur, ceci est du au capteur, mais il aurait été possible de le faire au niveau du FPGA, ce qui aurait nettement augmenté la sensibilité de la caméra.
3 ) La bande passante de la caméra : Le flux du capteur ne peux être envoyer en raw, ni même en jpg 100%, car la liaison entre la caméra et le pc se fait en ethernet 100. Je pense que même en giga-ethernet cela ne sera pas suffisant. Il faudrait au minimum de l'usb3 voir du Thunderbolt quitte à avoir un adaptateur ethernet dans un premier temps. Il me semble qu'implémenter un bus usb via le fpga est dans le domaine du faisable. Cela serait vraiment dommage d'avoir un tel capteur, et de transférer les images en JPG.
4) Au niveau de l'électronique, avez vous contacter la société Armadeus, ils ont des cartes tout à fait pertinentes, des compétences avancées en FPGA et tout chez eux est OpenSource et OpenHardWare. Je sais qu'ils interviennent dans une thèse qui fait du traitement RT sur des vidéos en ce moment, donc je pense qu'ils seraient heureux de réfléchir au projet avec vous. Ils ont présenter au RMLL des outils permettant d'optimiser le transferts du FPGA vers le processeur dans leur bus de manière à éviter de interruptions.
Il serait vraiment temps d'expliquer quelle stratégie vous souhaitez mettre en oeuvre.
De notre cotès, notre communauté souhaiterait pouvoir utiliser des capteurs infrarouge fait en France mais uniquement distribués aux USA, car pas de PME pour faire le travail. Nous pourrions donc facilement monter un projet oseo, pour créer ce genre de dispositif, sachant qu'une caméra normale nous coûte 80k€, qu'elles sont faites pour les industriels et que nous n'avons accès à rien même pas les libraires pour pouvoir récupérer le flux. Tout doit se faire par le logiciel windows propriétaire et nous n'avons ni le temps ni les compétences pour faire l’ingénierie inverse. Il en va de même pour nos caméra SCMOS qui coûtent dans les 60k€ et ou nous ne pourrons jamais avoir accès au FPGA. Notre problème est que nous ne sommes pas un labo d'électronique embarquée donc nous n'avons pas les compétences pour faire ces choses là et que les labos qui les ont considèrent que ce n'est pas de la recherche, ils ne sont donc pas intéressés.
Bref il y a un espace d'innovation très important, et un tel projet s'il est fait en collaboration peut permettre l'apparition d'une vrai plateforme opensource pour les flux vidéo telle que les arduinos pour les bidouilleurs. C'est pour cette raison que j'aimerais bien avoir plus de détails techniques.
Beaucoup de financement pourraient être dégagés par une collaboration intelligente.
# De la technique, que diable !
Posté par freejeff . En réponse à la dépêche Apertus va créer une caméra de cinéma numérique entièrement nouvelle. Évalué à 10.
Bonjour,
je ne sais pas si je dois vous féliciter ou pas pour cette étape, car ce que vous présentez n'est qu'un discours de commerciaux. Je trouve que la démarche de recherche de financements et de partenariats est légitime, mais il est temps de revenir un peu sur la technique.
Il y a beaucoup de choses à revoir sur l'ergonomie et les aspects bas niveaux de la Elphel et je trouve dommage que vous n'expliquiez pas votre chaîne de traitement : du capteur au pc.
Il y a plusieurs points que je vais soulever, je vais donc le faire ici de manière à ce soit public.
1 ) Le système de caméra Elphel est complexe à trigger, car la caméra se désynchronise lorsque le trig externe n'est pas utilisé. Nous avons réussi à contrer ce problème en utilisant des μcontroller pour envoyer un trig périodique lorsque rien n'est reçu, mais ce n'est qu'un hack et il faudrait que cela soit fait au niveau FPGA.
2 ) Le binning par moyenne de photosites n'est pas possible lorsque l'on redimensionne la taille de capteur, ceci est du au capteur, mais il aurait été possible de le faire au niveau du FPGA, ce qui aurait nettement augmenté la sensibilité de la caméra.
3 ) La bande passante de la caméra : Le flux du capteur ne peux être envoyer en raw, ni même en jpg 100%, car la liaison entre la caméra et le pc se fait en ethernet 100. Je pense que même en giga-ethernet cela ne sera pas suffisant. Il faudrait au minimum de l'usb3 voir du Thunderbolt quitte à avoir un adaptateur ethernet dans un premier temps. Il me semble qu'implémenter un bus usb via le fpga est dans le domaine du faisable. Cela serait vraiment dommage d'avoir un tel capteur, et de transférer les images en JPG.
4) Au niveau de l'électronique, avez vous contacter la société Armadeus, ils ont des cartes tout à fait pertinentes, des compétences avancées en FPGA et tout chez eux est OpenSource et OpenHardWare. Je sais qu'ils interviennent dans une thèse qui fait du traitement RT sur des vidéos en ce moment, donc je pense qu'ils seraient heureux de réfléchir au projet avec vous. Ils ont présenter au RMLL des outils permettant d'optimiser le transferts du FPGA vers le processeur dans leur bus de manière à éviter de interruptions.
Il serait vraiment temps d'expliquer quelle stratégie vous souhaitez mettre en oeuvre.
De notre cotès, notre communauté souhaiterait pouvoir utiliser des capteurs infrarouge fait en France mais uniquement distribués aux USA, car pas de PME pour faire le travail. Nous pourrions donc facilement monter un projet oseo, pour créer ce genre de dispositif, sachant qu'une caméra normale nous coûte 80k€, qu'elles sont faites pour les industriels et que nous n'avons accès à rien même pas les libraires pour pouvoir récupérer le flux. Tout doit se faire par le logiciel windows propriétaire et nous n'avons ni le temps ni les compétences pour faire l’ingénierie inverse. Il en va de même pour nos caméra SCMOS qui coûtent dans les 60k€ et ou nous ne pourrons jamais avoir accès au FPGA. Notre problème est que nous ne sommes pas un labo d'électronique embarquée donc nous n'avons pas les compétences pour faire ces choses là et que les labos qui les ont considèrent que ce n'est pas de la recherche, ils ne sont donc pas intéressés.
Bref il y a un espace d'innovation très important, et un tel projet s'il est fait en collaboration peut permettre l'apparition d'une vrai plateforme opensource pour les flux vidéo telle que les arduinos pour les bidouilleurs. C'est pour cette raison que j'aimerais bien avoir plus de détails techniques.
Beaucoup de financement pourraient être dégagés par une collaboration intelligente.