A une époque (lointaine 1 an ou 2) cela ne marchait plus avec le graphique, j'étais bien content de le rentrer en dur au démarrage pour ma chère et tendre.
La nouvelle version xM étant plus puissante, en couplant le boiter de ton père, je pense que tu tiens là quelque chose. Si tu plus tu rajoutes Logram pour l'interface alors tu es vraiment innovant !
Faux ! Tu peux aussi te servir des metafichiers GDI, il te permettent de garder la mise en forme de l'origine vers la destination, et peuvent te permettre de redimensionner simplement. Il est vrai que pour les tableaux, ce n'est jamais évidents de les avoir propres depuis calc, donc c'est une bonne nouvelle d'avoir une macro pour
si les diagrammes sont très simples alors pas de pbs, mais s'ils sont plus complexes alors c'est le drame.
Par contre OOo gère parfaitement le PS, qui peu être exporté sans compression, il devient alors assez simple de chercher un champs dedans et de le modifier avec sed ou autre.
Je pense qu'il manque vraiment aujourd'hui un outil performant pour traiter un flux d'images tel qu'un film. Penses tu qu'il y aurait un intérêt à intégrer Gstreamer en tant que moyen d'entrée de vidéos, je m'explique.
Il existe tout un tas de pipeline possible dans gstreamer qui permettent d'acquérir des flux (mms, rtsp, file, v4l2) pour la video et le son. pouvoir utiliser cimg Cimg et G'MIC via une suite de pipe bien choisis permettrait vraiment de toucher par exemple le monde de la video.
Je sais que OpenCv a déjà commencé ce travail, mais les résultats me semblent encore limités (gros bugs sur les flux rtsp).
Dans ce cadre il y aurait deux stratégies, soit inclure gstreamer comme source de données, soit faire un plugin de G'MIC. Les deux on des avantages et des incovénients. Personnellement je trouve que gstreamer est super mais un peu trop usine à gaz, je préferais donc pouvoir utiliser directement gstreamer depuis G'MIC ou EKD.
Je pense qu'il veut dire que si tu fais la promotion autour de toi et que cela marche, alors les gens mettront à jour les données, mais ça ne sera pas "officiel".
Pour avoir discuté de ce sujet avec des scientifiques que je respecte, il y a deux critiques qui sont émises face à un tel système.
1) Ces revues sont elles impactées au sens ISI web of knowledge ?
Il faut savoir que l'avancement d'un chercheur se fait en France principalement via l'indice de Hirsch, pour faire augmenter cet indice il faut que la revue ait un facteur d'impact non nul, celui ci étant évalué par the Institute for Scientific Information (ISI). Les jeunes chercheurs ont clairement une pression, car l'AERES (Agence d’évaluation de la recherche et de l’enseignement supérieur) tend à faire une évaluation de plus en plus personnelle (comprendre que bientôt chaque chercheur sera évalué). Il est donc très difficile pour eux de choisir une revue non impactée au sens ISI.
2) N'y a il pas un conflit d'intérêt ?
Plusieurs chercheurs sont intimement convaincus qu'une revue qui fait payer les auteurs (ou les institutions) à l'article aura tout intérêt à accepter le plus d'articles possible pour augmenter son budget. Qu'en est il du tau de rejet des articles publiés dans ces revues ?
Ne t'y trompe pas, je suis autant outré que toi du système en place qui semble complètement fou, on donne beaucoup trop à ces éditeur commerciaux, mais la question de savoir comment sortir de ce système sans sacrifier sa carrière et un vrai problème. La question de comment valider la qualité d'une revue "libre" est dans cette optique complètement fondamentale.
Sinon, je trouve que c'est une excellente nouvelle !
Comme le disait Djnet dans son commentaire, il est possible de recharger des piles soit disant "non rechargeables" de plus sans fer à souder.
J'ai acheté, il y a un, un chargeur s'appelle batboostor et j'en suis satisfait.
L'idée de base de ce dispositif est de considérer l'aspect transitoire du transfert thermique en ne chargeant pas en continu, on évite ainsi l'accumulation des problèmes liés à l'augmentation de la température dans la cinétique de rechargement.
Une documentation exposant des résultats en laboratoire est disponible à cette adresse : http://bioenergies.free.fr/mes_documents/batbooster.pdf
S'il faut citer une limitation d'un tel système je dirais qu'il est assez complexe d'utiliser des piles déchargées depuis longtemps, il devient donc délicat de recharger des piles issues de
la récupération (bien que j'ai déjà joué à ce jeu avec un succès mitigé). Les piles peuvent couler si celles que l'on tente de recharger sont trop vielles.
Il est possible de recharger des piles neuves (entendre qui viennent d'être déchargées) une quinzaine de fois, sachant qu'un phénomène de demie vie apparait ce qui contraint in fine à l'abandon des piles au bout de ces utilisations.
Dans de telles conditions il devient urgent de réfléchir à l'achat de batteries rechargeables, car on peut ainsi diminuer par ~10 le coût de piles "non rechargeables".
La société ayant inventé ce procédé est française et se nomme alphysis-AES, mais elle ne semble plus exister et on peut lire sur certains sites que la société JADE a pris le relai.
N'étant pas un spécialiste électrochimie je ne serais me prononcer plus que ce que je vous ai exposé sur ce sujet, je peux juste donner mon expérience d'utilisateur lambda à savoir que ce procédé m'a déjà éviter beaucoup d'achat de piles.
Depuis quelque temps la communauté scientifique tend à utiliser de plus en plus les unités graphiques pour le calcul scientifique. Cette technique est extrêmement adaptée lorsque le problème à traiter peut simplement se décomposer en sous problèmes. Il me semble qu'une bonne partie de l'analyse d'image respecte cette contrainte. Il serait donc vraiment intéressant d'avoir accès à un outil tel que G'MIC utilisant nos GPU.
N'étant pas un spécialiste de la compilation, je ne peux pas réellement savoir comment s'y prendre pour atteindre un tel but, mais il me semble que OpenCL est basé sur LLVM, donc peut être qu'un première étape serait de parvenir à compiler G'MIC via LLVM et clang ?
Si j'évoque ce problème c'est parce que j'aimerais d'ici 1 ou 2 ans être capable de faire du traitement d'image en temps réel dans une optique de contrôle de machines expérimentales, bien que je sache qu'il existe OpenCV qui implémente déjà beaucoup d'algos, son architecture ne me convient pas toujours c'est pour cela que j'aimerais parfois utiliser un autre framework.
J'ai vu qu'il existait PANDORE, et que tu travailles dessus, aussi je me demande si pandore peut profiter des évolutions de Cimg/G'MIC, et me pose la question de savoir pourquoi ne pas avoir utilisé OpenCV.
Je serais donc vraiment intéressé par utiliser ces outils, mais j'ai besoin de pouvoir les situer dans les outils existant.
Depuis quelque temps la communauté scientifique tend à utiliser de plus en plus les unités graphiques pour le calcul scientifique. Cette technique est extrêmement adaptée lorsque le problème à traiter peut simplement se décomposer en sous problèmes. Il me semble qu'une bonne partie de l'analyse d'image respecte cette contrainte. Il serait donc vraiment intéressant d'avoir accès à un outil tel que G'MIC utilisant nos GPU.
N'étant pas un spécialiste de la compilation, je ne peux pas réellement savoir comment s'y prendre pour atteindre un tel but, mais il me semble que OpenCL est basé sur LLVM, donc peut être qu'un première étape serait de parvenir à compiler G'MIC via LLVM et clang ?
Si j'évoque ce problème c'est parce que j'aimerais d'ici 1 ou 2 ans être capable de faire du traitement d'image en temps réel dans une optique de contrôle de machines expérimentales, bien que je sache qu'il existe OpenCV qui implémente déjà beaucoup d'algos, son architecture ne me convient pas toujours c'est pour cela que j'aimerais parfois utiliser un autre framework.
J'ai vu qu'il existait PANDORE, et que tu travailles dessus, aussi je me demande si pandore peut profiter des évolutions de Cimg/G'MIC, et me pose la question de savoir pourquoi ne pas avoir utilisé OpenCV.
Je serais donc vraiment intéressé par utiliser ces outils, mais j'ai besoin de pouvoir les situer dans les outils existant.
Il me semble de plus que même si linux est un noyau "généraliste", sa base est massivement utilisée dans l'embarqué avec les processeur arm de type 7, 9 et cortex A8. Je sais qu'il y a quelques changements, mais ça n'en est pas moins un linux.
Ça fait longtemps que je me pose la question, mais est ce qu'il existe une pile usb préemptive ?
Sans vouloir dire de bétises, il me semble que Ingo Molnar a introduit la possibilité d'avoir une version RT d'un noyau classique avec l'option CONFIG_PREEMPT_RT (Attention, je ne saurais être précis la dessus) appelée "hard-realtime scheduling". Cette option permet notament aux gens faisant de l'audio de réduire drastiquement la latence. Je citerai Linus :
"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." -- Linus Torvalds
J'ai utilisé de manière tout à fait satisfaisante le noyau packagé par debian linux-rt dans le cadre d'une version d'ubuntu-studio avec des cartes d'acquisitions PCI, mais je n'ai jamais eu de bons résultats (voir bien pire qu'avec la version classique du noyau) avec une carte usb.
Il semble que cette pile (je ne sais pas si ce terme convient, j'aurais a priori dit "driver" sans conviction) ne soit pas capable de fonctionner sans aberrations i.e : valeur d'acquisitions erratiques, j'avais trouvé USB4RT, mais ça date de 2005 et le patch de Ingo n'a été introduit qu'à partir de fin 2007 !
Je me permets donc (vu que c'est LA news ou je peux le faire) de demander aux gens qui sont un peu plus dans la technicité que moi s'ils connaissent des moyens de faire de l'USB en RT, et si oui est il possible de le faire sans un gros hack condamnant le pc à ne plus subir aucune mis à jour.
Est-ce que quelqu'un a déjà vu ça passer ce sujet sur la LKML (oui, je sais, je pourrais chercher moi même), suis-je le seul à me poser cette question ?
Pour info la granularité temporelle que j'ai réussi à atteindre sur une carte PCI est de l'ordre de 100 kHz stable (limite de la carte d'acquisition) sans buffer et de 1 kHz avec des erreurs en USB.
Dans tous les fichiers vectoriels tu peux inclure des png. Il n'est de plus pas forcément nécessaire d'avoir des textures très définies pour les gradients de couleurs par exemple, car lors de l'affichage d'une image tu peux décider d'interpoler les pixels. Il est donc tout à fait possible d'avoir des objets vectoriels avec des textures bitmaps, tu peux également inclure différentes résolutions et switcher de l'une à l'autre en fonction du zoom.
Donc il me semble possible de faire déjà pas mal de choses !
Ce que tu décris existe déjà et cela s'appelle la frankencamera. Ce n'est pas encore un produit industrialisable, mais les résultats semble assez intéressants : http://graphics.stanford.edu/projects/camera-2.0/
Si je devais apporter une critique sévère sur ce projet, c'est l'attitude des auteurs. Ils sont partis sur une base de caméra elphel, l'ont modifiée avec l'aide des concepteurs de cette caméra et ne les ont pas cités. Ils n'ont de plus pas forcément publié leurs développement alors qu'ils partaient d'un projet OpenSource. Je pense donc que ce projet a le mérite d'exister mais que les projets d'Elphel sont bien plus intéressant.
En ce qui me concerne, pour la vision par ordinateur j'ai deux stratégies différentes. La première lorsque je n'ai pas besoin de plus d'une image par seconde alors je passe par un appareil photo numérique reflex, ce qui me permet de récupérer les fichiers bruts de les convertir aux mieux et de profiter de gphoto2 pour pouvoir piloter entièrement mon appareil, du réglage du temps d'intégration jusqu'à l'ouverture du diaphragme en passant par l'ISO ...
Jusqu'à présent lorsque j'avais besoin de plus d'images par seconde je n'avais pas de solutions simples. Il existe bien une norme de carte d'acquisition dédiée à l'imagerie avec la définition d'une liaison série ad hoc, nommée cameralink, mais cette norme n'a spécifiée que le tuyau et pas la manière de transférer les données, résultats chaque constructeur gère comme il l'entend son pilotage de caméra. Pour utiliser ce type de caméra il faut un "framegrabber", nos amis de chez NI (National Instrument) ont une très forte présence sur ce secteur (Carte et logiciels NI vision) , mais ils ont décidé de ne pas supporter linux, donc si un labo a ce type de carte et s'il veut continuer d'utiliser ses caméras, mais cette fois sur linux, alors il est obligé de changer de cartes ! De plus même s'il existe des SDK pour linux, aucun n'est opensource, pour aucune carte que je connaisse (si vous en connaissez je suis preneur). Depuis quelques années la norme GigE/gencam permet de parler à toutes les caméras de ce type de manière transparente à partir du moment ou un fichier xml contenant les caractéristiques a été renseignées. C'est extrêmement prometteur ! Reste qu'en terme de flux de données cette interface reste légèrement inférieure à ce que l'on peut trouver en caméralink, et comme les labos ont tendance à n'acheter qu'en fonction des caractéristiques du matériel ce sytème n'a pas encore vraiment pénétré le monde scientifique (en tout cas celui que je fréquente).
D'un autre cotés en OpenSource OpenHardware, on a Elphel qui a fait plusieurs caméras avec une interface ethernet classique, mais avec des FPGA et un processeur ARM, ce qui leur permet de traiter les images de manière intelligente avant de les envoyer vers le pc hôte. Il sont en ce moment en train de développer une carte GigE qui permettra à terme de faire passer un flot de données très important. Un autre intérêt pour les personnes intéressées réside dans la modularité de leurs solutions, en effet, vous pouvez choisir une "carte capteur" parmi plusieurs existantes, vous pouvez rajouter une carte entrées/sorties permettant de synchroniser de manière très fines plusieurs caméras entre elles.
J'ai commandé une caméra, qui ne devrait pas tarder à arriver, une fois que j'aurais un workflow opérationnel, je rédigerais certainement une dépêche expliquant en détail tout ça.
Donc pour conclure, je pense que les choses avancent bien pour le monde OpenSource dans le domaine de la vision et j'espère que ça continuera dans ce sens.
Je trouve ça très intéressant que tu décide ce qui de l'utilité ou pas, mais laisses moi maître de décider ce qui fait sens par moi même.
Je n'ai jamais dit qu'il n'y avait pas de différence, il est bien évident que si tu photographie une scène avec un très importante variation de lumière alors plus ta dynamique sera grande et mieux se passeront les choses. Il existe tout un tas de cas où cette dynamique n'apportera que peu de plu-value à ta photo, par contre la différence de taille est elle fort signifiante quelle que soit l'image. Ce que je soulignait était le fait que prendre une image en raw la tranformer en tiff, ajuster les contrastes globalement et l'exporter en jpeg peut donner de moins bon résultats que prendre directement le fichier en jpeg. Tu fais peut être partie des passionnés qui ne prennent qu'une photo en une heure en maîtrisant tous les paramètre de ton boitier et objectifs, je t'en félicite, mais lorsque je prends un centaine d'images en une semaine de vacance, alors les trois ou 4 heures qu'il va me falloir pour bien convertir analyser les images pour enfin les archiver me semblent fastidieuses. Je suis cependant capable de prendre des images en raw lorsque les conditions me semblent sévère ...
Pour ceux qui se persuade de pouvoir juste en derawtisant faire mieux que le jpeg d'un boitier, je vais vous expliquer un point intéressant.
Lorsque j'ai commencé à faire de la photo scientifique sous linux, j'ai tout d'abors utilisé dcraw, car celui-ci permet de se rapprocher le plus du capteur (dcraw -4 -T -D), il m'était de me fabriquer l'image en niveau de gris qui m'intéressait.
Plus tard j'ai découvert libopenraw, nous avons fait un programme en C++ avec et nous sommes rendu compte que nous récupérions plus de pixels qu'avec dcraw. En fait nous recupérions des pixels sur le bord du capteur. J'ai passé un peu de temps à analyser ces pixels et me suis rendu compte qu'il y avait des zones où le capteur est masqué, pour mesurer le bruit thermique et d'autres où il y avait une évolution non linéaire de l'intensité en fonction d'une direction du capteur. En cherchant un peut j'ai constaté que ces courbes étaient au nombre de trois et très proche de : http://luminance.londonmet.ac.uk/webhdr/cameras/Canon__Canon(...)
J'en ai conclu qu'il y avait sur ces pixels des filtres avec un coefficient d'absorption différent pour les différents type de photo-sites. Je me suis également rendu compte que si je prenais ces courbes et que je déterminer un polynôme pour chaque pixel et faisait cette correction non linéaire des niveaux de gris alors j'avais une image qui était très proche du jpeg fait en raw+jpeg !
J'ajouterai que dans l'optique de fusion de multiple LDR (Low Dynamique Range imaging) la HDRI suivie du tone mapping n'est pas la seule solution, existe également la technique de "exposure fusion" avec des outils tels que : enfuse http://forum.ubuntu-fr.org/viewtopic.php?id=332584
qui contrairement à ce que dit Zakath (qui ferait mieux de renseigner avant de parler) permettent d'avoir un excellent rendu réaliste (certains outils de pfs également)
Pour conclure, il semblerait que les constructeurs de reflex aient mis au point des algos de élargissement de contraste intelligent qui joueraient le rôle d'un tonemapping physique.
Je vais me dépécher de le compiler et de l'installer sur ma distribution (checkinstal). Je vais le tester et le faire tester à l'AI (assistant ingénieur) en conception mécanique qui bosse avec moi. Je pourrais ainsi avoir l'avis d'un professionnel (travail quotidient sur SolidWorks et formation prochaine à Catia).
Ce logiciel est clairement plus avancé que FreeCad. La puissance du l'interface python en fera un sérieux adversaire des solutions propriétaires si les points soulevés par André PASCUAL sont corrigés. S'il ne le sont pas j'essayerais de réunir des équipes pour dégager un budget pour implémenter les fonctions manquantes en usant des CDD.
A tous les membres de l'éducation nationale et du CNRS de la région Nord Pas de calais qui sont intéressés par ce projet et qui disposent de budget, je vous propose de monter un groupe de recherche la mise en oeuvre d'outils pour l'ingénieur Opensource. J'ai défriché pas mal de domaines et je suis aujourd'hui capable de proposer des solutions acceptables dans la plupart des thématiques scientifiques et technique que je connais. Je pense que tout ce qui existe est plus que suffisant pour mettre en place une solution de recherche et de pédagogie totalement OpenSource de Bac +3 à Bac+8.
J'ai la chance d'avoir la responsabilité de changer toute l'architecture d'une salle info (4 postes) pour la passer de windows à linux avec les outils pour les chercheurs et étudiant (même si cela n'est qu'un aspect marginal de mon travail), je vais me servir de cette salle comme incubateur et verrai la réaction des différents utilisateurs.
Il faut absolument que je rédige des billets sur tout ce que j'ai fait depuis mon arrivée à Lille au sein du CNRS pour fédérer des personnes compétentes et débloquer des budgets.
J'invite toute personne intéressée à me contacter sur ma boite mail professionnelle :
Mon_fichier.txt est formate en ligne pour le temps et colonnes pour les variables cet exemple traite un fichier de 3 colonnes et n lignes
load("Mon_fichier.txt");plot(Mon_fichier(:,1),Mon_fichier(:,2),Mon_fichier(:,1),Mon_fichier(:,3));title "graphe de Mon_fichier";print -deps "Graphe_de_Mon_fichier.eps"
dans scicoslab
M=fscanfMat(("Mon_fichier.txt");plot(Mon_fichier(:,1),Mon_fichier(:,2),Mon_fichier(:,1),Mon_fichier(:,3));title "graphe de Mon_fichier"
Tu peux aussi le faire très facilement avec matplotlib, mais je ne suis pas aussi à l'aise.
Je pense que cela prend moins de 30 secondes, en tout cas nettement moins que de faire l'import dans calc, sélectionner les colonnes, demander un nuage de points, ...., cliquer pour enregistrer le fichier !
Je trouve ton commentaire totalement déplacé, il ne me semble pas que le "bio" soit aujourd'hui totalement démocratisé et même si c"était le cas, je ne pense pas que ton commentaire même sur le ton de l'ironie puisse d'être d'une quelconque aide, ou apporte un éclairage nouveau.
Je pense qu'il est tout à fait justifier d'être aigri d'avoir été un dommage collatéral de la production massive même si on a acheté des produits issus de cette agriculture (je ne suis pas persuadé qu'une seule personne ici ne l'ait jamais fait dans sa vie).
Je trouve que tu perds vraiment toute notion de réalité lorsque tu écris : "Parce que sinon, tu as ta part de responsabilité" à quelqu'un qui vit une injustice totale.
Je suis totalement halluciné que tu sois pertinenté.
Je ne me pose pas en garant de la bonne morale, mais je trouve qu'il y a tout de même des limites., et en ce qui me concerne tu les as totalement dépassées.
Certes cela existe, mais la luminosité est très faible, ce qui contraint à utiliser ce projecteur dans un environnement peu éclairé. Il y a des vrais progrès dans le monde des LED, mais il me semble qu'il reste de la marge avant de pouvoir projeter une scène en plein jour sans avoir une batterie de 3Kg sur soi.
Histoire de faire un commentaire constructif sur le libre, j'ai tout de même noté que l'auteur de cette conférence annonce libérer le code permettant ce genre d'interactions.
Je trouve que s'il le fait, il est tout à fait possible de retrouver ce genre d'interface dans un délai raisonnable.
Le point le plus critique me semble être la projection, en effet il faudrait vraiment faire des progrès dans les projos à LED pour pouvoir utiliser ce système dans un environnement éclairé normalement. Il faut bien reconnaitre que les outils d'identification d'objet et de fonctions qu'il utilise sont vraiment au dessus de tout ce que l'on a pu voir jusqu'à présent.
Tu reconnaitras qu'il est difficile de se faire une idée, bien que le code ait été libéré, aucun développement n'a été effectué, même pas le minimum à savoir pouvoir s'interfacer avec le SVG de manière correcte. L'import que j'avais testé était d'une telle nullité que pour essayer le logiciel j'ai dû repartir de 0. Là on nous parle d'un livre qui n'est même pas consultable gratuitement sur un logiciel qui ne nous permettra pas de communiquer avec les standards du libre.
Si Mr Pascual souhaite se faire de l'argent en écrivant des livres, il n'y a rien à redire c'est son droit, mais nous faisons tout de même parti d'une communauté qui utilise sans arrêt de la documentation libre avec des logiciels libres, il est donc naturel de faire des remarques à ce sujet.
Quant au point que tu soulèves sur les cours de dessin vectoriel qui peut être appliqué à d'autres logiciels, n'ayant pas lu le livre je ne peux te dire, mais bien souvent je me suis rendu compte qu'il n'est pas évident de passer d'un soft à un autre lorsqu'un livre se focalise sur un logiciel et non sur les concepts !
Il en allé de même avec QCAD, j'aurais bien lu son livre pour faire quelques plans personnels, mais mon intérêt pour ce logiciel n'était pas suffisant pour lui accorder une somme de plus de 30€, j'ai donc regardé d'autres tutos et ne suis jamais devenu un poweruser.
Je ne suis pas en train de dire que ce monsieur doit travailler à l'oeil, mais plutôt qu'il choisi des marché de niche avec en plus des logiciels qui ne sont pas la référence.
Il aurait très bien pu écrire son livre en utilisant inkscape, je ne pense pas qu'il aurait mis fondamentalement plus de temps.
En bref André Pascual fait des choix et nous sommes libre de ne pas lire son travail du fait ces choix même, si le sujet nous intéresse.
[^] # Re: Un peu d'accord pour Network Manager
Posté par freejeff . En réponse au journal Toujours plus vite. Évalué à 5.
A une époque (lointaine 1 an ou 2) cela ne marchait plus avec le graphique, j'étais bien content de le rentrer en dur au démarrage pour ma chère et tendre.
[^] # Re: j'ai pas bien compris
Posté par freejeff . En réponse au journal Écriture d'une macro dans OpenOffice.org. Évalué à 1.
Elle est de plus "explosible" pour en récupérer les infos, donc c'est moins binaire que tu m'entends ...
[^] # Re: arch
Posté par freejeff . En réponse au journal Soutenir le Logiciel Libre au moyen d'une mini-entreprise. Évalué à 4.
Le projet beagle board à donné naissance à :
touchbook, complètement open : http://www.alwaysinnovating.com/home/index.htm
La nouvelle version xM étant plus puissante, en couplant le boiter de ton père, je pense que tu tiens là quelque chose. Si tu plus tu rajoutes Logram pour l'interface alors tu es vraiment innovant !
Et tu n'as pas à proposer du windows en plus !!!
[^] # Re: j'ai pas bien compris
Posté par freejeff . En réponse au journal Écriture d'une macro dans OpenOffice.org. Évalué à 1.
[^] # Re: SVG est ton ami
Posté par freejeff . En réponse au journal Publipostage dans OpenOffice Draw. Évalué à 1.
si les diagrammes sont très simples alors pas de pbs, mais s'ils sont plus complexes alors c'est le drame.
Par contre OOo gère parfaitement le PS, qui peu être exporté sans compression, il devient alors assez simple de chercher un champs dedans et de le modifier avec sed ou autre.
# Video
Posté par freejeff . En réponse à la dépêche Sortie de CImg 1.3.9 et G'MIC 1.3.9.0. Évalué à 4.
Il existe tout un tas de pipeline possible dans gstreamer qui permettent d'acquérir des flux (mms, rtsp, file, v4l2) pour la video et le son. pouvoir utiliser cimg Cimg et G'MIC via une suite de pipe bien choisis permettrait vraiment de toucher par exemple le monde de la video.
Je sais que OpenCv a déjà commencé ce travail, mais les résultats me semblent encore limités (gros bugs sur les flux rtsp).
Dans ce cadre il y aurait deux stratégies, soit inclure gstreamer comme source de données, soit faire un plugin de G'MIC. Les deux on des avantages et des incovénients. Personnellement je trouve que gstreamer est super mais un peu trop usine à gaz, je préferais donc pouvoir utiliser directement gstreamer depuis G'MIC ou EKD.
Qu'en penses tu ?
[^] # Re: opencyclemap
Posté par freejeff . En réponse au journal Pour la libération des cartes cyclables d'Île-de-France. Évalué à 2.
# Impact factor ?
Posté par freejeff . En réponse à la dépêche Les résultats du LHC sous licence Creative Commons. Évalué à 5.
1) Ces revues sont elles impactées au sens ISI web of knowledge ?
Il faut savoir que l'avancement d'un chercheur se fait en France principalement via l'indice de Hirsch, pour faire augmenter cet indice il faut que la revue ait un facteur d'impact non nul, celui ci étant évalué par the Institute for Scientific Information (ISI). Les jeunes chercheurs ont clairement une pression, car l'AERES (Agence d’évaluation de la recherche et de l’enseignement supérieur) tend à faire une évaluation de plus en plus personnelle (comprendre que bientôt chaque chercheur sera évalué). Il est donc très difficile pour eux de choisir une revue non impactée au sens ISI.
2) N'y a il pas un conflit d'intérêt ?
Plusieurs chercheurs sont intimement convaincus qu'une revue qui fait payer les auteurs (ou les institutions) à l'article aura tout intérêt à accepter le plus d'articles possible pour augmenter son budget. Qu'en est il du tau de rejet des articles publiés dans ces revues ?
Ne t'y trompe pas, je suis autant outré que toi du système en place qui semble complètement fou, on donne beaucoup trop à ces éditeur commerciaux, mais la question de savoir comment sortir de ce système sans sacrifier sa carrière et un vrai problème. La question de comment valider la qualité d'une revue "libre" est dans cette optique complètement fondamentale.
Sinon, je trouve que c'est une excellente nouvelle !
# Recharger les piles non rechargeables
Posté par freejeff . En réponse à la dépêche De l'utilisation des batteries rechargeables. Évalué à 4.
J'ai acheté, il y a un, un chargeur s'appelle batboostor et j'en suis satisfait.
L'idée de base de ce dispositif est de considérer l'aspect transitoire du transfert thermique en ne chargeant pas en continu, on évite ainsi l'accumulation des problèmes liés à l'augmentation de la température dans la cinétique de rechargement.
Une documentation exposant des résultats en laboratoire est disponible à cette adresse :
http://bioenergies.free.fr/mes_documents/batbooster.pdf
S'il faut citer une limitation d'un tel système je dirais qu'il est assez complexe d'utiliser des piles déchargées depuis longtemps, il devient donc délicat de recharger des piles issues de
la récupération (bien que j'ai déjà joué à ce jeu avec un succès mitigé). Les piles peuvent couler si celles que l'on tente de recharger sont trop vielles.
Il est possible de recharger des piles neuves (entendre qui viennent d'être déchargées) une quinzaine de fois, sachant qu'un phénomène de demie vie apparait ce qui contraint in fine à l'abandon des piles au bout de ces utilisations.
Dans de telles conditions il devient urgent de réfléchir à l'achat de batteries rechargeables, car on peut ainsi diminuer par ~10 le coût de piles "non rechargeables".
La société ayant inventé ce procédé est française et se nomme alphysis-AES, mais elle ne semble plus exister et on peut lire sur certains sites que la société JADE a pris le relai.
Ce chageur se trouve un peu partout sur internet, dont le site rue du commerce :
http://www.rueducommerce.fr/m/ps/mpid:MP-07193M574511#moid:M(...)
N'étant pas un spécialiste électrochimie je ne serais me prononcer plus que ce que je vous ai exposé sur ce sujet, je peux juste donner mon expérience d'utilisateur lambda à savoir que ce procédé m'a déjà éviter beaucoup d'achat de piles.
[^] # Re: A propos de l'USB
Posté par freejeff . En réponse à la dépêche Nouvelle version 2.6.34 du noyau Linux. Évalué à 2.
Je pense que cette granularité couplée à un jitter de 10 µs est largement suffisante pour beaucoup d'applis non ?
# Puissance des GPU
Posté par freejeff . En réponse à la dépêche Sortie de G'MIC 1.3.5. Évalué à -1.
N'étant pas un spécialiste de la compilation, je ne peux pas réellement savoir comment s'y prendre pour atteindre un tel but, mais il me semble que OpenCL est basé sur LLVM, donc peut être qu'un première étape serait de parvenir à compiler G'MIC via LLVM et clang ?
Si j'évoque ce problème c'est parce que j'aimerais d'ici 1 ou 2 ans être capable de faire du traitement d'image en temps réel dans une optique de contrôle de machines expérimentales, bien que je sache qu'il existe OpenCV qui implémente déjà beaucoup d'algos, son architecture ne me convient pas toujours c'est pour cela que j'aimerais parfois utiliser un autre framework.
J'ai vu qu'il existait PANDORE, et que tu travailles dessus, aussi je me demande si pandore peut profiter des évolutions de Cimg/G'MIC, et me pose la question de savoir pourquoi ne pas avoir utilisé OpenCV.
Je serais donc vraiment intéressé par utiliser ces outils, mais j'ai besoin de pouvoir les situer dans les outils existant.
# Puissance des GPU
Posté par freejeff . En réponse à la dépêche Sortie de G'MIC 1.3.5. Évalué à 7.
N'étant pas un spécialiste de la compilation, je ne peux pas réellement savoir comment s'y prendre pour atteindre un tel but, mais il me semble que OpenCL est basé sur LLVM, donc peut être qu'un première étape serait de parvenir à compiler G'MIC via LLVM et clang ?
Si j'évoque ce problème c'est parce que j'aimerais d'ici 1 ou 2 ans être capable de faire du traitement d'image en temps réel dans une optique de contrôle de machines expérimentales, bien que je sache qu'il existe OpenCV qui implémente déjà beaucoup d'algos, son architecture ne me convient pas toujours c'est pour cela que j'aimerais parfois utiliser un autre framework.
J'ai vu qu'il existait PANDORE, et que tu travailles dessus, aussi je me demande si pandore peut profiter des évolutions de Cimg/G'MIC, et me pose la question de savoir pourquoi ne pas avoir utilisé OpenCV.
Je serais donc vraiment intéressé par utiliser ces outils, mais j'ai besoin de pouvoir les situer dans les outils existant.
[^] # Re: A propos de l'USB
Posté par freejeff . En réponse à la dépêche Nouvelle version 2.6.34 du noyau Linux. Évalué à 3.
Il me semble de plus que même si linux est un noyau "généraliste", sa base est massivement utilisée dans l'embarqué avec les processeur arm de type 7, 9 et cortex A8. Je sais qu'il y a quelques changements, mais ça n'en est pas moins un linux.
# A propos de l'USB
Posté par freejeff . En réponse à la dépêche Nouvelle version 2.6.34 du noyau Linux. Évalué à 5.
Sans vouloir dire de bétises, il me semble que Ingo Molnar a introduit la possibilité d'avoir une version RT d'un noyau classique avec l'option CONFIG_PREEMPT_RT (Attention, je ne saurais être précis la dessus) appelée "hard-realtime scheduling". Cette option permet notament aux gens faisant de l'audio de réduire drastiquement la latence. Je citerai Linus :
"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." -- Linus Torvalds
J'ai utilisé de manière tout à fait satisfaisante le noyau packagé par debian linux-rt dans le cadre d'une version d'ubuntu-studio avec des cartes d'acquisitions PCI, mais je n'ai jamais eu de bons résultats (voir bien pire qu'avec la version classique du noyau) avec une carte usb.
Il semble que cette pile (je ne sais pas si ce terme convient, j'aurais a priori dit "driver" sans conviction) ne soit pas capable de fonctionner sans aberrations i.e : valeur d'acquisitions erratiques, j'avais trouvé USB4RT, mais ça date de 2005 et le patch de Ingo n'a été introduit qu'à partir de fin 2007 !
Je me permets donc (vu que c'est LA news ou je peux le faire) de demander aux gens qui sont un peu plus dans la technicité que moi s'ils connaissent des moyens de faire de l'USB en RT, et si oui est il possible de le faire sans un gros hack condamnant le pc à ne plus subir aucune mis à jour.
Est-ce que quelqu'un a déjà vu ça passer ce sujet sur la LKML (oui, je sais, je pourrais chercher moi même), suis-je le seul à me poser cette question ?
Pour info la granularité temporelle que j'ai réussi à atteindre sur une carte PCI est de l'ordre de 100 kHz stable (limite de la carte d'acquisition) sans buffer et de 1 kHz avec des erreurs en USB.
[^] # Re: textures
Posté par freejeff . En réponse au journal Des films en vectoriel ?. Évalué à -2.
Dans tous les fichiers vectoriels tu peux inclure des png. Il n'est de plus pas forcément nécessaire d'avoir des textures très définies pour les gradients de couleurs par exemple, car lors de l'affichage d'une image tu peux décider d'interpoler les pixels. Il est donc tout à fait possible d'avoir des objets vectoriels avec des textures bitmaps, tu peux également inclure différentes résolutions et switcher de l'une à l'autre en fonction du zoom.
Donc il me semble possible de faire déjà pas mal de choses !
[^] # Re: corriger des pixels défectueux ?
Posté par freejeff . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 1.
http://wiki.osphoto.org/index.php/Dcraw_bad_pixel_mapping
[^] # Re: manque un appareil photo libre
Posté par freejeff . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 6.
http://graphics.stanford.edu/projects/camera-2.0/
Si je devais apporter une critique sévère sur ce projet, c'est l'attitude des auteurs. Ils sont partis sur une base de caméra elphel, l'ont modifiée avec l'aide des concepteurs de cette caméra et ne les ont pas cités. Ils n'ont de plus pas forcément publié leurs développement alors qu'ils partaient d'un projet OpenSource. Je pense donc que ce projet a le mérite d'exister mais que les projets d'Elphel sont bien plus intéressant.
En ce qui me concerne, pour la vision par ordinateur j'ai deux stratégies différentes. La première lorsque je n'ai pas besoin de plus d'une image par seconde alors je passe par un appareil photo numérique reflex, ce qui me permet de récupérer les fichiers bruts de les convertir aux mieux et de profiter de gphoto2 pour pouvoir piloter entièrement mon appareil, du réglage du temps d'intégration jusqu'à l'ouverture du diaphragme en passant par l'ISO ...
Jusqu'à présent lorsque j'avais besoin de plus d'images par seconde je n'avais pas de solutions simples. Il existe bien une norme de carte d'acquisition dédiée à l'imagerie avec la définition d'une liaison série ad hoc, nommée cameralink, mais cette norme n'a spécifiée que le tuyau et pas la manière de transférer les données, résultats chaque constructeur gère comme il l'entend son pilotage de caméra. Pour utiliser ce type de caméra il faut un "framegrabber", nos amis de chez NI (National Instrument) ont une très forte présence sur ce secteur (Carte et logiciels NI vision) , mais ils ont décidé de ne pas supporter linux, donc si un labo a ce type de carte et s'il veut continuer d'utiliser ses caméras, mais cette fois sur linux, alors il est obligé de changer de cartes ! De plus même s'il existe des SDK pour linux, aucun n'est opensource, pour aucune carte que je connaisse (si vous en connaissez je suis preneur). Depuis quelques années la norme GigE/gencam permet de parler à toutes les caméras de ce type de manière transparente à partir du moment ou un fichier xml contenant les caractéristiques a été renseignées. C'est extrêmement prometteur ! Reste qu'en terme de flux de données cette interface reste légèrement inférieure à ce que l'on peut trouver en caméralink, et comme les labos ont tendance à n'acheter qu'en fonction des caractéristiques du matériel ce sytème n'a pas encore vraiment pénétré le monde scientifique (en tout cas celui que je fréquente).
D'un autre cotés en OpenSource OpenHardware, on a Elphel qui a fait plusieurs caméras avec une interface ethernet classique, mais avec des FPGA et un processeur ARM, ce qui leur permet de traiter les images de manière intelligente avant de les envoyer vers le pc hôte. Il sont en ce moment en train de développer une carte GigE qui permettra à terme de faire passer un flot de données très important. Un autre intérêt pour les personnes intéressées réside dans la modularité de leurs solutions, en effet, vous pouvez choisir une "carte capteur" parmi plusieurs existantes, vous pouvez rajouter une carte entrées/sorties permettant de synchroniser de manière très fines plusieurs caméras entre elles.
http://www3.elphel.com/fr/353_overview
J'ai commandé une caméra, qui ne devrait pas tarder à arriver, une fois que j'aurais un workflow opérationnel, je rédigerais certainement une dépêche expliquant en détail tout ça.
Donc pour conclure, je pense que les choses avancent bien pour le monde OpenSource dans le domaine de la vision et j'espère que ça continuera dans ce sens.
[^] # Re: Raw ?
Posté par freejeff . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 3.
Je n'ai jamais dit qu'il n'y avait pas de différence, il est bien évident que si tu photographie une scène avec un très importante variation de lumière alors plus ta dynamique sera grande et mieux se passeront les choses. Il existe tout un tas de cas où cette dynamique n'apportera que peu de plu-value à ta photo, par contre la différence de taille est elle fort signifiante quelle que soit l'image. Ce que je soulignait était le fait que prendre une image en raw la tranformer en tiff, ajuster les contrastes globalement et l'exporter en jpeg peut donner de moins bon résultats que prendre directement le fichier en jpeg. Tu fais peut être partie des passionnés qui ne prennent qu'une photo en une heure en maîtrisant tous les paramètre de ton boitier et objectifs, je t'en félicite, mais lorsque je prends un centaine d'images en une semaine de vacance, alors les trois ou 4 heures qu'il va me falloir pour bien convertir analyser les images pour enfin les archiver me semblent fastidieuses. Je suis cependant capable de prendre des images en raw lorsque les conditions me semblent sévère ...
[^] # Re: Raw ?
Posté par freejeff . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 5.
Pour ceux qui se persuade de pouvoir juste en derawtisant faire mieux que le jpeg d'un boitier, je vais vous expliquer un point intéressant.
Lorsque j'ai commencé à faire de la photo scientifique sous linux, j'ai tout d'abors utilisé dcraw, car celui-ci permet de se rapprocher le plus du capteur (dcraw -4 -T -D), il m'était de me fabriquer l'image en niveau de gris qui m'intéressait.
Plus tard j'ai découvert libopenraw, nous avons fait un programme en C++ avec et nous sommes rendu compte que nous récupérions plus de pixels qu'avec dcraw. En fait nous recupérions des pixels sur le bord du capteur. J'ai passé un peu de temps à analyser ces pixels et me suis rendu compte qu'il y avait des zones où le capteur est masqué, pour mesurer le bruit thermique et d'autres où il y avait une évolution non linéaire de l'intensité en fonction d'une direction du capteur. En cherchant un peut j'ai constaté que ces courbes étaient au nombre de trois et très proche de :
http://luminance.londonmet.ac.uk/webhdr/cameras/Canon__Canon(...)
J'en ai conclu qu'il y avait sur ces pixels des filtres avec un coefficient d'absorption différent pour les différents type de photo-sites. Je me suis également rendu compte que si je prenais ces courbes et que je déterminer un polynôme pour chaque pixel et faisait cette correction non linéaire des niveaux de gris alors j'avais une image qui était très proche du jpeg fait en raw+jpeg !
J'ajouterai que dans l'optique de fusion de multiple LDR (Low Dynamique Range imaging) la HDRI suivie du tone mapping n'est pas la seule solution, existe également la technique de "exposure fusion" avec des outils tels que : enfuse
http://forum.ubuntu-fr.org/viewtopic.php?id=332584
qui contrairement à ce que dit Zakath (qui ferait mieux de renseigner avant de parler) permettent d'avoir un excellent rendu réaliste (certains outils de pfs également)
Pour conclure, il semblerait que les constructeurs de reflex aient mis au point des algos de élargissement de contraste intelligent qui joueraient le rôle d'un tonemapping physique.
# Super nouvelle, mais allons plus loin
Posté par freejeff . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 8.
Je vais me dépécher de le compiler et de l'installer sur ma distribution (checkinstal). Je vais le tester et le faire tester à l'AI (assistant ingénieur) en conception mécanique qui bosse avec moi. Je pourrais ainsi avoir l'avis d'un professionnel (travail quotidient sur SolidWorks et formation prochaine à Catia).
Ce logiciel est clairement plus avancé que FreeCad. La puissance du l'interface python en fera un sérieux adversaire des solutions propriétaires si les points soulevés par André PASCUAL sont corrigés. S'il ne le sont pas j'essayerais de réunir des équipes pour dégager un budget pour implémenter les fonctions manquantes en usant des CDD.
A tous les membres de l'éducation nationale et du CNRS de la région Nord Pas de calais qui sont intéressés par ce projet et qui disposent de budget, je vous propose de monter un groupe de recherche la mise en oeuvre d'outils pour l'ingénieur Opensource. J'ai défriché pas mal de domaines et je suis aujourd'hui capable de proposer des solutions acceptables dans la plupart des thématiques scientifiques et technique que je connais. Je pense que tout ce qui existe est plus que suffisant pour mettre en place une solution de recherche et de pédagogie totalement OpenSource de Bac +3 à Bac+8.
J'ai la chance d'avoir la responsabilité de changer toute l'architecture d'une salle info (4 postes) pour la passer de windows à linux avec les outils pour les chercheurs et étudiant (même si cela n'est qu'un aspect marginal de mon travail), je vais me servir de cette salle comme incubateur et verrai la réaction des différents utilisateurs.
Il faut absolument que je rédige des billets sur tout ce que j'ai fait depuis mon arrivée à Lille au sein du CNRS pour fédérer des personnes compétentes et débloquer des budgets.
J'invite toute personne intéressée à me contacter sur ma boite mail professionnelle :
Jean_+tiret+_francois_+point+_witz_+chez+_ec_+tiret+_lille_+point+_fr
J'en profite également pour vous remercier car je ne serais pas là aujourd'hui sans la communauté linuxienne.
PS : je suis toujours aussi nul en naurteaugraffe donc pas taper.
[^] # Re: Argl... un tableur n'est pas une base de données !
Posté par freejeff . En réponse au journal Le million pour Calc. Évalué à 4.
lancer octave,
Mon_fichier.txt est formate en ligne pour le temps et colonnes pour les variables cet exemple traite un fichier de 3 colonnes et n lignes
load("Mon_fichier.txt");plot(Mon_fichier(:,1),Mon_fichier(:,2),Mon_fichier(:,1),Mon_fichier(:,3));title "graphe de Mon_fichier";print -deps "Graphe_de_Mon_fichier.eps"
dans scicoslab
M=fscanfMat(("Mon_fichier.txt");plot(Mon_fichier(:,1),Mon_fichier(:,2),Mon_fichier(:,1),Mon_fichier(:,3));title "graphe de Mon_fichier"
Tu peux aussi le faire très facilement avec matplotlib, mais je ne suis pas aussi à l'aise.
Je pense que cela prend moins de 30 secondes, en tout cas nettement moins que de faire l'import dans calc, sélectionner les colonnes, demander un nuage de points, ...., cliquer pour enregistrer le fichier !
[^] # Re: Aigri je suis
Posté par freejeff . En réponse à la dépêche Le Temps des Grâces. Évalué à 3.
Je pense qu'il est tout à fait justifier d'être aigri d'avoir été un dommage collatéral de la production massive même si on a acheté des produits issus de cette agriculture (je ne suis pas persuadé qu'une seule personne ici ne l'ait jamais fait dans sa vie).
Je trouve que tu perds vraiment toute notion de réalité lorsque tu écris : "Parce que sinon, tu as ta part de responsabilité" à quelqu'un qui vit une injustice totale.
Je suis totalement halluciné que tu sois pertinenté.
Je ne me pose pas en garant de la bonne morale, mais je trouve qu'il y a tout de même des limites., et en ce qui me concerne tu les as totalement dépassées.
[^] # Re: OpenSource
Posté par freejeff . En réponse au journal Mieux que l' Ipad et Open source !. Évalué à 3.
# OpenSource
Posté par freejeff . En réponse au journal Mieux que l' Ipad et Open source !. Évalué à 7.
Je trouve que s'il le fait, il est tout à fait possible de retrouver ce genre d'interface dans un délai raisonnable.
Le point le plus critique me semble être la projection, en effet il faudrait vraiment faire des progrès dans les projos à LED pour pouvoir utiliser ce système dans un environnement éclairé normalement. Il faut bien reconnaitre que les outils d'identification d'objet et de fonctions qu'il utilise sont vraiment au dessus de tout ce que l'on a pu voir jusqu'à présent.
W&S.
[^] # Re: Réponse d'André Pascual
Posté par freejeff . En réponse à la dépêche Xara Xtreme pour Linux chez Eyrolles par André Pascual. Évalué à 5.
Si Mr Pascual souhaite se faire de l'argent en écrivant des livres, il n'y a rien à redire c'est son droit, mais nous faisons tout de même parti d'une communauté qui utilise sans arrêt de la documentation libre avec des logiciels libres, il est donc naturel de faire des remarques à ce sujet.
Quant au point que tu soulèves sur les cours de dessin vectoriel qui peut être appliqué à d'autres logiciels, n'ayant pas lu le livre je ne peux te dire, mais bien souvent je me suis rendu compte qu'il n'est pas évident de passer d'un soft à un autre lorsqu'un livre se focalise sur un logiciel et non sur les concepts !
Il en allé de même avec QCAD, j'aurais bien lu son livre pour faire quelques plans personnels, mais mon intérêt pour ce logiciel n'était pas suffisant pour lui accorder une somme de plus de 30€, j'ai donc regardé d'autres tutos et ne suis jamais devenu un poweruser.
Je ne suis pas en train de dire que ce monsieur doit travailler à l'oeil, mais plutôt qu'il choisi des marché de niche avec en plus des logiciels qui ne sont pas la référence.
Il aurait très bien pu écrire son livre en utilisant inkscape, je ne pense pas qu'il aurait mis fondamentalement plus de temps.
En bref André Pascual fait des choix et nous sommes libre de ne pas lire son travail du fait ces choix même, si le sujet nous intéresse.