David Tschumperlé a écrit 332 commentaires

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 :)

Attention, la version 1.12 de CImg ne contient pas la dernière version de GREYCstoration. Il faut prendre la version du CVS pour avoir GREYCstoration 2.3 !

Non mais je n'ai pas de de Mac à disposition.
Ou alors je ne comprend pas la suggestion.

En passant, je lance un appel à volontaires : j'aimerais compiler GREYCstoration pour MacOSX car j'ai eu quelques demandes pour ce système.
Malheureusement, je n'ai pas accès à de telles machines, et les deux Mac de la ferme de compilation de Sourceforge ne sont pas accessibles (depuis un petit moment d'ailleurs).

Ce n'est vraiment pas très difficile à faire, ca prend au pire deux minutes à compiler.

Si quelqu'un est intéressé pour le faire (ou l'a déjà fait), il peut me contacter directement sur mon mail du GREYC. Ca serait sympa d'avoir GREYCstoration pour Mac.

Préréquis : Avoir installé X11 pour MacOSX et avoir g++ >3.xx.

Merci d'avance !

Pour le moment c'est écrit en C++, je suppose qu'une bonne optimisation en assembleur de la boucle principale pourrait arranger les choses. SI quelqu'un est volontaire...

Merci pour tes impressions, j'ai corrigé le bug dont tu m'as parlé. J'ai également rajouté quelques infos sur les bornes admissibles des paramètres.
C'est dispo maintenant en téléchargement.