Je te conseille cet article : http://www.jp-petit.org/science/Z-machine/from_geffray/ltd.html.
Il faut bien comprendre que les enjeux industriels sont énormes, il y a donc peu de chance qu'une technique si simple soit publiée avant que les brevets ne soient déposés.
J'ai entendu parlé de plusieurs brevets américains sur l'amorçage de bombe H via ces circuits LTD, je n'ai pas encore réussi à les trouver ...
Ces découvertes sont assez sensibles politiquement. Le lobby du cea a toujours été porté vers le laser mega Joule qui est en phase de finalisation au cea cesta au Barp. Il y a une réelle volonté de de lutter contre la technologie de striction axiale pour l'amorçage de réaction de fusion à ce que j'ai cru comprendre, comme tout ceci n'est que bruit de couloirs il faut le prendre avec des pincette. Ce que je peux affirmer c'est que la Z-machine française(SPHINX) qui se trouve à Gramat dans le Lot est fonctionnelle, elle était précédemment utilisée par la DGA pour simuler l'influence de rayonnement électromagnétiques sur les électroniques des véhicules militaires. En 2010 le centre d'étude de Gramat a été réorganisé pour faire parti du cea et non plus de la DGA. Les enjeux politiques et économiques sont bien trop important pour que l'on sache ce que va en faire le cea, mais je tiens à rappeler que le SPHINX a été la première Z-machine utilisant des circuits LTD.
Il est tout à fait envisageable de produire de l'énergie avec de telles installations, ce serait un peut le passage de la machine à vapeur (énergie continue) au moteur à combustion interne (fonctionnement par allumage successif). Il n'y a aucune barrière scientifique en ce qui concerne les matériaux (principale inconnue pour ITER), et la faisabilité. Il reste "juste" une dizaine d'année ingénierie intense (peut être beaucoup moins) pour maîtriser ce cycle un peu plus subtil que celui de la fission.
Nous n'en entendrons pas parler avant je pense que le premier démonstrateur soit sorti de chez Sandia, mais comme nous disposons du deuxième plus puissant à ce jour avec l’architecture la plus moderne, il y a de grande chances que des recherches discrètes nous permettent de suivre l'état de l'art de chez Sandia.
Je rappel que l'état français s'est vu accorder l'implantation de ITER sur son sol, ce serait le plus grand scandale en terme d'investissement en R&D internationale si ce projet était abandonné pour une technologie plus réaliste. Il faut bien assimiler le fait que personne ne sait aujourd'hui pourquoi Sandia a pu atteindre ces températures. Il serait donc possible d'utiliser cette énergie en y mettant de l’ingénierie, mais de comprendre d'où elle vient. Les français en sont pas du genre à accepter un tel paradoxe, qui n’empêchera pas de dormir un américain.
J'ai donc bien peur que le jour où cette application sorte, elle soir bardée de brevets et donc peu utilisable avant plusieurs générations.
Ce qui je veux souligner ici c'est que encore une fois les solutions semblent être à notre portée, mais les défenseurs d'une certaine chapelle vont nous faire perdre au moins 10 ans (5 années ont passée depuis la découverte de Sandia).
J'ai essayé cette version de l'import et si les choses vont dans le bon sens, il me semble qu'il est complètement prématuré de parler d'un support. Il n'existe aucun éditeur graphique (WYSIWYG, ) vi/emacsNedit/kate/gedit ... en WYSIWYM) capable de prendre en compte toute les fonctionnalités de SVG. Essayez donc d'importer un SVG contenant du texte des images, des dégradés, issu de inkscape et lisible sous Gecko/webkit et vous allez voir le massacre.
La bonne nouvelle est que l'import pdf est relativement correct ce qui permet le passage vectoriel entre Inkscape et LOdraw.
En quoi quelqu'un voulant livrer une partie de ses réalisations artistiques en utilisant une licence libre devait il le faire gratuitement. Tu sais lorsque je veux faire un programme en OpenSource, il me faut payer quelqu'un (bon hein souvent un stagiaire, vu nos finances...) et au final cela me coute vraiment !
Si ce monsieur propose de livrer à la communauté 30 portrait pour 1500$ et que les concepteurs des jeux videos opensources trouvent le travail valorisable pour leur réalisations alors tout le monde est gagnant.
Il faut arrêter de croire que les ressources non matérielles n'ont pas de coût.
Après j'ai des doutes sur l'utilité de portrait fait sous GIMP pour les jeux, mais cela vient probablement du fait que je n'y connais rien ...
Pour être aller à une conférence, ce Monsieur déclamait qu'il y avait des "vrai" terroristes chez microsofts. Qu'il n'existait aucun cas où le logiciel libre était moins adapté qu'un logiciel propriétaire, il n'est peut être pas extrémiste dans ton référentiel, mais pour les gens qui n'ont pas ton niveau dans la compréhension de l'écosystème libre, le message est complètement inaudible car volontairement radical.
Ce genre de logiciels a un temps de gestation bien plus lent que les logiciels traditionnels de part la complexité initialement requise. On pourrait prendre l'exemple de Salome qui est codé en utilisant Corba, ce choix a initialement été fait de part la nécessité de tout pouvoir faire en parallèle et en déporté simplement. A l'époque ou se projet a été commencé cela semblait une bonne idée, mais ça a malheureusement mis un frein à des contributions externe de part la complexité de corba.
Il faut bien voir que le nombre de soft que contient Salomé est impressionnant, il me semble que le gros problème vient du fait que ces softs sont fait par des scientifiques qui n'ont ni les connaissances ni l'envie d'apprendre à empaqueter leurs programmes pour différentes distributions (pour donner du grain à moudre à Zenitram). Il ne mettent pas forcément leurs softs à jour, car lorsqu'il fait le travail et qu'ils n'ont pas motivations scientifiques pour le faire évoluer alors ils ne le feront pas. Il devient du coup très difficile de faire cohabiter toutes les version des différentes lib dans le gestionnaire de programme. Il est donc souvent décidé de compiler en local. Je te rappel qu'il y a également des standard pour qu'un dépot soit accepter et je pense qu'ils s'en contrefichent. La solution de l'équipe de CAELinux est donc de prendre une distribution à jour, de se frapper tout le travail de compilation et de générer une "distribution" ou tout marchera "out of the box". Cette tactique me semble pertinente car ce sont les distributions (et le noyau) qui gères les évolutions de matériels et de softs standards.
Je ne pense donc pas qu'il faille réellement prendre ça au sens d'une distribution, mais plutôt au sens d'une compilation de logiciels sur une distribution déjà existante.
Le débat de la complexité de faire des logiciels pour linux a déjà souvent été abordé ici et je n'ai pas vu de solution simple. Celle-ci l'est pour le développeur et pour l'utilisateur qui accepte la contrainte de devoir installer un système pour ces applications. Je pense donc que c'est un compromis qui fait avancer les choses.
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 ...
[^] # Re: Sortir du nucléaire
Posté par freejeff . En réponse au journal HS Un débat sur l'énergie nucléaire en France. Évalué à 0.
Je te conseille cet article : http://www.jp-petit.org/science/Z-machine/from_geffray/ltd.html.
Il faut bien comprendre que les enjeux industriels sont énormes, il y a donc peu de chance qu'une technique si simple soit publiée avant que les brevets ne soient déposés.
J'ai entendu parlé de plusieurs brevets américains sur l'amorçage de bombe H via ces circuits LTD, je n'ai pas encore réussi à les trouver ... Ces découvertes sont assez sensibles politiquement. Le lobby du cea a toujours été porté vers le laser mega Joule qui est en phase de finalisation au cea cesta au Barp. Il y a une réelle volonté de de lutter contre la technologie de striction axiale pour l'amorçage de réaction de fusion à ce que j'ai cru comprendre, comme tout ceci n'est que bruit de couloirs il faut le prendre avec des pincette. Ce que je peux affirmer c'est que la Z-machine française(SPHINX) qui se trouve à Gramat dans le Lot est fonctionnelle, elle était précédemment utilisée par la DGA pour simuler l'influence de rayonnement électromagnétiques sur les électroniques des véhicules militaires. En 2010 le centre d'étude de Gramat a été réorganisé pour faire parti du cea et non plus de la DGA. Les enjeux politiques et économiques sont bien trop important pour que l'on sache ce que va en faire le cea, mais je tiens à rappeler que le SPHINX a été la première Z-machine utilisant des circuits LTD. Il est tout à fait envisageable de produire de l'énergie avec de telles installations, ce serait un peut le passage de la machine à vapeur (énergie continue) au moteur à combustion interne (fonctionnement par allumage successif). Il n'y a aucune barrière scientifique en ce qui concerne les matériaux (principale inconnue pour ITER), et la faisabilité. Il reste "juste" une dizaine d'année ingénierie intense (peut être beaucoup moins) pour maîtriser ce cycle un peu plus subtil que celui de la fission.
Nous n'en entendrons pas parler avant je pense que le premier démonstrateur soit sorti de chez Sandia, mais comme nous disposons du deuxième plus puissant à ce jour avec l’architecture la plus moderne, il y a de grande chances que des recherches discrètes nous permettent de suivre l'état de l'art de chez Sandia.
Je rappel que l'état français s'est vu accorder l'implantation de ITER sur son sol, ce serait le plus grand scandale en terme d'investissement en R&D internationale si ce projet était abandonné pour une technologie plus réaliste. Il faut bien assimiler le fait que personne ne sait aujourd'hui pourquoi Sandia a pu atteindre ces températures. Il serait donc possible d'utiliser cette énergie en y mettant de l’ingénierie, mais de comprendre d'où elle vient. Les français en sont pas du genre à accepter un tel paradoxe, qui n’empêchera pas de dormir un américain.
J'ai donc bien peur que le jour où cette application sorte, elle soir bardée de brevets et donc peu utilisable avant plusieurs générations.
Ce qui je veux souligner ici c'est que encore une fois les solutions semblent être à notre portée, mais les défenseurs d'une certaine chapelle vont nous faire perdre au moins 10 ans (5 années ont passée depuis la découverte de Sandia).
My 2 cents
[^] # Re: Multiplateforme
Posté par freejeff . En réponse au journal Qt pour Android en version alpha. Évalué à 5.
Rhooo ! On en a entendu parlé tout le weekend, tu veux pas le laisser où il est le DSK ..., même s'il semblerait qu'il aime bien ce qui est "Qt"
---->[]
[^] # Re: SVG !!!!!
Posté par freejeff . En réponse à la dépêche LibreOffice est de sortie !. Évalué à 3.
La bonne nouvelle est que l'import pdf est relativement correct ce qui permet le passage vectoriel entre Inkscape et LOdraw.
[^] # Re: Plait-il ?
Posté par freejeff . En réponse au journal Des graphismes dans les jeux libres. Évalué à 10.
En quoi quelqu'un voulant livrer une partie de ses réalisations artistiques en utilisant une licence libre devait il le faire gratuitement. Tu sais lorsque je veux faire un programme en OpenSource, il me faut payer quelqu'un (bon hein souvent un stagiaire, vu nos finances...) et au final cela me coute vraiment !
Si ce monsieur propose de livrer à la communauté 30 portrait pour 1500$ et que les concepteurs des jeux videos opensources trouvent le travail valorisable pour leur réalisations alors tout le monde est gagnant.
Il faut arrêter de croire que les ressources non matérielles n'ont pas de coût.
Après j'ai des doutes sur l'utilité de portrait fait sous GIMP pour les jeux, mais cela vient probablement du fait que je n'y connais rien ...
# Un journal ?
Posté par freejeff . En réponse au journal Comportement d'apt-get par défaut. Évalué à 10.
Ceci est une vrai question, pas juste un, "ya les forum pour ça". Il y a il un intérêt au niveau du référencement ?
[^] # Re: Bayart et Stallman en conf. à Paris
Posté par freejeff . En réponse à la dépêche Richard Stallman: 2 conférences à Paris. Évalué à 4.
Pour être aller à une conférence, ce Monsieur déclamait qu'il y avait des "vrai" terroristes chez microsofts. Qu'il n'existait aucun cas où le logiciel libre était moins adapté qu'un logiciel propriétaire, il n'est peut être pas extrémiste dans ton référentiel, mais pour les gens qui n'ont pas ton niveau dans la compréhension de l'écosystème libre, le message est complètement inaudible car volontairement radical.
[^] # Re: pourquoi ?
Posté par freejeff . En réponse à la dépêche CAElinux 2010 et Salome-meca 2010. Évalué à 9.
Il faut bien voir que le nombre de soft que contient Salomé est impressionnant, il me semble que le gros problème vient du fait que ces softs sont fait par des scientifiques qui n'ont ni les connaissances ni l'envie d'apprendre à empaqueter leurs programmes pour différentes distributions (pour donner du grain à moudre à Zenitram). Il ne mettent pas forcément leurs softs à jour, car lorsqu'il fait le travail et qu'ils n'ont pas motivations scientifiques pour le faire évoluer alors ils ne le feront pas. Il devient du coup très difficile de faire cohabiter toutes les version des différentes lib dans le gestionnaire de programme. Il est donc souvent décidé de compiler en local. Je te rappel qu'il y a également des standard pour qu'un dépot soit accepter et je pense qu'ils s'en contrefichent. La solution de l'équipe de CAELinux est donc de prendre une distribution à jour, de se frapper tout le travail de compilation et de générer une "distribution" ou tout marchera "out of the box". Cette tactique me semble pertinente car ce sont les distributions (et le noyau) qui gères les évolutions de matériels et de softs standards.
Je ne pense donc pas qu'il faille réellement prendre ça au sens d'une distribution, mais plutôt au sens d'une compilation de logiciels sur une distribution déjà existante.
Le débat de la complexité de faire des logiciels pour linux a déjà souvent été abordé ici et je n'ai pas vu de solution simple. Celle-ci l'est pour le développeur et pour l'utilisateur qui accepte la contrainte de devoir installer un système pour ces applications. Je pense donc que c'est un compromis qui fait avancer les choses.
[^] # 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 ...