Edouard Gomez a écrit 450 commentaires

>Parce que xvid, selon la propagande libriste que j'ai entendue, repose sur la norme MPEG4 qui est brevetée.

Déjà, je dirais une première chose. Etant français, les brevets logiciels sur le MPEG4, je n'en ai rien à faire. Et je pense que pas mal de linuxfr'iens aussi (désolé pour les francophones du Canada et d'autres pays qui ont adopté de lois sur la propriété intellectuelle proches de celles des USA)

Puis en deuxième lieu, je te signales qu'en vidéo, plein de principes de base sont brevetés. A tel point que personnellement je juge tout simplement impossible de coder une image en la prédisant grâce à des références vers une image passée sans violer au moins un brevet déposé dans au moins un pays dans le monde. Des exemples, y'en a plein, prédire un vecteur de mouvement en prenant le vecteur median de ces voisins est breveté, prédire la valeur d'un pixel en utilisant une loi affine est breveté. IBM a déposé des brevets sur des techniques employées par XviD après que nous les ayons publiées (je pense au mode VHQ).

Theora ou XviD doivent violer des brevets l'un comme l'autre. Sauf que dans un cas, on tente pas de faire croire le contraire.

Donc à moins que tu te décides à ne pas contribuer à un seul projet de codec libre, alors acceptes de violer inconciemment des brevets dans dans plusieurs pays. C'est triste mais c'est comme ca.

>Je ne sais pas comment ca s'est passé avec toi Edouard mais si tu veux que ton projet continu a vivre, il faut que tu trouves surtout une personne hyper motivée pour apprendre et pas forcement un dieu du code car coder ca s'apprend. Une personne peu suffir pour fédérer un ensemble de compétence autour d'un projet.

Bah on a un chan IRC #xvid@freenode.org qui se voulait orienté developpeur. Au final, la notoriété d'XviD faisant son chemin, le chan s'est plutot orienté "utilisateur fan de la premiere heure". Donc de ce coté là, j'ai pas pu en tirer grand chose. Ensuite dans la communauté Doom9.org, y'a un tas de fanatiques lunatiques (je suis un peu méchant, mais je trouve que ces geeks butinent un peu tous les codecs, et n'hesitent pas à changer au lieu de fournir des efforts pour améliorer leur préféré du moment) qui s'extasient sur XviD mais qui dès qu'il s'agit de contribuer, hop deviennent invisibles. Donc parmi les gens plutôt môtivés auquels j'avais accès, personne n'était apte a reprendre.

Apres plus de 6mois où je disais a qui le voulait que j'allais partir, j'ai commencé à prévenir les gens qui m'envoyaient des patchs regulierement: "je vais arréter de maintenir XviD, merci de commencer a forwarder systèmatiquement sur xvid-devel pour que quelqu'un prenne en charge le patch". Puis biensur, appel aux autres dev de la xvid-team pour qu'une reprise du flambeau s'opère...

Au vu des maigres résultats, j'ai fais ma derniere release pour ne pas partir comme un sauvageon en laissant un CVS dans un état inconnu. Je pouvais pas faire beaucoup mieux.

> De ton temps y'avait combien d'autres contributeurs ?

Le probleme c'est que "mon temps" s'etale sur les 3 dernieres annees, donc j'ai vu passer des gens ponctuels, j'ai intégré celui qui a fini par devenir le plus gros contributeur (en terme de fonctionnalités).

Le probleme du comptage, c'est que t'as les membres fondateurs endormis qui ont jamais dit: je reprens ou j'abandonne. Du coup ils sont peut etre 4, peut etre 0. Au moins 1 semble reagir sporadiquement aux contributions (skal).

Sinon pour repondre a ta question, dans les moments les plus fastes on a été 6 codeurs simultannés. Une moyenne de 2 actifs est plus realiste sur l'ensemble 2001-2005, plus en general toujours quelqu'un pour bosser plus ponctuellement sur un port ou des correctifs.

>Le projet est peut-être mature et n'a pas trop besoin d'évoluer ?

Mature oui dans la mesure où les utilisateurs l'utilisent même face à DivX qui est une machine commerciale qui s'impose par le nom plutot que par les fonctionnalites intrinseques du codec.

Par contre il peut encore largement evoluer. Le code est generalement assez pauvrement correlé. Je veux dire que les APIs internes ont été peu travaillées car elles sont été dictées par les besoins du moment. Et ca s'en ressent. Donc y a du travail du fond (fonctionnalites pouvant etre rajoutées) et du travail de forme (meilleur code).

>Y'a peut-être des alternatives beaucoup plus populaires qui attirent les contributeurs ?

DivX qui a la puissance commerciale, et une palanquée d'outil pour mr tout le monde afin de convertir en "un clic" ses videos.

Sinon dans le monde du libre, y a FFMPEG qui integre un codeur ISO MPEG4. Mais il est un chouilla moins bon qu'XviD car FFMPEG axe beaucoup son travail sur la partie decodeur. La partie codage n'est pas la plus active d'FFMPEG.

Et pour l'avenir, y a juste a dire que ISO MPEG4 Part 2 (Norme sous jacente a XviD, DivX4/5/6, FFMPEG MPEG4 etc...) est vieille de presque 5ans, et que y a h264 qui est archement plus sexy et mieux adopté par les professionnels du hardware (futur DVD-HD)

Donc pour conclure, sous des OS libres où DivX est pas dispo, t'as deux choix: xvid ou ffmpeg. Donc c'est pas non plus la fragmentation d'efforts entre projet qui explique la non evolution d'xvid.

Moi je pencherai plus à une désertion par niveau d'entrée trop élevé. Le codage vidéo c'est pas facile, y a plein de maths derrière et ca en rebute surement plus d'un.

>En effet, un programme peut modifier ses octets partout où il le souhaite sans générer un seul SIGSEGV tant qu'il reste dans sa plage de mémoire réservée par le système

Petite imprécision.

Le programme peut modifier les octets partout où il le souhaite dans ses segments mémoire marqués en écriture (bss/heap/stack etc...) sans générer un seul SIGSEGV.

> Par hassard aurais tu fais des tests sur l'interuption de la transaction lors d'un commit ie une coupure du reseau

Lorsque tu commite, tout se passe en local, je pensais que ce détail était connu, puisque Mercurial est un SCM distribué, c'est à dire que ton checkout est equivalent à un repository. Donc tu n'as pas besoin de te connecter pour commiter.

>ou un kill lorsqu'il est entrain de commiter les modifications

Ah bonne question, celui je testerai ce soir. Ceci dit, mercurial a une tendance folle a n'opérer qu'en append et ecrire les index qu'en fin de transaction, donc ca devrait pas casser trop souvent.

http://www.selenic.com/mercurial/(...)

--
Templeet m'a tuer le lien

L'assembleur AT&T est assez illisible, je le concede :-)

D'apres: http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_mono/as.(...)

un triplet se lit (base, offset, scale) ce qui en C donnerait *(base + offset*scale) pour un pointeur base char* (car sinon en C l'offset 'offset*scale' serait multiplié par la taille du type pointé).

Voila

Mount ne prend soin de monter que les partitions de type connus, ici iso9660.

Or un cd musique est composé de track sans aucun filesystem informatique sous jacent. Il y a en revanche une norme regissant comment graver les tracks audio (commant marquer une piste, ou mettre les channels de controle d'erreur etc...)

Donc que tu ne puisses pas monter un cd audio est normal.

Les applis utilisent un set d'appels systemes différent qui ne necessitent pas un montage pour acceder aux tracks audio. Donc mets ton CD audio, sois sur d'avoir configuré correctement tes emplacements CD Audio (en general indiquer le device et/ou le point de montage), va dans le repertoire de montage... le logiciel devrait faire le reste et te faire croire que il y a N fichiers .cda représentant chaque track audio ou bien directement commencer la lecture audio.

Quand on souhaite inviter les gens a troller, on respecte l'ordre naturel de choses qui veut que:

s,'à lire l'article avant de troller','à troller avant de lire l'article',g

Dans ton code L80@serial.c:
strftime(iso_time, (size_t)20, "%Y-%m-%d-%H:%M:%S", localtime(&timing);

devrait etre:
strftime(iso_time, (size_t)20, "%Y-%m-%dT%H:%M:%S", localtime(&timing);

Notes le T qui separe la partie YYYY-MM-JJ et l'heure:min:sec.

C'est decris dans le standard ISO 8601, dont une reference est faite dans un document du w3c par exemple:
http://www.w3.org/TR/NOTE-datetime(...)

Juste une remarque Out Of Topic en passant, désolé du dérangement.

Sous Win32 l'ABI C impose de prefixer tout symbole par un underscore lorsque celui ci utilise la convention d'appel C standard.

De meme les symboles utilisant la convention stdcall (toute l'api win32 par ex), ne prefixe pas, mais ajoute un suffixe @${n} ou n est la taille totale prise par les arguments sur la pile si je me souviens bien.

Sous GNU/Linux, l'ABI C suivie n'est pas la meme.

Voila la raison :-)

En general, la solution consiste à avoir une macro:
#if defined ( _WIN32)
SYMBOL_NAME(symbol_name) _##symbol_name
#else if defined (__linux__)
SYMBOL_NAME(symbol_name) ##symbol_name
#else
#error SYMBOL_NAME not defined !!!
#endif

Je te laisse en exercise le soin de corriger les erreurs eventuelle de cette macro non testée.

Uitiliser le langage sh tout naturellement

.profile
#!/bin/sh
if [ -f ${HOME}/.bashrc] ; then
. ${HOME}/.bashrc
fi

.bashrc
#!/bin/sh
echo Je suis trop malin

Je vais tester ca, une fois mes tests avec monotone achevé.

Moi je veux une photo a chaque arret avec le metro/20 minutes du jour !

>mais l'avantage de la technique en 3 lignes, c'est qu'il n'y a pas besoin de recompiler le noyau...

Mais depend du format de FS utilisé pour le initrd :-)

LA solution pour ne plus dependre du type de FS consiste a:
- gunzip initrd.gz
- mount -o loop initrd /mnt/initrd
- cp DSDT.aml /mnt/initrd/
- umount /mnt/initrd
- gzip -9 initrd

Il faut aussi t'assurer que le DSDT.aml soit chargé par les modules ACPI, et la je m'arrete car je ne me sers pas de l'acpi moi meme et je ne peux donc pas t'aider plus.

Merci pour les tips. Sinon pour passer le log dans la ligne de commande je suis pas trop d'accord, on peut vite etre farppé par la malediction de la ligne de commande trop longue si jamais tes messages commits sont precis, explicatifs et donc bavent d'informations :-)

Sinon un coup de "export EDITOR="cat"" pourrait faire l'affaire histoire de voir defiler le commentaire de commit sans l'editer.

Par contre je me fais toujours pas aux revisions par hash, c'est un peu la misere pour communiquer sur le projet:
- "Dis Toto, tu as mergé 01f5e9964547da4cb8e9 ?" (un sha1 c'est encore plus long ;-))
- Ah non, Titi, pas encore, je regle des conflits sur 1e5b6985c9a65f9145de23b.
- Ok ok, toto, moi je vais prendre une aspirine en tout cas, parler de commit monotone, ca me file la migraine.

:-)

Je me moque, mais c'est pas bien serieux comme moquerie.

bazaar est une amelioration de tla, qui se concentre sur l'utilisabilite de l'interface cli et de quelques fondamentaux defecteux de tla, mais il ne vise pas une cassure rapide avec tla.

bazaar-ng c'est plutot un projet qui part de rien, completement incompatible avec arch/tla. L'objectif est de se baser sur les idees de arch tout en les implementant completement differement afin de ne pas repeter des erreurs de conception aui limite tla aujourd'hui.

Donc a part le nom, ce sont deux choses tres differentes.

>J'aimerais connaître ta position (ou tes craintes) sur le devenir d'XviD face au nouveau DivX 6 qui sortira très prochainement.

DivX6 sera comme ses predecesseurs, de la poudre aux yeux en terme de gain de qualité reelle. DivX n'a pas sorti un seul codec innovant depuis DivX5.0. Depuis DivX5, ils multiplient les features qui ne donnent au final que de bien maigres gains pour de si longue seance de codage (mode insane == 1.7x plus lent que xvid avec toute option a fond, pour une qualite moindre dans bien des cas): le npass, le mode insane, les bvops implementes de facon partielle, le GMC a un seul warp point (donc inutile car incapable de simuler les mouvements de caméra autre que la translation) etc etc.

Donc DivX6, je retiens que ce sera surtout un nouveau container... sur PC l'adoption d'un container reste facile, il suffit d'avoir un demultiplexer adequat (splitter sous DShow, ou module quivabien pour nos utilitaires unix). Leur format aura du succes uniquement si l'industrie de players hardware suit. Si elle ne suit pas, ce format restera cantonné au PC et autre player plus évolué qu'une platine de salon, et ne touchera donc pas Mr tout le monde.

Ma crainte pour xvid, c'est que les developpeurs qui restent sur le projet sont de tres loin, les moins actifs de ces deux dernieres années. Le projet est donc fortement compromis dans son évolution. D'autant plus que les codecs h264 arrivent, alors il attirera de moins en moins de personnes, car pourquoi s'embeter a coder sur des vieilles normes, quand on a des trucs bien plus sexys avec lesquels on peut s'amuser aujourd'hui (ie: x264)? :-)

Une idée en l'air comme ca, mais est ce que Firefox ne met pas ses fichiers dans ${TEMP} par defaut, jusqu'a ce qu'on choissise l'emplacement du fichier ?

Dans ce cas, il se pourrait aussi que Firefox, rusé comme il est, conserve le fichier dans ${TEMP} si la destination n'a pas assez de place.

>Enfin j'ai du mal à croire que Linus soit un imbécile pas pragmatique du tout.

Je tiens juste a dire que mes propos n'ont jamais présenté Linus comme un imbécile. Ce sont tes propres conclusions.

Aussi je voudrais répondre à l'argument "Linus a bien codé Linux ! C'etait spécifique".

Sauf que les deux cas sont peu comparables.

Dans le cas de Linux, il n'y avait pas de noyau Unix-like tournant sur le i386 que Linus utilisait. Minix avait une architecture qui ne correspondait pas tout a fait au modele unix traditionnel, de plus la license ne convenait pas. Et a l'epoque 386BSD n'existait pas si je me trompe pas.

Aujourd'hui Linus a au moins 3 projets sur lesquels se pencher, avec une license qui convient. Dans les 3 cas, ca peut faire ce qu'il cherche a faire, c'est a dire stocker/manager des changesets.

L'excuse du manque de temps pour faire accepter ses vues dans les divers projets, c'est une excuse bien tardive. Il a eu 3 ans pour chercher un remplacant. Or pendant 3 ans, il n'a fait que demonter (verbalement) les solutions de rechange proposées par divers kernel dev (dont Arcangeli) et retorquait toujours que BK lui convenait et tant qu'aucun projet libre ne donnerait exactement les meme features, il utiliserait BK. Or aujourd'hui bizarrement, GIT ca va lui convenir, or GIT c'est un embryon de SCM, bien loin de couvrir ce que fait BK, et Monotone/Darcs/Arch....

Alors maintenant qu'il reparte dans une implementation d'un simili-SCM-tronqué dont on peut douter de la durée de vie, ca me derange pas du tout. Il est libre de faire ce que bon lui semble. Par contre, qu'il chippe les forces de dév en attirant des gens sur un projet à la durée de vie contestable (solution de rechange d'après ses dires), et dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.

J'ai un peu suivi l'evolution du developpement de GIT sur la LKML... et de mon point de vue, je crois que Linus Torvalds ne semble pas regarder plus loin que ses besoins immediats.

Il a à peine évoquer les raisons qui l'ont poussé à rejeter Monotone. N'a pas cité Arch, ni Darcs. Je parlerai principalement d'arch/tla ou bazaar car c'est le SCM que j'utilise depuis plus de 2 ans, mais j'ai aussi regardé du coté de Monotone recemment, voir du tres tres jeune bazaar-ng (plus proche de monotone dans sa gestion du tracking des sources).

Ayant utilisé arch/tla, je sais que ce n'est pas une solution viable aujourd'hui, car tla (ou bazaar) se trainent des problemes de conception qui remontent au prototype arch/larch codé à coup de sh/gawk/gnutar/gnudiff par Tom Lord qui cherchait à valider les idées fondatrices de son futur outils de versionning. Je ne donnerai ici que quelques examples:
- le gachi monumental d'inode pour l'historique (qui devient un cauchemar sur des FS comme ext2/3, et est un peu pres vivable sur des FS comme ReiserFS qui merge les petits fichiers directement dans l'inode).
- des conventions de nommage qui sont bien loin de toutes les habitudes
- une CLI trop centrée autour du design interne du code et pas assez orienté user (c'est ce que tente de reparer bazaar)
- une redondance monstre dans le suivi des patchs mergés (c'est pas optimal, mais ca marche)
- des doublons dans les possibilités laissées a l'utilisateur pour avoir un tla efficace (pristines trees hardlinkés, revision libraries...)
- une documentation qui se ne couvre meme pas tout car le dev de tla a connu une periode tres riche et la doc n'a jamasi suivi).

Vu comme ça, arch/tla ou bazaar peuvent sembler bien nuls, mais en fait pour des projets de taille raisonnable (pas un noyau linux en somme), c'est largement suffisant à condition de s'imposer quelques restrictions sur sa gestion des archives. C'est pour ça, que je continue à utiliser bazaar.

Aussi, Andrea Arcangeli (auteur de la VM des noyaux >= 2.4.10 iirc) avait jeté un coup d'oeil sur tla, et avait proposé des améliorations qui auraient permis à des dev de bosser sur des arbres de source comme linux. Il avait réussi à obtenir plus ou moins le type de résultats que Linus obtient aujourd'hui avec son outil GIT pour la génération d'un patchset entre deux arbres... mais bon d'autresdéfauts de tla me font croire que tla n'est pas capable de gérer les quelques 60000 patchsets du noyau 2.5/2.6 par exemple. Sur XviD avec seulement 600 patchs, y'a des fois ou je me dis que arch/tla a quelques defauts :-).

Enfin bon, ce que code Linus, est plus proche du mode de fonctionnement de Monotone, qui maintient un inventaire des fichiers de source en leur attribuant leur somme SHA1, que de arch/tla.

Puis certes, comme le dit Linus, Monotone est lent. Mais je trouve plus que dommage, qu'au lieu d'investir un peu (tant en termes d'efforts de dev ou d'argent) sur l'evolution d'un SCM decentralisé existant qui serait utilisé par les devs de Linux, bah Linus choisit la voie du "je me fais ma sauce dans mon coin".

Bizzarement sur la LKML, personne ne semble s'en rendre compte et tout le monde se penche sur ce GIT que "comme c'est Linus qui code, c'est trop de la bombe, faut trop que je mette mon nom dans le AUTHORS".

PS: je sais, que mes propos peuvent sembler prétentieux, mais si on reflechi deux nanosecondes, c'est pas bien dur de voir que Linus s'embarque dans un choix qui risque d'engendrer un outil purement dédié à SES besoins et à rien d'autre. Bref un peu un gachi, car il va monopoliser des forces de développement dont auraient pu profiter plus de personnes en travaillant sur un SCM plus générique.

>Peux tu nous livrer quelques conclusions sur les

>pistes

XviD est maintenant une mecanique bien rodée. Les algorithmes de Motion Estimation sont stabilisés depuis pas mal de temps maintenant et on ne peut plus trop espérer les améliorer. La suite sera donc surement principalement orienté sur deux axes:
- Reduire la complexité des algos, afin de gagner des cycles et par consequent, pour un meme temps de codage, permettre l'utilisation d'options plus gourmande. On optimise en vitesse pour que l'utilisateur a machine constante puisse activer plus d'options pour la qualité -> gain de qualité a temps de codage constant.
- Ameliorer les algos de ME. Tache plus difficle mais pas insurmontable pour les courageux. sysKin avait beaoucoup travaillé sur les algos dit "rate distortion optimized (RDO)" dans XviD 1.x pour le choix des blocs (vhq1) et pour l'evaluation des vecteurs de mouvements candidats (vhq>1). Ces fonctions RDO d'evaluation utilisent toutes des contantes magiques qui permettent d'etablir une relation entre R (le nombre de bit codés) et D (distortion entre l'image originale et l'image codée, grandeur assimilable a l'energie de l'erreur de codage), et F(type de bloc) qui donne une cst par rapport au type de bloc qui represente le nombre de bit employes de facon constante dans la grammaire du bitstream du bloc codé:
R = F(type bloc) + Lambda*D
XviD utilise un lambda constant, pour gagner en qualité, il est envisageable de passer à un lambda optimum pour le bloc codé... en gros rendre le Lambda un poil adaptif a la source.... J'ai pas d'url a proposer pour obtenir les publications sur le sujet, dsl.

>astuces

Pas d'astuces désolé, optimiser tant en qualité qu'en vitesse, c'est toujours un travail assez fastidieux et minutieux.

>Trucs a faire

Ouais, plein ! d'abord le code d'XviD est pas si bien designé. Donc un travail plus ou moins facile consisterait a nettoyer les APIs internes tout en ayant une correspondance 1:1 avec le resultat des vieilles versions. Une autre tache moins excitante, completer la doc dispo sur mon site.... bref XviD est un projet plutot en maintenance, les codeurs fous passeront surement leur chemin, les autres, trouveront toujours quelque chose a nettoyer, redisigner etc...

Autre truc a faire, continuer a tester, remonter les bugs de facon precise (avec une lib compilée pour debug et un coup de gdb et le contexte de pile etc etc)... bref ce que tout logiciel libre demande à ses power users.

>Trucs a ne pas faire

Appeler les fonctions inutilement: toujours n'appeler une fonction que si c'est necessaire, meme si cela impose de garder en memoire l'etat de tes objets (au sens conceptuel, pas OOP) pour savoir le travail qu'il reste encore a effectuer dessus.

La consommation inutile de memoire reduit aussi beaucoup les perfs de facon indirecte. Reduire les besoins memoire permet souvent d'etre moins gourmand en bande passante... moins d'acces memoire, c'est moins de temps perdu dans les cache miss et le rapatriement sur les bus memoires qui representent de vrais goulot d'etranglement comparativement aux 3GHz de nos CPU...

Mettre des tests dans les boucles critiques, preferer une boucle critique par cas a traiter.

... je pourrais en parler des heures... mais tout a une fin :-)

>As-tu de nouveaux projets ? En particulier dans les codecs video ?

Non, rien de particulier en vue. Je n'ai plus trop de temps libre ces derniers temps...

Je redeviens donc avec plaisir un simple utilisateur de logiciels libres, meme s'il m'arrive encore parfois, d'aller fouiner dans le code des applis pour changer quelques trucs afin de les adapter a mes besoins.

>Peut-être qu'ici c'est un des rares et/ou derniers cas où l'accessibilité (bien sûr pas au niveau inter-plate-formes) est meilleure dans un format propriétaire que dans un quelconque format "libre"... espérons que cela change vite.

Une réponse rapide car on a attiré mon attention sur IRC à propos de ce post et on m'a demandé de répondre, mais il se fait super tard.

Le format Quicktime dont tu parles, n'est pas un format à proprement parler. Quicktime est malheureusement un terme tellement générique dans la monde Macintosh, c'est le nom de: codecs, de containers, d'un Framework multimedia...

Le Quicktime que tu sembles aprécier, est le Quicktime container, les .mov, pas leur contenu, Or dans ce cas, il existe des containers dont les spécifications sont publiques, et libres de droits qui peuvent faire autant que les .mov car ils supportent le multipiste, OGG et Matroska.

Biensûr à cela tu peux répondre, "oui mais non, ogg ca a jamais été pensé pour autre chose que vorbis, preuve en est les .ogm (1piste video+1piste sonore) sont meme pas officiellement reconnus par Xiph.org". A cela je repondrais, que ce n'est pas parce que aujourd'hui ce n'est pas utilisé que ce n'est pas possible. Il suffit dans ce cas de spécifier les identifiants marquant certains contenus... et le tour est joué. Matroska quant à lui est déjà plus complet dans la mesure où sa spécification intègre déjà bon nombre de concepts: multipiste video, multipiste audio, sous titres, chapitrage etc etc...

Bon j'arrete la, il est vraiment trop tard.

PS: meme les AVI sont multipistes, seulement faute d'un reel support de la part de MS, les AVI multipistes n'ont jamais décollé. Ceci dit, DivX(tm) n'a pas hésité à mettre glisser les sous titres directement dans les AVI dans la derniere version de sa suite d'outil de compression video... comment faire du neuf avec du vieux :-)

Ca ne regle malheureusement pas le probleme de fond qui est double:
- Pour chaque pixel, on integre sur une assez grande zone autour du pixel courant, ce qui bouffe une bande passante mémoire énorme.
- On traite l'image pixel par pixel, diminuer le ratio CLOCKS/Pixels.

Les solutions imaginables pour le premier point:
- Etre sur de bien aligner le tout, mine de rien, des lectures de memoire alignées c'est plus rapide pour le CPU/Controleur memoire.
- Penser à utiliser au maximum le cache CPU en travaillant sur des données le plus localisées possible et si possible se servir autant de fois que possible de chaque acces afin de ne pas avoir a y revenir plus tard.
- Voir si certains calculs pourraient utiliser moins d'acces memoire, selon que l'algo s'y prete ou pas, envisager la reutilisation de resultats precedents couvrant un grand nombre d'acces memoire.

Les solutions imaginables pour le second point:
- Regarder de plus pres l'utilisation de tout opérateur couteux (/ et *) et donc minimiser petit a petit les nombre de cycles necessaires par pixel.
- Il faut voir si on ne peut pas prévoir une vectorisation de la transformation pour pouvoir optimiser le tout en utilisant les instructions SIMD SSE d'abord, puis si on est vraiment très courageux, passer en SIMD iSSE (mais attention, il faut bien prévoir la precision de calcul en virgule fixe sous peine de tuer l'intégration ç cause de l'accumulation d'erreurs d'approximations).

Voila, c'est toujours les memes concepts d'optim qu'on doit mettre a l'oeuvre. La plupart du temps, chaque technique d'optim est limité par l'algo qui se prete plus ou moins au jeu.

A savoir que le mieux reste d'optimiser l'algo avant de penser a partir dans les delires de reduction d'acces memoire et de vectorisation.