David Tschumperlé a écrit 337 commentaires

Et je m'excuse auprès des développeurs de GIL d'Adobe, leur travail est très intéressant et instructif par ailleurs (j'ai regardé en détail leur présentation), même si je ne suis pas d'accord sur tout leurs concepts.

Bonjour,
Tu sais, j'ai pas mal discuté de çà avec Victor, et effectivement nous n'étions pas d'accord sur certains points. Je ne vais pas recommencer la discussion avec toi en profondeur, car ca risquerait d'être trop long.

Cela dit, tu t'emportes mais tu me parais bien prétentieux ! Pourquoi tu aurais toi la connaissance absolue de la façon de bien programmer ? Tu parles ici d'un sujet qu'apparemment tu ne maitrises pas : le C++ et ses spécificités, notamment la programmation générique à base de templates.

- Tu parles de séparation en .h et .cpp, c'est effectivement une technique assez classique mais dès lors que l'on parle de bibliothèque C++ générique utilisant à fond les templates, cette règle est généralement moins évidente, notamment quand le type des classes n'est connu qu'à la compilation (exactement comme quand on utilise la STL, qui est comme chacun sait, une bibliothèque faite avec les pieds par des débutants en programmation). Je peux te citer d'autres exemples. C'est un fait, la programmation générique utilisant des templates est un concept fort du C++ qui est assez particulier et qu'il faut prendre en compte.

- La plupart des classes du .h de CImg sont extrêmement bien séparées, et on peut tout à fait compiler la bibliothèque sans utiliser de display ou autres bibliothèques optionnelles. Ne t'arrête pas aux 50 premières lignes qui effectivement contiennent des tableaux de données dont j'ai besoin pour certaines fonctions. Si tu as le temps essayer de regarder un peu plus loin, tu verras que c'est bien structuré et très facile à lire (ce n'est pas le nombre importants de contributions et de corrections de bugs que je recois régulièrement qui va me dire le contraire, comme si bizarrement les gens avaient moins peur d'aller débugger un code de fonction plus court et bien localisé qu'un code étalé sur 50 fichiers différents...)

- Pour finir, je vais peut-être t'étonner, mais il y a un bon paquet de gens qui utilise CImg justement parce que c'est simplissime au niveau des dépendances et ca leur rappelle un peu la STL. Va voir dans les forums, je peux te trouver des messages absolument contraires au tiens qui encense cette structure. Alors bien sûr il y a des défauts je ne le cache pas (notamment le temps de compilation quand on active l'optimisation), mais beaucoup de qualités aussi, notamment le fait de pouvoir écrire des codes très courts (va voir la longueur des codes sources exemples fournis dans le package).

Bref je ne cache pas que CImg est un peu original, et a été clairement élaboré pour la programmation C++ générique. Alors oui ca s'interface pas très bien avec le python, et la structure ne ressemble pas à la façon typique qu'on enseigne en école d'ingénieur mais si c'est ton seul critère pour juger la valeur d'une bibliothèque, permets moi de te dire que c'est un peu léger.
Pour finir, CImg a maintenant 7 ans d'existence, et crois moi, si cette structure avait posé problème, je pense que ca aurait été modifié depuis bien longtemps.
Je pense qu'au contraire, elle a pu évoluer relativement rapidement grâce à cette simplicité d'écriture et d'utilisation.

Alors moi aussi je m'emporte, mais faudrais arrêter de vouloir donner des leçons comme tu le fais quand manifestement tu n'as pas plongé ton nez plus de 5 minutes dans cette bibliothèque. A l'inverse quand je vois que des gens "reconnus" (adobe) proposent aujourd'hui des bibliothèques de traitement d'images soit disant C++ qui s'utilisent avec des structures comme ca :

http://opensource.adobe.com/gil/html/giltutorial.html#Images(...)

Des fois je me dis que c'est pas la peine de faire du C++.

David.

Pour Krita et Digikam, j'ai mis au courant les développeurs des projets sur la mise à jour de GREYCstoration. Mais je crois savoir qu'ils se sont basés sur les sources du plug-in GIMP pour leur intégration, donc je ne sais pas si ils ont pu mettre à jour l'algorithme de leur coté.

En faisant l'extension à GREYCstoration ,j'avais justement dans l'idée de centraliser l'utilisation de l'algo GREYCstoration pour pouvoir proposer des mises à jours simples aux développeurs sans qu'ils aient besoin de répercuter beaucoup de modifs sur leur propre code.

David.

Apparemment, Victor avait déjà essayé de voir avec eux, mais ils ne veulent pas de plug-in basés sur du C++.
Peut-être peut-il confirmer.. Mais effectivement, c'est dommage.

David.

Oui, comme tout le monde.

En fait, quand je parlais du taux de compression, je parlais plutôt du paramètre
de "qualité" qui indique grosso-modo le nombre de coefficients DCT qui sont gardés lors du codage des blocs de l'image. Ce paramètre doit apparaitre quelque part dans l'en-tête du fichier JPEG, à mon avis au même titre que les dimensions ou le nombre de bits par pixels. Mais c'est peut-être plus compliqué que ça à récupérer...

Ca serait pas mal d'avoir l'information du taux de compression en % d'un JPEG, en plus du nombre de bits/pixel et des dimensions.
Je ne sais pas si c'est facilement accessible, mais les traiteurs d'images te remercieraient grandement pour cette feature très utile.

Je pense que tu peux utiliser GREYCstoration pour faire ce travail :

http://www.greyc.ensicaen.fr/~dtschump/greycstoration/

Il se lance en ligne de commande très facilement, et il est très paramètrable pour s'adapter au type d'image que tu as.

Tu peux faire une simple boucle en bash du style :

for i in *.tif; do greycstoration -restore $i -o smooth_`basename $i .tif`.png; done

Et si on supprimait les fumeurs plutôt ?
Ca règlerait tous les problèmes de tabagisme, plus le problème de la surpopulation à l'échelle mondiale.

Effectivement ta version de offset va plus vite.
Je pensais en écrivant offset qu'il fallait que je minimise le nombre de multiplications faites mais j'imagine que c'est des vieux reflexes de programmeurs de 68000 qui n'ont plus lieu d'être avec les proc maintenant.
Je commit.

Pour la modification du layout, je pense que ca risque d'être un gros travail de modifications dans pleins de fonctions si on veut faire ca correctement. J'ai souvent considéré le layout comme fixé et optimisé mes fonctions avec cette idée en tête, à coup de memcpy() et autres.

Pour ta version de offset, j'ai pas testé, je vais voir ca, ca a l'air intéressant.
Est-ce que ca risque pas d'être moins performant sur d'autres archi (proc PPC ou Sun par exemple ?)

Il est vrai que le choix de l'alignement est important.
J'ai opté pour un alignement 'plan par plan' plutot que de manière 'entrelacée'. Ce choix effectivement pénalise l'accès pixel par pixel quand on fait des traitement couleurs.
Mais inversement, c'est très adapté pour toute opération qui se fait composant par composante, comme le filtrage (flou, erosion, gradient, convolution, et j'en oublie d'autres), en fait toute opération intrinsèquement scalaire qui nécéssite l'accès aux voisins directs.

Je pense que si tu changes CImg pour avoir une structure entrelacée R,G,B,R,G,B, tu vas gagner sur certaines opérations mais tu vas en perdre sur d'autres. Le gain final (si il y en a un) n'est pas si évident à estimer.
Bien sûr j'ai pensé à faire des CImg qui pourrait avoir plusieurs manières différentes de stocker les données, manière qui seraient donnée à la construction par exemple. On rendrait ainsi la classe plus générique. Mais franchement, je trouve que c'est un peu du détail d'informaticien, et ca alourdirait pas mal le code pour un gain que l'utilisateur final qui veut juste faire du traitement d'image ne verrait pas forcément.
CImg ne s'adresse évidemment pas à des gens voulant faire de l'animation temps réel à la base, même si c'est possible sur des machines puissantes. Il est clair que des bibliothèques plus adaptées existent (SDL et consort).

Non car ton compilo sera optimisé pour les multi-coeurs, même pour compiler un seul fichier.

Dis toi que dans deux ans, ca compilera en temps réel de toute facon.

C'est ta vision des choses, n'hésite pas à la mettre en oeuvre si besoin est. Comme je te l'ai deja dit, je suis ouvert, et prêt à mettre ta version découpée sur le site de CImg, afin d'avoir éventuellement un retour des utilisateurs intéressés.

Personnellement, j'ai loin d'avoir le temps (et l'envie) de faire ce découpage que je juge un peu "artificiel".
En ce qui me concerne, je trouve le code de CImg très lisible, car compact et bien structuré.
Mettre ca en trois ou quatre fichiers m'importe peu, d'autant que les IDE de programmation actuels te permettent de naviguer aisément à travers les classes et les namespaces en dehors de toute structuration par fichiers.

Tu peux toujours utiliser les headers pré-compilés depuis gcc 4.x.

Ca fait maintenant 7 ans que je travaille sur CImg, et crois moi j'ai eu l'occasion de me poser des questions sur la structure de la bibliothèque pendant tout ce temps. Pour chaque choix que j'ai fait, j'ai pesé le pour et le contre, et je peux le justifier. Et si la bibliothèque a ajourd'hui cette forme, il y a des (bonnes à mon sens) raisons que je peux justifier.
Alors bien sûr, en programmation, on ne peut pas plaire à tout le monde, mais l'intérêt du libre c'est que tu peux reprendre le code et le modifier à ta sauce si ca te tente.

Beaucoup de gens ont critiqué CImg, simplement parce que son style ne rentrait pas dans les standards de programmation qu'ils avaient appris à l'école, et cela sans avoir lu plus de 3 lignes de son code. Je trouve ca ridicule : il faut savoir sortir des sentiers battus de temps en temps, sinon on coderait encore tout en basic.

Ne crois pas qu'on puisse pondre quasiment 20000 lignes de code (la longueur totale de CImg, ce qui est très peu en réalité) sans jamais se remettre en question.
Boost a un style propre et des buts qui n'ont rien a voir avec CImg, ca n'a aucun sens de les comparer.

Regarde bien, c'est exactement ce qui est fait actuellement.
Tout ce qui est affichage (et qui est refait pour chaque plateforme) est la classe CImgDisplay, et c'est tout.
La encore, la séparation est faite, simplement dans une classe à part. Si tu veux mettre cette classe à part dans un autre fichier, pourquoi pas, mais ca sera plus pour la forme (enfin pour ta forme :) ), puisque la séparation est déjà faite.

Tout le code propre au traitement d'image est de la même façon dans la classe CImg, qui elle ne contient aucun code spécifique à une plateforme donnée.

Le code est déjà très bien séparé en classes et en namespaces.
Le fait que ces classes soient définies dans plusieurs fichiers ou dans un seul ne change absolument rien ni à la vitesse de compilation, ni à la structure intrinsèque de la bibliothèque.
De toute facon, il n'y a que 5 classes, qui sont toutes nécéssaires en général.
Un découpage en fichiers headers multiples est artificiel et ne changera pas plus la structure de la bibliothèque que si je découpais CImg par blocs de 10 lignes ou je ne sais quelle autre décomposition.

Pour le nouveau entrant qui s'interesserait à la bibliothèque en elle-même, je pense même que c'est plus facile de faire un 'Search' du nom de la fonction dans un seul fichier plutot qu'un grep pour savoir deja dans quel fichier se trouve la fonction, puis un search.

Un bon compilo sait de plus aujourd'hui compiler uniquement les fonctions dont il a besoin, c'est d'autant vrai pour les bibliothèques templates qui ont un fonctionnement particulier.
Conclusion : Découpage ou pas, le compilo mettra non seulement le même temps à compiler, mais en plus produira le même code.

Après, ton a-priori sur la clarté du code de CImg... Passe 5 minutes à vraiment analyser le code et les classes, et dis moi si tout cela te semble vraiment incompréhensible. J'ai vu trop de gens affolé juste par le nombre de lignes qui disait : "non c'est trop gros, ca doit être le bordel". Bin en fait, non. Tout ca est extrêmement structuré.
Et d'après le nombre de contributions sans cesse croissant que je recois, je suppose que ca doit pas être si compliqué à comprendre pour des gens extérieurs.

Si elle est trop lente, tu devrais choisir une autre bibliothèque.
Ce n'est pas en découpant CImg en plusieurs fichiers qu'elle va aller plus vite.
Si tu as des optimisations de fonctions à proposer, dis le moi, je pourrai s toujours les intégrer dans CImg.
Je suppose que ce sera uniquement sur des fonctions précises, ca devrait pas être trop dur de faire un flag qui permet de choisir à la compilation les versions ASM ou C++ des fonctions, de la même façon que des flags permettent de compiler des fonctions pour X11 ou pour la lib GDI32 de windows.

Je ne comprend pas ta reaction. CImg est une bibliothèque. En quoi le fait que le style de code d'une bibliothèque te plaise ou non soit un critère pour l'utiliser, si elle remplit les fonctions pour lesquelles tu l'utilises ?

Est-ce que quand tu linkes ton code avec une autre bibliothèque, tu regarde son code avant pour être sûr que ca te plait ? Si le code ne te plait pas mais que tu as besoin de sa fonctionnalité, tu la recodes depuis le début ?

De la même manière, le code source du logiciel GREYCstoration utilise la bibliothèque CImg. Le fait que cette bibliothèque est en fait un header et non pas un binaire pré-compilé ne change rien au problème (si vraiment ca te gêne, tu peux facilement générer un fichier de code objet avec toutes les fonctions de CImg pour tous les types dont tu as besoin).

Ne serait-ce pas un peu une sorte de snobisme de programmation ?

Si bien sur math.h suffit.
Il faut bien voir que CImg est programmé en essayant d'être multi-plateforme et multi-compilateurs. Ca peut paraitre un détail mais rendre un code qui compile avec plusieurs compilateurs, c'est déjà pas facile. La redéfinition de PI a été nécéssaire ici pour une de ces raisons (un compilateur particulier (je ne sais plus lequel) ne connaissait pas le PI de math.h...).
Pleins d'autres trucs qui peuvent paraitre superflus sont présent justement pour que ca compile sur bcp de compilos.
C'est dommage, mais c'est le prix à payer pour avoir quelque chose de "portable".

Oui, mais il faut recompiler en spécifiant à g++ l'option '-D cimg_display_type=0'.

Non, malheureusement ce plug-in contient seulement la toute premier version de GREYCstoration qui a bien évolué depuis.

C'est bien l'ESSI ?

Ha oui désolé, autant pour moi.
Je vais cependant rebondir en conseillant quand même la version CVS, car le CImg.h qui est dedans (1.13béta) contient des fonctions légèrement plus performantes et avec moins de problèmes pour le chargement/sauvegarde des fichiers avec des espaces dans les noms :)