ganymede a écrit 21 commentaires

Tout d'abord merci beaucoup pour cette application.
J'ai une variante du même problème… Je viens tout juste de me faire vacciner, et le document papier qu'on m'a remis comporte 2 QR-Codes. Le 1er est apparemment au format 2D-DOC (en tout cas c'est écrit dessous), et le 2e dans un format lié à TousAntiCovid (il est écrit : "Flashez pour ajouter dans TousAntiCovid").
Quand j'importe le 1er dans Sanipasse, j'ai la même erreur : "Aucun code QR ou 2D-DOC détecté dans le document.", par contre pour le 2e aucun problème, les données sont correctement extraites.
Je précise que j'ai fait un scan de bonne qualité et bien recadré les QR-Codes, j'ai même essayé plusieurs recadrages.
Si tu souhaites y regarder de plus près, je peux t'envoyer mes QR-Codes en message privé.

le problème avec les regexp, c'est qu'une fois qu'on les maitrise on en abuse

Je suis d'accord. Voici tout de même, pour ceux que ça intéresserait, une expression rationnelle qui valide correctement une IPv4 :
\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(.|$)){4}\b

Salut,
Le nom de ce système d'exploitation a-t-il déjà été choisi ?
Pour ce que nom sonne bien de chez nous, on pourrait l'appeler ClacOS.
---> []

J'utilise sans problème une carte de ce type sous archlinux… mais avec un lecteur Gemalto USB Shell Token V2.
Donc oui, c'est peut-être une question de lecteur.

Cas d'utilisation précis :
- tu as un fichier vidéo dans lequel la piste image et la piste son sont désynchronisées
- mais tu peux déterminer exactement le décalage temporel entre les deux pistes (grâce à mediainfo par exemple)
- et tu veux traiter séparément la piste son (par exemple lui appliquer un filtre d'Audacity et l'encoder dans un certain format pour la diffuser)
Admettons que la piste audio "avance" de 1234 millisecondes sur l'image. Il peut être utile dans ce cas-là de couper précisément ces 1234 millisecondes au tout début de la piste audio, avant de l'exporter et de la remultiplexer avec l'image.
(On peut aussi faire ça "au jugé" dans un logiciel de montage, mais c'est moins précis, et le logiciel en question n'offrira probablement pas autant de possibilités pour traiter le son qu'Audacity.)

si tu as eu besoin de cette fonctionnalité, d'autres doivent également en éprouver le besoin donc la contribuer upstream me semble une très bonne idée. […] ça ne dérangerait personne. Le seul risque c'est que ça satisfasse plus d'utilisateurs

En effet. Je me sers parfois d'Audacity pour éditer la piste son de petites séquences vidéo, et le mode d'affichage que tu proposes me serait utile dans certains cas.

Salut,
Pour ceux qui voudraient acheter le montage "tout fait", les produits JDS Labs ne sont pas faciles à trouver en Europe.
En revanche, on peut se procurer l'O2, l'ODAC ou le "combo" O2+ODAC sur ce site suisse : http://www.headnhifi.com/

Bonjour,
Tout d'abord ce projet me paraît intéressant et utile, étant donnée la capacité de désinformation lobbying de l'industrie agro-alimentaire.
Cependant, le 1er contact donne une impression de fouillis, car, comme le dit la dépêche, il y a beaucoup de doublons. Par exemple, une recherche sur le nutella (dans la barre de recherche en haut à droite) donne pas moins de 22 résultats, certains étant plus complets que d'autres : liste des composants alimentaires plus ou moins exhaustive, présence ou non d'une photo, etc. Même chose pour bien d'autres produits "stars" (Coca-cola, etc.).
Manifestement, c'est un défaut de jeunesse, le site ayant besoin d'un effort de modération pour "fusionner" les fiches en doublon, en gardant toutes les informations pertinentes (ce qui implique donc aussi de les vérifier). Il y a là une forme de contribution possible et utile, en plus du recensement des produits.
Mais du coup je me demande si la méthode de recensement à partir des codes-barres n'a pas quelques défauts :
- Il semble qu'un même produit puisse être commercialisé avec plusieurs codes-barres différents, ce qui tendrait à créer des doublons.
- Inversement, je suppose qu'il peut y avoir des cas où un produit change légèrement de recette (donc de composition) sans changer ni d'appellation, ni de prix… ni de code-barres. Dans ce cas, il faudrait créer une fiche pour la 1ère version du produit et une autre pour la 2e, sachant que les deux peuvent cohabiter un certain temps dans les rayons (ou que la 1ère version peut rester un certain temps sur une étagère de cuisine, bien qu'elle ne soit plus vendue en magasin).
Certes il y a des normes dans ce domaine (EAN dans l'Union Européenne, UPC en Amérique du nord…), mais est-ce que cela empêche un fabricant d'écrire la partie "codage de l'article" (sur 4 ou 6 chiffres en Europe) comme il l'entend, créant ainsi (parfois) les problèmes ci-dessus ?

Avisynth 3 est mort depuis des années… mais la relève existe, elle s'appelle vapoursynth. En gros, c'est une réécriture complète et multiplateforme d'avisynth, qui se présente comme une extension du langage python. C'est un projet jeune (moins d'un an) mais très prometteur, qui a connu un développement rapide. La prochaine version devrait être "feature-complete" c'est-à-dire qu'il sera possible de transcrire avec vapoursynth n'importe quel script avisynth. Vapoursynth permet même d'utiliser des plugins compilés pour avisynth, mais sous Windows uniquement, si bien que sous Linux les possibilités sont pour l'instant réduites. Cependant, certains plugins d'avisynth ont été portés pour tourner nativement avec vapoursynth, et sont donc dispo sous Linux. Les heureux utilisateurs d'ArchLinux peuvent d'ores et déjà installer pas mal de choses depuis AUR. Le développement de vapoursynth et de ses plugins est discuté activement sur le forum doom9.

Avisynth et vapoursynth peuvent être utilisés comme des NLE mais ce n'est vraiment pas pratique. Par contre, ils sont très appréciés pour leurs possibilités de filtrage et de post-traitement (désentrelacement, débruitage, netteté, etc.), grâce au très riche écosystème de plugins d'avisynth. Beaucoup de ces filtres dépassent en qualité et en fonctionnalité ceux des autres logiciels, libres ou même propriétaires. Pour ma part, je travaille dans un cadre semi-professionnel avec des outils propriétaires sous Windows (Premiere Pro pour le montage, After Effects pour les effets visuels, Adobe Audition pour le son, DaVinci Resolve pour la correction et l'étalonnage) mais j'utilise souvent avisynth (et maintenant parfois vapoursynth) dans la dernière phase de mon "workflow", juste avant l'encodage final.

Il y a tout de même de plus en plus de pistes cyclables, aussi bien à Paris qu'en banlieue. Pour ma part j'emprunte souvent la coulée verte, un axe réservé aux piétons et aux cyclistes qui traverse la banlieue sud de Paris. Dans d'autres grandes villes c'est pareil.

Et avec digikam/showfoto ? C'est un logiciel très adapté pour la retouche photo sur 16 bits, qui supporte des modules externes (au moins Liquid Rescale et les kipi-plugins).

Ce que je trouverais vraiment génial, c'est que ce framework permette de traiter des flux vidéo à la manière d'avisynth [http://avisynth.org/mediawiki/Main_Page]. Pour l'instant il n'existe rien d'équivalent sous linux (à ma connaissance).

utiliser la version Cinelerra-CV plutot que la version de base d'heroinewarrior
Peux-tu s'il te plaît préciser pour quelle raison ?
Je pose cette question car j'envisage d'utiliser cinelerra (en tout cas de consacrer un peu de temps pour apprendre à l'utiliser).

Je vais donc réessayer kdenlive sans jamais demander la lecture de la vidéo
La lecture de la vidéo est bien sûr une fonction indispensable, et cette remarque est d'ailleurs peut-être ironique (?).
Je précise que je n'ai subi ces plantages que sur des vidéos dont le son et l'image étaient légèrement désynchronisés. Il est vrai qu'on est parfois (souvent) obligé de travailler à partir d'un matériel vidéo de mauvaise qualité... Mais avec des vidéos « standard », je n'ai jamais eu de problème.

J'utilise kdenlive et j'en suis très content... Mais rien ne vaut l'expérience que tu feras par toi-même :-)
Pour préciser tout de même dans quel cadre je l'ai utilisé : je ne suis pas du tout un professionnel, mais j'ai eu à monter deux courts-métrages de 6-7 minutes à partir de plusieurs heures de rushes dans des formats vidéo différents. Cela m'a demandé plusieurs jours de boulot au total. J'ai effectivement subi plusieurs plantages (uniquement lors de la lecture de ma vidéo dans le « moniteur de projet ») mais kdenlive n'a heureusement jamais perdu aucune donnée. Par contre j'ai apprécié son côté intuitif, sa richesse en fonctionnalités et la bonne qualité des fichiers rendus.
Mais, encore une fois, à toi de te faire une idée selon tes besoins et de comparer entre les différents logiciels. Le site lprod est une bonne source d'infos, ainsi bien sûr que celui de kdenlive (qui abrite d'ailleurs plusieurs tutoriels vidéo).

ces utilisateurs pourront continuer à utiliser ce logiciel libre car il fonctionne aussi sur un OS libre :)Ah bon, même sur une distribution linux 64 bits autre que debian / ubuntu ? En tout cas, pas sans quelques contorsions qui demandent des connaissances techniques supérieures à la moyenne. Et de la chance.

passait plus de temps à encourager les usages des logiciels libres qu'a les dénigrer par des prétextesCe n'est pas parce qu'on émet des critiques (argumentées) sur le logiciel que tu développes qu'on « dénigre » les logiciels libres en général, et encore moins « par des prétextes » ! Ceux qui me connaissent savent que je m'efforce de populariser les logiciels libres autour de moi, à commencer par les utilisateurs novices. Si la critique te gêne, ce n'est pas une raison pour tomber dans le faux procès et l'amalgame.

Peut être que la communauté du libre aurait encore plus d'adeptes.Vous développez un logiciel libre, c'est très bien. Ce logiciel convient à un certain nombre d'utilisateurs, c'est très bien aussi. Mais en tant qu'utilisateur (dans mon cas : ex-utilisateur) d'un logiciel, on a bien le droit de dire ce qu'on en pense, y-compris de relever certains problèmes rencontrés. À plus forte raison s'il s'agit d'un logiciel libre qui prétend fédérer une communauté. Mais je remarque qu'au lieu de répondre à ces critiques (en particulier la quasi-impossibilité de packager scenari pour toutes les distributions), tu préfères « dénigrer » les personnes qui les émettent (rien que des geeks et des power-users, qui ne comprennent pas les besoins de l'utilisateur « normal », n'est-ce pas !).

Rien n'empêche de proposer un binaire « toutes dépendances incluses » pour Windows ou Mac - ce qui, en effet, conviendra à la plupart des utilisateurs - tout en permettant aux différentes distributions linux d'intégrer le programme suivant leurs propres standards.

C'est tout bonnement ce que proposent la plupart des logiciels « grand public » présents à la fois sur windows, mac et linux ! Un petit exemple : sur le site de VLC tu peux télécharger un binaire complet pour windows ou mac sans avoir besoin de gérer toi-même les dépendances (ex : Qt4 pour l'interface graphique) ; mais si tu installes VLC sous linux, le gestionnaire de paquets de ta distribution te proposera d'installer automatiquement toutes les dépendances nécessaires, et le logiciel qu'il installera chez toi aura été spécialement compilé pour ta distribution.

Procéder ainsi, ce n'est pas forcément plus de travail pour les développeurs du logiciel. C'est plutôt la construction d'un exécutable complet avec les dépendances incluses qui représente un travail supplémentaire.

Un dernier aspect : ce n'est pas par hasard que beaucoup de logiciels libres sont conçus comme des « briques » qui peuvent être assemblées avec d'autres pour fournir aux utilisateurs les outils dont ils ont besoin. C'est le fameux principe_KISS, qui a fait le succès de nombre d'entre eux. Vouloir forcément « tout » inclure sans laisser le choix va à l'encontre de cette philosophie. (Mais c'est vrai qu'on s'écarte du sujet initial...)

L'objectif est de vraiment simplifier l'installation pour l'utilisateur final, il faut garder à l'esprit que la discussion ici est un peu élitiste...
C'est apparemment ici que le bât blesse : sous prétexte de simplicité, on en vient à faire les choix à la place de l'utilisateur. C'est un vieux débat...

En gros cela aboutit à :

1. Masquer certains aspects du logiciel. Je viens de télécharger le binaire générique d'Opale pour linux : une archive de 51 Mo, qui « pèse » 147 Mo une fois décompressée. À quel moment l'utilisateur qui télécharge et installe ce programme est-il informé qu'il contient, en plus d'une version patchée de xulrunner et imagemagick (compilés statiquement), rien moins que le JRE (Java Runtime Environment) de Sun ? À quel moment est-il informé, par ailleurs, que toute cette usine à gaz n'est prévue que pour une architecture 32 bits ? La plupart des utilisateurs de linux connaissent pourtant la notion de dépendances logicielles et savent choisir la version d'un programme qui correspond à leur architecture matérielle et leur distribution.

2. Restreindre les possibilités de choix pour l'utilisateur. Prenons l'exemple du JRE de Sun. Pourquoi imposer celui-là plutôt que de permettre à l'utilisateur d'utiliser scenari, s'il le souhaite, avec openjdk, qui est l'implémentation libre du JRE de Sun, soutenue par l'entreprise Sun elle-même, et que de nombreuses distributions considèrent maintenant comme le JRE par défaut ? Serait-ce parce que l'équipe de développement de scenari n'a pas pu tester ses programmes avec d'autres JRE que celui de Sun ? Je doute fort pourtant que ce qui fonctionne avec Sun JRE ne fonctionne pas avec openjdk. Pourquoi ne pas laisser la communauté des utilisateurs tester scenari avec différents JRE, et ainsi pouvoir profiter des différents retours d'expérience ?

Au bout du compte, je crois que les programmes de la suite scenari gagneraient à s'appuyer davantage sur la communauté des utilisateurs de logiciels libres, au moins pour tester ces programmes dans différents environnements et pour construire des packages destinés aux différentes distributions. Profiter des apports de la communauté, c'est bien l'un des avantages de développer un logiciel libre, non ?

Le principe d'embarquer le xulrunner est aussi d'être sur qu'on ne se base pas sur une version peu testé ou trop ancienne, par exemple sauf erreur de ma part, pas de xulrunner 1.9.1 dans lenny. De toute façon on doit l'embarquer sous windows et mac, si tout le monde utilise exactement la même version on évite les mauvaises surprises. Pour windows je veux bien, mais sous linux ce n'est clairement pas la meilleure approche... D'ordinaire, les développeurs se contentent d'indiquer que leur programme fonctionne / doit être construit avec telle ou telle version de telle ou telle dépendance ; ensuite, charge aux packageurs de créer des paquets viables à partir de ces informations.

L'objectif est de vraiment simplifier l'installation pour l'utilisateur final, il faut garder à l'esprit que la discussion ici est un peu élitiste... Pour beaucoup d'utilisateurs "tu l'installes et ça marche" c'est mieux que "tu l'installes, tu installes imagemagick s'il n'est pas installé, tu vérifies que tu as bien la JVM de sun et si tu en as plusieurs installées qu'elle est bien en première dans ton path, tu installes la version X.Y.Z du xulrunner, et ça marche", là ce serait comme le titre de ton message : "compliqué" :) On est prêt à sacrifier 40Mo de téléchargement pour être dans le 1er cas. Pour la plupart des distributions linux, c'est très contestable ! Le plus simple et le plus habituel pour les utilisateurs est d'installer un programme depuis leur gestionnaire de paquets préféré, qui s'occupera automatiquement des dépendances.

Je salue le travail que vous faites sur le projet scenari, mais je trouve que sur le point précis du packaging, vous vous compliquez un peu trop la vie - et aussi celle de l'utilisateur, du moins sous linux. Au passage, le titre « compliqué » n'est pas de moi, mais d'un autre utilisateur... qui a renoncé à utiliser scenari précisément pour cette raison.

L'avantage de pouvoir compiler soi-même le programme est non seulement de permettre de fabriquer assez simplement des paquets installables pour n'importe quelle distribution (ce qui est déjà pas mal), mais aussi de les lier dynamiquement aux dépendances, telles qu'elles existent dans chacune des distributions. On obtient ainsi des programmes plus légers et nettement mieux intégrés, tout en évitant les contorsions parfois nécessaires pour exécuter un binaire 32 bits sur une plateforme 64 bits. Au passage, je viens de regarder pour Opale (celui des projets qui m'intéresse le plus) : le binaire sous linux (compilé statiquement, si je comprends bien) pèse pas moins de 50 Mo !
Je ne sais pas précisément ce qu'apporte votre patch pour xulrunner qui oblige à inclure celui-ci statiquement dans les exécutables scenari, mais :
- S'il apporte quelque chose qui vous est utile, l'avez-vous proposé aux développeurs de xulrunner pour en faire bénéficier tout le monde ? Dans ce cas, si le patch est adopté, la nécessité d'inclure xulrunner statiquement disparaîtra.
- En quoi est-il indispensable d'inclure d'autres dépendances statiques, comme imagemagick par exemple, pourtant déjà présent dans toutes les distributions ?

Il me semble que ce problème vient du fait qu'il est très difficile de trouver comment construire soi-même les programmes de la suite scenari depuis leurs sources.
Si la marche à suivre était indiquée clairement, il y a fort à parier que des packageurs externes au projet scenari viendraient se proposer et effectueraient ainsi un travail qui, il est vrai, n'a pas forcément à retomber sur les développeurs du logiciel. C'est plutôt le boulot des distributions et de leurs contributeurs.
Pour l'instant, les seuls paquets disponibles sont pour ubuntu et debian (apparemment en 32 bits seulement ?), ce qui est dommage en effet.