kif a écrit 4 commentaires

  • [^] # Re: Brevet pas valide en Europe

    Posté par . En réponse à la dépêche Recalage d’images, PIV et corrélation d’images — Les logiciels. Évalué à 1.

    Salut,

    Concernant la création des descripteurs, tu as l'air au point. Ce dont je me souviens (c'était il y a quelques années) c'est qu'après avoir trouvé l'orientation principale du gradient, on fait la même chose sur un voisinage (4x4 si je me souviens bien) avec des histogrammes sur les (8) orientations dans ces voisinages. C'est la dessus que se trouve le brevet je crois (en plus de la DoG).

    Le matching est assez simple en fait: il est basé sur norme L1 entre deux descripteurs, cette distance doit être la plus petite possible. L'idée un peu astucieuse est de dire qu'un descripteur A marche avec B d'un l'ensemble de keypoints si C, le deuxième meilleur de cet ensemble match beaucoup moins bien.
    soit: dAB < k.dAC avec k=0.53 (0.73*0.73, je sais pas d'où cela viennent ces chiffres).

    Je ne penses pas qu'il y ait de brevet non plus sur le matching. Il faut souvent valider le matching par un RANSAC.

    Voici une implémentation python (pour référence) du matching.
    https://github.com/silx-kit/silx/blob/master/silx/opencl/sift/match.py#L337
    Le reste du fichier c'est l'implémentation GPU.

  • # Brevet pas valide en Europe

    Posté par . En réponse à la dépêche Recalage d’images, PIV et corrélation d’images — Les logiciels. Évalué à 3.

    Merci pour la contribution.

    J'ai mois même bossé sur une implémentation open-source de SIFT et j'ai pris contact avec les ayant droits: pas de problème à ce que le code soit en licence MIT, les contraintes ne sont que pour les utilisateurs, pas pour le développeur. C'est a dire qu'il suffit pour les utilisateurs de ne pas être sur le sol américain. Et même dans ce cas là, il leur suffit de ne pas "faire d'argent avec" pour ne pas avoir besoin de licence.

    Si cela intéresse du monde, le code est ici:
    https://github.com/silx-kit/silx/blob/master/doc/source/Tutorials/Sift/sift.ipynb
    et je l'utilise pour recaler des time-lap (entre autre).

  • [^] # Re: Merci pour la pub

    Posté par . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 3.

    Je comprends pas trop ton point de vue. La carte Olimex utilise un chip A20 de chez AllWinner avec un GPU Mali400. Ni AllWinner ni le GPU de chez ARM ne sont particulièrement "libre-friendly". J'ai moi même un Pine64 basé sur le A64 du même fabricant avec le même GPU et franchement, les perfs ne sont pas terribles et pour l'instant on est toujours locké sur le kernel d'origine, la procédure de boot est pour le moins obscure … bref je ne n'en suis pas satisfait.

    A coté de cela, le Raspberry-pi 3 (et maintenant 2 aussi) utilise un cortex A53, dispose d'une bonne bande passante RAM, le GPU est certes ancien mais les drivers open-sources sont presque finis (en tous cas fonctionnel), le mécanisme de boot est documenté, tout comme le reste de la plate-forme.

    Ce serait juste le schéma du PCB de Olimex qui serait libre ? c'est léger comme argument commercial, non ?

  • # Numa c'est bien plus vieux ...

    Posté par . En réponse à la dépêche Sortie du noyau Linux 4.3. Évalué à 7.

    A ma connaissance, NUMA a été introduit dans le monde "x86" avec l'Opteron Hammer (dit K8) en 2003 et son contrôleur mémoire intégrée dans le processeur, en mode bi-processeur. En tous cas mon premier système NUMA était une workstation xw9300 de chez HP en 2005. Sur d'autres architectures, je ne sais pas …