On compile tout avec les libs system, dont openmp, mpi, fftw3, ….
Compiler en static de Linux vers Linux demande de refaire tout le travail de makefile toute la compilation en local de toutes tes bibliotheques, si son systeme permettait de tout installer en local pour un packaging en local ca eviterait un boulot d'informaticien qui n'est pas vraiment le miens …
Quand a ton lien sur les les bibliotheaues partagees, c'est justement le probleme … je ne sais pas ce que j'aurai lorsque j'arriverai. Par exemple la j'ai envoye deux semaines a l'avance ma demande d'installation de lib, mais non il n'avaient pas les RH pour le faire, ce que je peux comprendre. donc on arrive et tout a La Rache, on y arrive mais on perd du temps alors a 10k euros par journee c'est un peu la loose.
je sais que j'aurais un linux 64 bits sans droits d'admin.
Voila les contraintes …
Apres c'est un pb de genie logiciel, je ne suis pas expert …
je ne suis pas tres au point avec tout cela mais j'en aurais vraiment besoin.
Nous avons fait un projet ou nous utilisons des libs bas niveau comme openmp,mpi,fftw3,…
On les a toutes installees en dynamic sous nos machines, mais nous devons utiliser ce programme dans des endroits ou nous ne pouvons etre root, genre accelerateur de particules.
Du coup si je pouvais avoir un bon gros executable ou alors un repertoire qui contient tout et que je peux lancer en local en gerant des variables d'environnement alors cela nous aideriait beaucoup. J'utilise ce Code en ce moment a l'Institut Paul Scherrer et j'ai vriament eu de la chance que les admins soient sympa.
Donc si une telle chose est possible sous linux j'en serais ravi !
Si tout ceci est trivial a faire n'hesitez pas a me le dire !
J'ai essayé de vérifier et apparemment tu as raison !
Il n'y aura pas de drivers libres de chez Intel permettant d'exploiter la puce de décodage, l'accélération 2D et 3D. Du coup je trouve cette carte vraiment moins intéressante.
C'est bien dommage.
Je pense que leur idée est d'aller sur le terrain de la beagle board et de son DSP qui permet de faire pas mal de choses, mais du coup pas d'accès à VA-API.
Je suis déçu, cela m'apprendra à aller voir les spec des composants avant de poster …
Mais par rapport à ce que tu proposes, il y a le giga ethernet et surtout un driver graphique inclue dans le noyau. Il me semble que c'est le plus gros problème aujourd'hui.
Donc au final si ça ne révolutionne pas grand chose c'est tout de même très intéressant.
Oui je pense que c'est l'idée, mais l'atout principale est pour moi le fait de donner l’accès aux GPIO et autres bus sans passer par la complexité qu'il y a dans tout le monde ARM. Du coup c'est assez simple de se faire une petite carte que fait de la conversion analogique numérique en SPI ou I²C en utilisant IIO. Cela évite de devoir utiliser Comedi par exemple.
En ce qui concerne le prix. Si tu regardes combien coûte une carte CAN compatible Linux. C'est autour des 400€ chez Peak. La tu as une carte avec du CAN et avec un river directement inclue. Tu peux directement faire du socketCAN dans CAN Festival.
On est dans l'ordre de grandeur du prix d'une BeagleBoard par exemple.
Donc je pense que c'est plus qu'un PC (GPIO), et de l'ordre de grandeur du prix d'une BeagleBoard. C'est donc une outil assez intéressant.
oui en effet ce n'est pas utile pour faire un routeur. Je pense que l'utilisation pour faire de l'embarqué facilement (genre domotique, régulation,…) grâce au GPIO ou alors faire une plateforme multimédia via le HDMI me semble tout à fait possible.
Le fait que le GPU soit de chez intel permet également d'avoir de très bonnes performances sur un linux.
Donc tu as raison, mais je ne pensais pas à cette cible.
Ce projet est très intéressant et progresse régulièrement, ce qui ne semble pas être le cas de heekscad par exemple. Il est vraiment dommage que des problèmes de licences entre branches de la GPL ralentissent son bon développement. Le format DWG est un standard de fait, c'est un peu comme le .doc on peut le déplorer mais c'est un standard.
En ce qui concerne les avancées de FreeCAD, il ne manque plus que le module d'assemblage avec contraintes pour pouvoir vraiment envisager de développer avec !
Le gros point noir étant l'export en plans. Est il possible de rajouter de la cotation fonctionnelle ?
C'est vraiment remarquable d'avoir fait tant de progrès, j'espère que ça avancera vite. Je vais le faire tester à un des ingénieurs que j'encadre pour qu'il me dise ce qu'il lui manque. Il a toujours travaillé sur Catia où il a ses habitudes ce qui me permettra de faire un retour constructif à l'équipe de développement.
Il n'y a pas que Mdc, il y a aussi Ingé de recherche (vu que tu aimes pisser du code c'est ce qu'on leur demande), chargé de recherche au CNRS à l'INRIA à l'INSERM (oui aussi en info). Il faut arrêter de caricaturer.
C'est des postes passionnant avec des sujets variés et émulant qui permettent en plus de faire de la veille et de faire de l'OpenSource. Que vous faut il au juste ?
Je ne suis pas du tout d'accord !
Je connais plein de gens (dont moi même) qui ont fait une thèse CIFRE et qui sont aujourd'hui dans le monde académique. Et ce que tu dis est complètement faux pour les grosses boites au CEA ils prennent les docteurs à des postes plus haut placés, chez EDF aussi chez SNECMA aussi, chez EADS également. Je trouve que les choses changent vraiment, au moins ça te laisse le temps de voir si un domaine te passionne et de laisser passer la crise …
Ce que j'ai dit c'est que le traitement des toutes les tâches n'est pas parallélisé dans ITK.
Par exemple lorsque l'on fait du recalage d'images avec un algorithme de descente de type gradient stochastique le temps principale se passe dans les itérations, celles-ci ne sont pas parallélisées, il ne serait pas trop difficile de le faire.
De plus le "solver" du système ne tourne que sur un cœur, et ce temps peut être assez long.
S'il est vrai que je n'ai pas fait tous les tests avec ITK4, j'avais vraiment essayé avec ITK3.
De plus ITK est une bibliothèque difficile à faire évoluer pour un non informaticien car tout est encapsulé, alors qu'il est facile avec CIMG de créer ses propres classes utilisant des opérateurs mathématiques aussi complexe que l'on souhaite, ce qui est plus adapté à ce que l'on fait. Nous avons ainsi pu implémenter toutes les boucles critiques en OpenMP ce qui nous permet de bien exploiter notre HPC (on aurait pu faire encore mieux en MPI !). Nous faisons de la métrologie, il n'est donc pas vraiment acceptable pour nous de ne pas utiliser tous les échantillons (random sampler). Nous devons donc prévoir un système permettant de gérer les données issues d'un micro-tomographe ce qui peut aller jusqu'à 4000x4000x4000 en ne sous échantillonnant pas.
Alors certes on aurait pu tout faire avec ITK, mais cette bibliothèque ne semblait pas la plus adaptée pour pouvoir permettre à des non-informaticiens de la faire évoluer.
J'utilise ITK tous les jours au travers d'Elastix et en suis satisfait, mais ça ne correspond pas à tous les besoins. Pour le cas spécifique des du recalage d'images sur des gros volumes sans sous-échantillonnage ce n'est pas adapté. Et nous n'avons pas le niveau pour la faire évoluer.
Encore une fois il est fort dommage de s'énerver de la sorte. Si j'ai fait une erreur je suis prêt à le reconnaître, mais dans ce cas donnez moi quelque chose à me mettre sous la dent comme un lien, plutôt de m'accuser d'incompétence, c'est n'est pas des manières.
numexpr est compris dans pytables, cela permet d'avoir des résultats vraiment intéressant car c'est plutôt orienté sur l'aspect optimisation de la mémoire. Penses tu qu'il sera possible à terme de pouvoir utiliser les outils de pytables avec pythran.
ITK n'est pas parallélisée sur toutes ses fonctionnalités et loin de là, il y a par exemple la tâche lourde du recalage d'images qui n'est pas du tout parallélisée.
Il n'y a pas à ma connaissances de bibliothèques en analyse d'images qui permettent d'avoir un niveau d'abstraction simple pour le non informaticien professionnel et parallèle.
Il est tout à fait possible de faire du parallèle avec cimg par exemple et openmp. Nous le faisons au labo (UMR aussi …).
J'ai essayé d'importer du SVG, histoire de voir ce que l'on peut faire, et je n'ai pas réussi. Il semble que ça soit supporté depuis quelques versions, mais pas de menu importé. Il est tout à fait possible que je sois un gros manche et que j'ai raté une option évidente, mais je n'ai pas réussi…
Il serait fondamental d'avoir le format SVG comme format d'import/export d'animations simples. Cela permettrait d'exploiter les navigateurs webs pour des animations simples comme plus complexes.
Je pense que beaucoup de gens intéressés par ce logiciel ne sautent pas le pas car la phase d'apprentissage est longue et si c'est pour faire un avi au final, c'est un peu dommage.
Ce logiciel est vraiment sympa, il me permet de me connecter sur à peu prêt tout eduroam, le wifi chez moi (ça heureusement …) les réseaux filaire en DHCP et IP fixe et bien d'autres. Il n'y a qu'un seul point que je trouve dommage : on se connecte généralement à un point d'accès avec des configurations données comme le proxy, dans Android, le proxy peut se configurer dans les paramètres avancés de la connexion, je trouve vraiment dommage que ça ne soit pas le cas dans NetworkManager, qui ne propose pas cette fonctionnalité !
Si quelqu'un a réussi à trouver une solution pour paramétrer graphiquement son proxy lors de la connexion je suis preneur.
Je n'avais jamais réussi à utiliser une bibliothèque OpenSource pour gérer des caméras genicam/GigE. Il me semble que dans le cas de GigE il faut signer un NDA pour accéder au protocole non ?
Voilà c'était assez juste, mais ils ont réussi à financer leur projet. Il y aura donc bientôt une tablette avec tous les driver Linux, sauf probablement l’accélération vidéo.
C'est un peu différent tout de même. Dans ce que tu fais tu définis une grille de type différence finies à la taille du pixel, et tu régularises en pénalisant une énergie de type laplacien du déplacement, ce qui évites d'avoir des fortes variations du déplacement. Nous avons implémenté un technique basée sur les éléments finis, qui assure une interpolation bilinéaire par élément avec une grille de taille allant de 16x16 à 64x64 (en général), il y a dans ce cas moins besoin de pénaliser l’énergie associée à l'image.
Pour expliquer un peu le problème de manière plus générale, associer déplacement et images est un thème abordé par plusieurs communautés.
Les pionnier sont la mécanique des fluide avec la Particule Image Velocimetry :
Il s'agit d'observer des particules et de prendre deux images successives à des temps très courts. La technique classique consiste à prendre des petites fenêtres et à chaque fenêtre rechercher le déplacement de corps rigide qui entraîne la meilleur corrélation entre les deux imagettes. Comme le déplacement est pris entre deux temps très courts on peut avoir une image fidèle de la vitesse. On notera le logiciel libre osiv http://osiv.sourceforge.net/ ainsi que jpiv http://www.jpiv.vennemann-online.de/ qui répondent à cette problématique
On appelle cette méthode en mécanique des solides déformables, Digital Images Correlation. La différence principale vient du fait que les images sont prises avec des temps plus grands entre deux images successives. On a donc des déplacements. Beaucoup de techniques sont identiques à celles de la PIV. On ne s’intéresse toujours pas au recalage entre l'image initiale et l'image finale. Il n'existe pas chez nous de Logiciels Libre pour répondre à ce besoin, mais ceux de la PIV fonctionnent bien.
A noter que les techniques utilisant le flot optique sont aussi couramment utilisées sur des imagettes, il existe une communauté en analyse d'images qui utilise massivement ces méthodes, on peut se référer à l'implémentation de l'algorithme de Lucas-Kanade dans OpenCV (https://code.ros.org/trac/opencv/browser/trunk/opencv/samples/c/lkdemo.c?rev=1429) pour plus de détails.
Il y a eu en 2006 l'apparition de méthodes appelées globales, qui sont celles que j'ai expliqué au début. Dans ces méthodes on recale l'image finale sur l'image initiale. Elles sont également basées sur le flot optique, mais c'est sur toute l'image que s'opère la minimisation et non sur une imagette.
Dans la communauté d'imagerie médicale, il existe depuis bien plus longtemps (1995) des techniques appelées Image Registration (ou recalage d'images), qui cherchent à rendre le plus semblables possible deux images en déformant l'image finale. Il y a plusieurs catégories, le recalage rigide, on l'on cherche à trouver la meilleurs translations et rotations (en 2D ou 3D) le recalage par similarité (on cherche le grossissement en +), il y a ensuite ce qui s'appelle le recalage déformable ou élastique. Il existe beaucoup de logiciels libres permettant de faire du recalage d'images, le plus complet est elastix (http://elastix.isi.uu.nl/) là où nous utilisons une base élément finis pour les déplacements ils utilisent des BSplines. Il existe également plastimatch (http://plastimatch.org/) qui a moins d'options que elastix ne fonctionne qu'en 3D mais est massivement // peut faire du OpenMP ou du Cuda ce qui le rend dans ce contexte très intéressant.
De notre cotés nous essayons de développer une plate-forme permettant de balayer tout ces domaines avec la contrainte de tout penser pour que ce soit massivement // du fait de l'arrivée prochaine d'un µtomographe qui nous permettra d'avoir ds images de 2000³ ce qui est infaisable aujourd'hui sur un laptop. et prend beaucoup de temps sur des machines performantes ou des HPC si ce n'est pas parallélisé.
Je rebondirais également sur l’aspect données, nous essayons également de travailler le plus possible avec netCDF car il permet d'avoir des données pérennes d'acceder aux fichiers en // et de stocker beaucoup plus que des pixels.
J'encadre un post-doc qui a developpé un protoype de PIV/DIC/"recalage d'image" en 2D en utilisant cimg. Son travail est basé sur l'estimation du flot optique global en utilisant des éléments bilinéaire. Cela ressemble un peu à ce qui est fait ici ftp://ftp-sop.inria.fr/athena/Team/David.Tschumperle/CImg/examples/optflow.c
tout est fait en GPL, cela peut évidemment être partagé.
Je croyais aussi que PLUME avait comme objectif de populariser les logiciels libres dans la recherche et l'enseignement supérieur. En fait ce n'est pas vraiment le cas, c'est aussi une chambre d'enregistrement de logiciels propriétaires mais fait par des instances publiques, telles que les laboratoires de recherche. Je prendrais au hasard une page : https://www.projet-plume.org/fr/relier/seal
Il n'est fait nul part état de la licence utilisée, aucune page de référence ni même une adresse de téléchargement.
Il faut comprendre que les laboratoires sont aujourd'hui également évalués sur leur rayonnement et plume permet un très bon référencement, je pense donc que cet outil a été détourné. Il n'a aujourd'hui aucun rapport avec un annuaire tel que framasoft qui référence uniquement des LL.
J'y ai participé fut un temps, mais ce virage m'a fait arrêter mes contributions.
En fait c'est assez pratique de pouvoir faire ses présentations en LaTeX, on peut y inclure des vidéos. Il est possible sous Windows de les lire avec acroread, mais la la version linux n'a pas cette fonctionnalité. Il est donc vraiment intéressant de pouvoir le faire avec okular. Ça ne concerne peut être pas grand monde, mais ceux que ça concernent sont ravis !
Franchement, cela commence à bien faire ces images de belles femmes n'ayant aucun rapport avec quoi que ce soit de libre. Cautionner la femme objet ne rend pas ce site meilleur. Alors certes on n'est pas obligé de cliquer, certes, on a le droit d'aimer les belles femmes, mais je ne pense pas que ce site ait à gagner quoi que ce soit là dedans. Cela donne une image de nerd n'ayant jamais vu une femme de prêt qu'en 2D.
Il y a de plus certainement de très bon sites de ce type qui apprécieraient ces Nimages à leur jute valeur.
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.
Le principe de l'insight journal est exactement celui-ci. Ils défendent l'idée qu'il est nécessaire de pouvoir vérifier les articles par soi-même.
Les personnes à l'origine de cette revue sont des acteurs majeurs de la visualisation scientifique avec les lib VTK et ITK, et le logiciel paraview. Il existe donc bien aujourd'hui des exemples de cette démarche et je m'en félicite !
[^] # Re: Ca marche avec Linux ??
Posté par freejeff . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 1.
Non en fait c'est beaucoup plus basique.
On compile tout avec les libs system, dont openmp, mpi, fftw3, ….
Compiler en static de Linux vers Linux demande de refaire tout le travail de makefile toute la compilation en local de toutes tes bibliotheques, si son systeme permettait de tout installer en local pour un packaging en local ca eviterait un boulot d'informaticien qui n'est pas vraiment le miens …
Quand a ton lien sur les les bibliotheaues partagees, c'est justement le probleme … je ne sais pas ce que j'aurai lorsque j'arriverai. Par exemple la j'ai envoye deux semaines a l'avance ma demande d'installation de lib, mais non il n'avaient pas les RH pour le faire, ce que je peux comprendre. donc on arrive et tout a La Rache, on y arrive mais on perd du temps alors a 10k euros par journee c'est un peu la loose.
je sais que j'aurais un linux 64 bits sans droits d'admin.
Voila les contraintes …
Apres c'est un pb de genie logiciel, je ne suis pas expert …
# Ca marche avec Linux ??
Posté par freejeff . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 1.
Salut,
je ne suis pas tres au point avec tout cela mais j'en aurais vraiment besoin.
Nous avons fait un projet ou nous utilisons des libs bas niveau comme openmp,mpi,fftw3,…
On les a toutes installees en dynamic sous nos machines, mais nous devons utiliser ce programme dans des endroits ou nous ne pouvons etre root, genre accelerateur de particules.
Du coup si je pouvais avoir un bon gros executable ou alors un repertoire qui contient tout et que je peux lancer en local en gerant des variables d'environnement alors cela nous aideriait beaucoup. J'utilise ce Code en ce moment a l'Institut Paul Scherrer et j'ai vriament eu de la chance que les admins soient sympa.
Donc si une telle chose est possible sous linux j'en serais ravi !
Si tout ceci est trivial a faire n'hesitez pas a me le dire !
[^] # Re: Rien de transcendant au final ... et GMA 600 ?
Posté par freejeff . En réponse au journal Minnow Board. Évalué à 6.
J'ai essayé de vérifier et apparemment tu as raison !
Il n'y aura pas de drivers libres de chez Intel permettant d'exploiter la puce de décodage, l'accélération 2D et 3D. Du coup je trouve cette carte vraiment moins intéressante.
C'est bien dommage.
Je pense que leur idée est d'aller sur le terrain de la beagle board et de son DSP qui permet de faire pas mal de choses, mais du coup pas d'accès à VA-API.
Je suis déçu, cela m'apprendra à aller voir les spec des composants avant de poster …
[^] # Re: Rien de transcendant au final ...
Posté par freejeff . En réponse au journal Minnow Board. Évalué à 3.
Ce n'est pas transcendant certes.
Mais par rapport à ce que tu proposes, il y a le giga ethernet et surtout un driver graphique inclue dans le noyau. Il me semble que c'est le plus gros problème aujourd'hui.
Donc au final si ça ne révolutionne pas grand chose c'est tout de même très intéressant.
[^] # Re: PC
Posté par freejeff . En réponse au journal Minnow Board. Évalué à 2.
Oui je pense que c'est l'idée, mais l'atout principale est pour moi le fait de donner l’accès aux GPIO et autres bus sans passer par la complexité qu'il y a dans tout le monde ARM. Du coup c'est assez simple de se faire une petite carte que fait de la conversion analogique numérique en SPI ou I²C en utilisant IIO. Cela évite de devoir utiliser Comedi par exemple.
En ce qui concerne le prix. Si tu regardes combien coûte une carte CAN compatible Linux. C'est autour des 400€ chez Peak. La tu as une carte avec du CAN et avec un river directement inclue. Tu peux directement faire du socketCAN dans CAN Festival.
On est dans l'ordre de grandeur du prix d'une BeagleBoard par exemple.
Donc je pense que c'est plus qu'un PC (GPIO), et de l'ordre de grandeur du prix d'une BeagleBoard. C'est donc une outil assez intéressant.
[^] # Re: singularité de cette carte
Posté par freejeff . En réponse au journal Minnow Board. Évalué à 1.
Salut,
oui en effet ce n'est pas utile pour faire un routeur. Je pense que l'utilisation pour faire de l'embarqué facilement (genre domotique, régulation,…) grâce au GPIO ou alors faire une plateforme multimédia via le HDMI me semble tout à fait possible.
Le fait que le GPU soit de chez intel permet également d'avoir de très bonnes performances sur un linux.
Donc tu as raison, mais je ne pensais pas à cette cible.
# Problèmes de licence
Posté par freejeff . En réponse à la dépêche FreeCAD 0.13. Évalué à 6.
Ce projet est très intéressant et progresse régulièrement, ce qui ne semble pas être le cas de heekscad par exemple. Il est vraiment dommage que des problèmes de licences entre branches de la GPL ralentissent son bon développement. Le format DWG est un standard de fait, c'est un peu comme le .doc on peut le déplorer mais c'est un standard.
En ce qui concerne les avancées de FreeCAD, il ne manque plus que le module d'assemblage avec contraintes pour pouvoir vraiment envisager de développer avec !
Le gros point noir étant l'export en plans. Est il possible de rajouter de la cotation fonctionnelle ?
C'est vraiment remarquable d'avoir fait tant de progrès, j'espère que ça avancera vite. Je vais le faire tester à un des ingénieurs que j'encadre pour qu'il me dise ce qu'il lui manque. Il a toujours travaillé sur Catia où il a ses habitudes ce qui me permettra de faire un retour constructif à l'équipe de développement.
En tout cas bravo aux développeurs !
[^] # Re: ça dépend ...
Posté par freejeff . En réponse au journal Thèse or not thèse, that is the question.... Évalué à 5.
Bordel !
Il n'y a pas que Mdc, il y a aussi Ingé de recherche (vu que tu aimes pisser du code c'est ce qu'on leur demande), chargé de recherche au CNRS à l'INRIA à l'INSERM (oui aussi en info). Il faut arrêter de caricaturer.
C'est des postes passionnant avec des sujets variés et émulant qui permettent en plus de faire de la veille et de faire de l'OpenSource. Que vous faut il au juste ?
[^] # Re: La vraie question : que veux-tu faire après ta thèse ?
Posté par freejeff . En réponse au journal Thèse or not thèse, that is the question.... Évalué à 5.
Je ne suis pas du tout d'accord !
Je connais plein de gens (dont moi même) qui ont fait une thèse CIFRE et qui sont aujourd'hui dans le monde académique. Et ce que tu dis est complètement faux pour les grosses boites au CEA ils prennent les docteurs à des postes plus haut placés, chez EDF aussi chez SNECMA aussi, chez EADS également. Je trouve que les choses changent vraiment, au moins ça te laisse le temps de voir si un domaine te passionne et de laisser passer la crise …
[^] # Re: Deux questions
Posté par freejeff . En réponse à la dépêche Traitement d'image : Sortie de G'MIC 1.5.5.1. Évalué à 1.
Bonjour,
Je ne comprends pas Votre agressivité.
Ce que j'ai dit c'est que le traitement des toutes les tâches n'est pas parallélisé dans ITK.
Par exemple lorsque l'on fait du recalage d'images avec un algorithme de descente de type gradient stochastique le temps principale se passe dans les itérations, celles-ci ne sont pas parallélisées, il ne serait pas trop difficile de le faire.
De plus le "solver" du système ne tourne que sur un cœur, et ce temps peut être assez long.
S'il est vrai que je n'ai pas fait tous les tests avec ITK4, j'avais vraiment essayé avec ITK3.
De plus ITK est une bibliothèque difficile à faire évoluer pour un non informaticien car tout est encapsulé, alors qu'il est facile avec CIMG de créer ses propres classes utilisant des opérateurs mathématiques aussi complexe que l'on souhaite, ce qui est plus adapté à ce que l'on fait. Nous avons ainsi pu implémenter toutes les boucles critiques en OpenMP ce qui nous permet de bien exploiter notre HPC (on aurait pu faire encore mieux en MPI !). Nous faisons de la métrologie, il n'est donc pas vraiment acceptable pour nous de ne pas utiliser tous les échantillons (random sampler). Nous devons donc prévoir un système permettant de gérer les données issues d'un micro-tomographe ce qui peut aller jusqu'à 4000x4000x4000 en ne sous échantillonnant pas.
Alors certes on aurait pu tout faire avec ITK, mais cette bibliothèque ne semblait pas la plus adaptée pour pouvoir permettre à des non-informaticiens de la faire évoluer.
J'utilise ITK tous les jours au travers d'Elastix et en suis satisfait, mais ça ne correspond pas à tous les besoins. Pour le cas spécifique des du recalage d'images sur des gros volumes sans sous-échantillonnage ce n'est pas adapté. Et nous n'avons pas le niveau pour la faire évoluer.
Encore une fois il est fort dommage de s'énerver de la sorte. Si j'ai fait une erreur je suis prêt à le reconnaître, mais dans ce cas donnez moi quelque chose à me mettre sous la dent comme un lien, plutôt de m'accuser d'incompétence, c'est n'est pas des manières.
Cordialement,
# PyTables
Posté par freejeff . En réponse au journal avec Pythran, Numpy file comme le vent. Évalué à 1.
Salut,
numexpr est compris dans pytables, cela permet d'avoir des résultats vraiment intéressant car c'est plutôt orienté sur l'aspect optimisation de la mémoire. Penses tu qu'il sera possible à terme de pouvoir utiliser les outils de pytables avec pythran.
[^] # Re: Deux questions
Posté par freejeff . En réponse à la dépêche Traitement d'image : Sortie de G'MIC 1.5.5.1. Évalué à 1.
Bonjour,
ITK n'est pas parallélisée sur toutes ses fonctionnalités et loin de là, il y a par exemple la tâche lourde du recalage d'images qui n'est pas du tout parallélisée.
Il n'y a pas à ma connaissances de bibliothèques en analyse d'images qui permettent d'avoir un niveau d'abstraction simple pour le non informaticien professionnel et parallèle.
Il est tout à fait possible de faire du parallèle avec cimg par exemple et openmp. Nous le faisons au labo (UMR aussi …).
# Import SVG
Posté par freejeff . En réponse à la dépêche Synfig Studio aux Libre Graphics Meeting 2013. Évalué à 2.
J'ai essayé d'importer du SVG, histoire de voir ce que l'on peut faire, et je n'ai pas réussi. Il semble que ça soit supporté depuis quelques versions, mais pas de menu importé. Il est tout à fait possible que je sois un gros manche et que j'ai raté une option évidente, mais je n'ai pas réussi…
Il serait fondamental d'avoir le format SVG comme format d'import/export d'animations simples. Cela permettrait d'exploiter les navigateurs webs pour des animations simples comme plus complexes.
Je pense que beaucoup de gens intéressés par ce logiciel ne sautent pas le pas car la phase d'apprentissage est longue et si c'est pour faire un avi au final, c'est un peu dommage.
# fonctionnalité Android
Posté par freejeff . En réponse à la dépêche NetworkManager 0.9.8 propose la création de points d'accès. Évalué à 5.
Ce logiciel est vraiment sympa, il me permet de me connecter sur à peu prêt tout eduroam, le wifi chez moi (ça heureusement …) les réseaux filaire en DHCP et IP fixe et bien d'autres. Il n'y a qu'un seul point que je trouve dommage : on se connecte généralement à un point d'accès avec des configurations données comme le proxy, dans Android, le proxy peut se configurer dans les paramètres avancés de la connexion, je trouve vraiment dommage que ça ne soit pas le cas dans NetworkManager, qui ne propose pas cette fonctionnalité !
Si quelqu'un a réussi à trouver une solution pour paramétrer graphiquement son proxy lors de la connexion je suis preneur.
[^] # Re: À propos du choix des caméras CCD
Posté par freejeff . En réponse à la dépêche L'astronomie libre sous Linux : le point fin 2012, début 2013. Évalué à 2.
C'est super, je n'avais jamais vu ce projet !
Je n'avais jamais réussi à utiliser une bibliothèque OpenSource pour gérer des caméras genicam/GigE. Il me semble que dans le cas de GigE il faut signer un NDA pour accéder au protocole non ?
J'ai vu qu'il y avait plusieurs projets de ingénierie inverse sur ce sujet : https://gitorious.org/opengigevision/opengigevision et https://github.com/datenwolf/REgiGV
Sais tu comment Aravis se positionne vis à vis de ces projet ?
# Le projet a atteint ses objectifs
Posté par freejeff . En réponse au journal Pengpod : la dernière ligne droite. Évalué à 1.
Voilà c'était assez juste, mais ils ont réussi à financer leur projet. Il y aura donc bientôt une tablette avec tous les driver Linux, sauf probablement l’accélération vidéo.
[^] # Re: PIV
Posté par freejeff . En réponse à la dépêche G’MIC Online, le traitement d’image en ligne. Évalué à 6.
C'est un peu différent tout de même. Dans ce que tu fais tu définis une grille de type différence finies à la taille du pixel, et tu régularises en pénalisant une énergie de type laplacien du déplacement, ce qui évites d'avoir des fortes variations du déplacement. Nous avons implémenté un technique basée sur les éléments finis, qui assure une interpolation bilinéaire par élément avec une grille de taille allant de 16x16 à 64x64 (en général), il y a dans ce cas moins besoin de pénaliser l’énergie associée à l'image.
Pour expliquer un peu le problème de manière plus générale, associer déplacement et images est un thème abordé par plusieurs communautés.
Les pionnier sont la mécanique des fluide avec la Particule Image Velocimetry :
Il s'agit d'observer des particules et de prendre deux images successives à des temps très courts. La technique classique consiste à prendre des petites fenêtres et à chaque fenêtre rechercher le déplacement de corps rigide qui entraîne la meilleur corrélation entre les deux imagettes. Comme le déplacement est pris entre deux temps très courts on peut avoir une image fidèle de la vitesse. On notera le logiciel libre osiv http://osiv.sourceforge.net/ ainsi que jpiv http://www.jpiv.vennemann-online.de/ qui répondent à cette problématique
On appelle cette méthode en mécanique des solides déformables, Digital Images Correlation. La différence principale vient du fait que les images sont prises avec des temps plus grands entre deux images successives. On a donc des déplacements. Beaucoup de techniques sont identiques à celles de la PIV. On ne s’intéresse toujours pas au recalage entre l'image initiale et l'image finale. Il n'existe pas chez nous de Logiciels Libre pour répondre à ce besoin, mais ceux de la PIV fonctionnent bien.
A noter que les techniques utilisant le flot optique sont aussi couramment utilisées sur des imagettes, il existe une communauté en analyse d'images qui utilise massivement ces méthodes, on peut se référer à l'implémentation de l'algorithme de Lucas-Kanade dans OpenCV (https://code.ros.org/trac/opencv/browser/trunk/opencv/samples/c/lkdemo.c?rev=1429) pour plus de détails.
Il y a eu en 2006 l'apparition de méthodes appelées globales, qui sont celles que j'ai expliqué au début. Dans ces méthodes on recale l'image finale sur l'image initiale. Elles sont également basées sur le flot optique, mais c'est sur toute l'image que s'opère la minimisation et non sur une imagette.
Dans la communauté d'imagerie médicale, il existe depuis bien plus longtemps (1995) des techniques appelées Image Registration (ou recalage d'images), qui cherchent à rendre le plus semblables possible deux images en déformant l'image finale. Il y a plusieurs catégories, le recalage rigide, on l'on cherche à trouver la meilleurs translations et rotations (en 2D ou 3D) le recalage par similarité (on cherche le grossissement en +), il y a ensuite ce qui s'appelle le recalage déformable ou élastique. Il existe beaucoup de logiciels libres permettant de faire du recalage d'images, le plus complet est elastix (http://elastix.isi.uu.nl/) là où nous utilisons une base élément finis pour les déplacements ils utilisent des BSplines. Il existe également plastimatch (http://plastimatch.org/) qui a moins d'options que elastix ne fonctionne qu'en 3D mais est massivement // peut faire du OpenMP ou du Cuda ce qui le rend dans ce contexte très intéressant.
De notre cotés nous essayons de développer une plate-forme permettant de balayer tout ces domaines avec la contrainte de tout penser pour que ce soit massivement // du fait de l'arrivée prochaine d'un µtomographe qui nous permettra d'avoir ds images de 2000³ ce qui est infaisable aujourd'hui sur un laptop. et prend beaucoup de temps sur des machines performantes ou des HPC si ce n'est pas parallélisé.
Je rebondirais également sur l’aspect données, nous essayons également de travailler le plus possible avec netCDF car il permet d'avoir des données pérennes d'acceder aux fichiers en // et de stocker beaucoup plus que des pixels.
[^] # Re: PIV
Posté par freejeff . En réponse à la dépêche G’MIC Online, le traitement d’image en ligne. Évalué à 3.
Bonjour,
J'encadre un post-doc qui a developpé un protoype de PIV/DIC/"recalage d'image" en 2D en utilisant cimg. Son travail est basé sur l'estimation du flot optique global en utilisant des éléments bilinéaire. Cela ressemble un peu à ce qui est fait ici ftp://ftp-sop.inria.fr/athena/Team/David.Tschumperle/CImg/examples/optflow.c
tout est fait en GPL, cela peut évidemment être partagé.
[^] # Re: Orthographe et grammaire
Posté par freejeff . En réponse au journal Pourquoi je suis libriste intégriste.. Évalué à 8.
Vos commentaires m'amusent beaucoup, j'apprends des nouveaux mots chaque fois.
[^] # Re: Projet PLUME
Posté par freejeff . En réponse au journal Petit Annuaire de Logiciels libres. Évalué à 4.
Je croyais aussi que PLUME avait comme objectif de populariser les logiciels libres dans la recherche et l'enseignement supérieur. En fait ce n'est pas vraiment le cas, c'est aussi une chambre d'enregistrement de logiciels propriétaires mais fait par des instances publiques, telles que les laboratoires de recherche. Je prendrais au hasard une page : https://www.projet-plume.org/fr/relier/seal
Il n'est fait nul part état de la licence utilisée, aucune page de référence ni même une adresse de téléchargement.
Il faut comprendre que les laboratoires sont aujourd'hui également évalués sur leur rayonnement et plume permet un très bon référencement, je pense donc que cet outil a été détourné. Il n'a aujourd'hui aucun rapport avec un annuaire tel que framasoft qui référence uniquement des LL.
J'y ai participé fut un temps, mais ce virage m'a fait arrêter mes contributions.
[^] # Re: Vidéos dans les PDF
Posté par freejeff . En réponse à la dépêche KDE 4.9 est sorti. Évalué à 8.
En fait c'est assez pratique de pouvoir faire ses présentations en LaTeX, on peut y inclure des vidéos. Il est possible sous Windows de les lire avec acroread, mais la la version linux n'a pas cette fonctionnalité. Il est donc vraiment intéressant de pouvoir le faire avec okular. Ça ne concerne peut être pas grand monde, mais ceux que ça concernent sont ravis !
[^] # Re: j'avais oublié
Posté par freejeff . En réponse au journal RPM de wmcoincoin 2.5.1f dispo . Évalué à -2.
Franchement, cela commence à bien faire ces images de belles femmes n'ayant aucun rapport avec quoi que ce soit de libre. Cautionner la femme objet ne rend pas ce site meilleur. Alors certes on n'est pas obligé de cliquer, certes, on a le droit d'aimer les belles femmes, mais je ne pense pas que ce site ait à gagner quoi que ce soit là dedans. Cela donne une image de nerd n'ayant jamais vu une femme de prêt qu'en 2D.
Il y a de plus certainement de très bon sites de ce type qui apprécieraient ces Nimages à leur jute valeur.
C'était un message du comité contre les Nimages.
# 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.
[^] # Re: Macros et (Common) Lisp
Posté par freejeff . En réponse à la dépêche Version 1.0 de Julia. Évalué à 0.
en python numpy:
A=[1,2,3,4]
print A[::-1]
en octave, matlab, (scilab,julia ?)
A=[1,2,3,4]
disp(A(end:-1:1))
Ou peut être ai je mal compris ?
# http://www.insight-journal.org/
Posté par freejeff . En réponse au journal L'open source, un gage de reproductibilité en science. Évalué à 6.
Le principe de l'insight journal est exactement celui-ci. Ils défendent l'idée qu'il est nécessaire de pouvoir vérifier les articles par soi-même.
Les personnes à l'origine de cette revue sont des acteurs majeurs de la visualisation scientifique avec les lib VTK et ITK, et le logiciel paraview. Il existe donc bien aujourd'hui des exemples de cette démarche et je m'en félicite !
Mes 2 centimes