Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1688 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  Comment lire une image d'un fichier en C++

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Comment lire une image d'un fichier en C++

n°1725205
fedora6
Posté le 27-04-2008 à 18:54:11  profilanswer
 

Bonjour à tous, :hello:
J'ai une image enregistrée dans dossier(.jpg) et je veux la lire avec c++ pour l'utliser comme variable d'entrée pour une fonction.Si quequ'un peut m'aider je serais trés reconnaissante.Merci d'avance pour tout le monde.

mood
Publicité
Posté le 27-04-2008 à 18:54:11  profilanswer
 

n°1725236
Joel F
Real men use unique_ptr
Posté le 27-04-2008 à 20:13:40  profilanswer
 
n°1726243
fedora6
Posté le 29-04-2008 à 14:19:56  profilanswer
 


Bonjour,  
Merci pour votre réponse, mais j'ai cherché sans résultat :sarcastic:  si vous pouvez m'élaircir un peu.
Merci d'avance.

n°1726246
IrmatDen
Posté le 29-04-2008 à 14:20:58  profilanswer
 

Tu veux faire quoi au juste?

n°1726248
fedora6
Posté le 29-04-2008 à 14:22:43  profilanswer
 

IrmatDen a écrit :

Tu veux faire quoi au juste?


J'ai une image je veux la lire pour l'utilisé comme variable d'entrée pour une fonction.

n°1726253
skeye
Posté le 29-04-2008 à 14:26:47  profilanswer
 

fedora6 a écrit :


Bonjour,  
Merci pour votre réponse, mais j'ai cherché sans résultat :sarcastic:  si vous pouvez m'élaircir un peu.
Merci d'avance.


 
ya plein de résultats là:
http://www.google.com/search?q=boo [...] =firefox-a
et là:
http://www.google.com/search?q=boo [...] =firefox-a


---------------
Can't buy what I want because it's free -
n°1726274
IrmatDen
Posté le 29-04-2008 à 14:40:51  profilanswer
 

fedora6 a écrit :


J'ai une image je veux la lire pour l'utilisé comme variable d'entrée pour une fonction.


Ca, c'était marqué dans ton premier post, mais ça ne nous dit pas ce que tu veux en faire. Juste utiliser le chemin ou décoder l'image et appliquer une série de transformations? (auquel boost.gil est tout indiqué par exemple, tout comme CImg avec les bons plugins de lecture ou d'autres libs, y'en a quelques unes selon l'usage à faire)


Message édité par IrmatDen le 29-04-2008 à 14:41:11
n°1726290
fedora6
Posté le 29-04-2008 à 14:54:34  profilanswer
 

[quotemsg=1726274,7,242237]
Je veux juste utiliser le chemin aprés la fonction dont l'image sera une variable d'entrée comme je vous ai dis se chargera de traiter l'image et de vérifier s'il y en a une couleur rouge dans l'image, je sais pas si je me fait comprendre.

n°1726294
IrmatDen
Posté le 29-04-2008 à 14:59:41  profilanswer
 

Si t'as juste à passer le chemin, tu passes un std::string qui représente le chemin. Je vois pas où est le problème; tu veux pas montrer ton code ? :sweat:

n°1726302
fedora6
Posté le 29-04-2008 à 15:08:16  profilanswer
 

[quotemsg=1726294,9,242237]
 
J'ai pas encore un code, je viens juste de commencer, je dois pouvoir donner le chemin et que ça soit valide et réussir à ouvrir l'image puis s'occuper de la manipuler par l'autre fonction.

mood
Publicité
Posté le 29-04-2008 à 15:08:16  profilanswer
 

n°1726307
IrmatDen
Posté le 29-04-2008 à 15:18:54  profilanswer
 

Ben dans ce cas commence, et si tu as un problème tu reviens à ce moment.

n°1726315
fedora6
Posté le 29-04-2008 à 15:29:26  profilanswer
 

Merci bien et je m'excuse si je vous embête par mes questions, mais je sais pas d'où commencé.
Pour la manipulation des fichiers je sais utiliser le fopen, fprintf, fscanf, fclose mais c'est pour des fichiers textes mais comment faire s'il sagit d'une image c'est ça mon probléme.

n°1726542
ptitchep
Posté le 29-04-2008 à 20:32:53  profilanswer
 

pas de fopen, fprintf fmachin en C++
http://www.cplusplus.com/doc/tutorial/files.html (trouvé dans la bibliolink c++)


---------------
deluser --remove-home ptitchep
n°1735144
tourneviss​ette
Posté le 21-05-2008 à 12:30:21  profilanswer
 

Moi je te conseille d'utiliser CImg (http://cimg.sourceforge.net), cette bibliothèque fait toutes les opérations nécessaires sur les images à ta place, sans avoir à s'embêter. Tu peux par exemple écrire :
 

CImg<> img("mon_image.bmp" );


 
et hop ! ton image est chargée !
 

img.display("mon image" );


 
pour l'afficher, etc... C'est quand même très pratique de plus avoir à manipuler directement les données.
Et en plus, il s'agit d'un simple en-tête à inclure...


Message édité par tournevissette le 21-05-2008 à 12:31:39
n°1735246
Joel F
Real men use unique_ptr
Posté le 21-05-2008 à 14:49:37  profilanswer
 

CImg ... ca existe encore ce .h indigeste ?

n°1735250
tpierron
Posté le 21-05-2008 à 15:03:36  profilanswer
 

Clair qu'elle est imbitable cette "lib".
 
Sinon si tu es sous Windows, tu peux utiliser gdi+ (note le +) pour lire et manipuler tes images (JPG, TIFF, BMP). L'API est super simple et bien foutue.
 
Avantage : dispo en standard sur tous les windows > 2000 et redistribuable aussi sur les autres versions.
 
Inconvénient : j'ai du un peu bidouiller pour compiler avec MinGW.

n°1740577
tourneviss​ette
Posté le 02-06-2008 à 23:23:34  profilanswer
 

Joel F a écrit :

CImg ... ca existe encore ce .h indigeste ?


 
La bonne blaque ! :lol:  
Sans rire, à ce que je sache, la STL c'est majoritairement des .h "indigestes" et je crois pas qu'on peut en redire grand chose.En C++, quand tu as des classes templates, tu es en général assez lié à des .h 'indigestes'. CImg définit des classes images génériques, ca explique la structure en .h.
Moi elle m'a sauvé plusieurs fois cette lib, et elle est *vraiment* portable, pas comme l'utilisation des fonctions de la lib gdi de windows..
 

n°1740589
tpierron
Posté le 03-06-2008 à 02:10:12  profilanswer
 

tournevissette a écrit :

Sans rire, à ce que je sache, la STL c'est majoritairement des .h "indigestes" et je crois pas qu'on peut en redire grand chose.En C++, quand tu as des classes templates, tu es en général assez lié à des .h 'indigestes'.


 
Hum, 31353 lignes de code pour 1578Ko (dans un seul fichier bien-sûr). Je pense que le qualificatif d'indigeste est largement mérité, même qu'on est relativement de l'anti-pattern en matière de design de bibliohèque. Rappelle-moi lorsqu'un .h de STL atteindra ne serait-ce que le dixième de cette lib.

n°1740632
Joel F
Real men use unique_ptr
Posté le 03-06-2008 à 09:08:54  profilanswer
 

tournevissette a écrit :


En C++, quand tu as des classes templates, tu es en général assez lié à des .h 'indigestes'. CImg définit des classes images génériques, ca explique la structure en .h.


http://img134.imageshack.us/img134/104/captainobviouslb4.jpg
 
j'ai dit 1 .h pas des .h  
et je passe sur le fait de m'apprendre comment marche les templates [:pingouino]
 
CImg est une atrocité en bien des points ...

n°1740717
tourneviss​ette
Posté le 03-06-2008 à 11:15:00  profilanswer
 

La seule différence c'est que la STL définit des classes qui ne sont pas inter-dépendantes, contrairement à CImg. Ce qui veut dire que tu vas avoir forcément besoin de toutes les classes pour l'utiliser (contrairement à la STL). C'est très bien expliqué dans la FAQ. Je ne crois pas que faire des classes inter-dépendantes soit une erreur de conception. Mais bon, tu as ton avis, et j'ai le mien.
 
Le tout c'est de laisser les gens se faire leur propre avis.
Balancer des phrases comme "CImg ... ca existe encore ce .h indigeste ?", c'est pas constructif pour un sou, au pire ça montre que tu es prétentieux et que tu as un avis sur tout sans argumentations.
 
Quand j'utilise une lib, je regarde l'API et la facilité d'utilisation, je me fous un peu de comment çà a été fait, du moment que ca marche, et sur ce point CImg marche très bien et est très pratique (et en plus c'est bien conçu à mon avis).
Je me permets donc de la conseiller à toutes les personnes voulant aborder facilement le traitement d'images.

n°1740719
Joel F
Real men use unique_ptr
Posté le 03-06-2008 à 11:21:58  profilanswer
 

tournevissette a écrit :

La seule différence c'est que la STL définit des classes qui ne sont pas inter-dépendantes, contrairement à CImg. Ce qui veut dire que tu vas avoir forcément besoin de toutes les classes pour l'utiliser (contrairement à la STL). C'est très bien expliqué dans la FAQ. Je ne crois pas que faire des classes inter-dépendantes soit une erreur de conception. Mais bon, tu as ton avis, et j'ai le mien.


 
 :sweat: v_v un fan boy ...
 
Pour faire court, j'ai rien contre faire des classes "inter-dépendantes" (sic) mais bon, la compilation séparée c'est pas pour les lévriers ousbeques.
Si Mr CImg ne sait pas faire de forward declaration et écrire plus de un .h j'y peut rien, et son argumentation a base de 'y a que un fichier c'est cool" est  
au moins aussi ridicule que sa librairie. On est plus en 1933, les compilos savent gérer les incldudes multiples :E
 
Encore une fois, j'ai rien contre la lib en elle même, elle résout qqs problèmes mais son exécution est à chier.

n°1740751
tourneviss​ette
Posté le 03-06-2008 à 11:59:30  profilanswer
 

Quelle arrogance, là c'est toi qui est ridicule...

n°1740761
skeye
Posté le 03-06-2008 à 12:09:21  profilanswer
 

tournevissette a écrit :

Quelle arrogance, là c'est toi qui est ridicule...


Il serait peut-être bon pour toi de te renseigner un tout petit peu sur les gens à qui tu parles quand tu débarques sur un forum.
Peu de gens ici peuvent l'ouvrir question C++ pour contredire Joel, alors essaye éventuellement d'envisager qu'il sait de quoi il parle et qu'il y a un fond derrière la forme pas forcément académique de sa critique...


---------------
Can't buy what I want because it's free -
n°1740779
bjone
Insert booze to continue
Posté le 03-06-2008 à 12:43:30  profilanswer
 

tournevissette a écrit :

Quelle arrogance, là c'est toi qui est ridicule...


 
il critique la qualité de son implémentation, sa maintenabilité.
 
je suis d'accord que c'est un point important, car par expérience une bibliothèque mal écrite c'est une bilbliothèque qui n'a pas d'avenir, et donc que c'est déconseillable de lier un projet avec une telle bibliothèque.
 
maintenant ça dépends si c'est pour un projet a l'arrache pour quelque chose de plus pro.


Message édité par bjone le 03-06-2008 à 12:43:43
n°1740827
tourneviss​ette
Posté le 03-06-2008 à 14:09:49  profilanswer
 

Juste pour finir, CImg ca existe depuis fin 1999 apparemment, donc pour un projet qui n'a pas d'avenir, je trouve que ca dure quand même depuis un bout de temps.
J'imagine que depuis le temps ils se seraient aperçus que quelque chose coinçait dans la structure.
 
Joel est peut-être très fort en C++, mais je vois pas pourquoi il serait une référence, ca reste à prouver. Il peut avoir son avis, mais il pourrait être humble aussi ça lui ferait pas de mal. L'arrogance ça cache souvent de l'incompétence.
A aucun moment, il n'a proposé de solutions sur ce post ("boost::gil" n'est pas ce qu'on peut appeller une description de solution..)
 
Moi j'ai écris pour essayer de résoudre le problème du posteur initial le plus facilement possible, c'est peut-être pas la meilleure solution aux yeux de certains, mais au moins çà marche, et c'est facile à mettre en oeuvre.
 
Sur ce, je vous laisse vous vanner entre vous, je vais essayer d'aider d'autres personnes..

n°1740862
Joel F
Real men use unique_ptr
Posté le 03-06-2008 à 14:43:45  profilanswer
 

tournevissette a écrit :

Juste pour finir, CImg ca existe depuis fin 1999 apparemment, donc pour un projet qui n'a pas d'avenir, je trouve que ca dure quand même depuis un bout de temps.
J'imagine que depuis le temps ils se seraient aperçus que quelque chose coinçait dans la structure.


 
Tu liras les commentaires sur le forum sourceforge associé à CIMg et tu verras que le problème de la structure de la lib revient périodiquement mais que l'auteur s'en débarrasser d'une pirouette.
Quant à ma solution, si les gens savent pas non plus faire un google ou n'ont jamais entendu parler de boost, je peut rien pour eux [:pingouino]

n°1740878
tourneviss​ette
Posté le 03-06-2008 à 15:22:38  profilanswer
 

Un lien pour étayer tes propos ?

n°1740901
Joel F
Real men use unique_ptr
Posté le 03-06-2008 à 15:45:13  profilanswer
 

En vrac :
http://sourceforge.net/forum/forum [...] _id=421080
http://sourceforge.net/forum/forum [...] _id=421080
 
Ensuite, son fabuleux FAQ 2.3 que j'aime à déboulonner les soirs ou il fait froid.
 

Citation :


    * First, the library is based on template datatypes (images with generic pixel type), meaning that the programmer is free to decide what type of image he instanciates in his code. Even if there are roughly a limited number of fully supported types (basically, the "atomic" types of C++ : unsigned char, int, float, ...), this is not imaginable to pre-compile the library classes and functions for all possible atomic datatypes, since many functions and methods can have two or three arguments having different template parameters. This really means a huge number of possible combinations. The size of the object binary file generated to cover all possible cases would be just colossal. Is the STL library a pre-compiled one ? No, CImg neither. CImg is not using a classical .cpp and .h mechanism, just like the STL. Architectures of C++ template-based libraries are somewhat special in this sense. This is a proven technical fact.


Non sens pur et simple. Les compilateurs n'ont pas besoin de "precompilés" quoique se soit, la génération du code template est faite on demand.  
 

Citation :


    * Second, why CImg does not have several header files, just like the STL does (one for each class for instance) ? This would be possible of course. There are only 4 classes in CImg, the two most important being CImg<T> and CImgList<T> representing respectively an image and a collection of images. But contrary to the STL library, these two CImg classes are strongly inter-dependent. All CImg algorithms are actually not defined as separate functions acting on containers (as the STL does with his header <algorithm> ), but are directly methods of the image and image collection classes. This inter-dependence practically means that you will undoubtly need these two main classes at the same time if you are using CImg. If they were defined in separate header files, you would be forced to include both of them. What is the gain then ? No gain.


Breaking NEWS from 1998 : on peut inclure des .h dans des .h :o
Ensuite, une lecture de http://www.gotw.ca/gotw/084.htm s'avère nécessaire. L'inter-dépendance ne signifie pas écrire du spaghetti moche.  
Et parler de gain parce qu'il faut pas inclure un .H , je reponds en 3 lettres : L,O,L
 

Citation :


      Concerning the two other classes : You can disable the third most important class CImgDisplay of the CImg library, by setting the compilation macro cimg_display_type to 0, avoiding thus to compile this class if you don't use display capabilities of CImg in your code. But to be honest, this is a quite small class and doing this doesn't save much compilation time. The last and fourth class is CImgException, which is only few lines long and is obviously required in almost all methods of CImg. Including this one is mandatory.


Breakign news from 1550 :
avoir eu 4 .h séparés aevc des forward et un CIMg.h qui aurait juste fait :
 

Code :
  1. #include <fichier1.h>
  2. #include <fichier2.h>
  3. #include <fichier3.h>
  4. #include <fichier4.h>


 
aurait donner le même résultat sans faire planter mon emacs, faire ramer eclipse pendant 50 ans ou peter le word wrap de Ultraedit et de VC6 :E
 

Citation :


    * Third, having a single header file has plenty of advantages : Simplicity for the user, and for the developers (maintenance is in fact easier). Look at the CImg.h file, it looks like a mess at a first glance, but it is in fact very well organized and structured. Finding pieces of code in CImg functions or methods is particularly easy and fast. Also, how about the fact that library installation problems just disappear ? Just bring CImg.h with you, put it in your source directory, and the library is ready to go !


Pour arreter d'etre negatif, je suis d'accord avec le passage en gras :o
 
Enfin bref, utiltié de CIMg : très grande, choix du design : a chier et fait de la discu :o

n°1740944
tourneviss​ette
Posté le 03-06-2008 à 17:00:40  profilanswer
 

Citation :


Ensuite, son fabuleux FAQ 2.3 que j'aime à déboulonner les soirs ou il fait froid.
...
Non sens pur et simple. Les compilateurs n'ont pas besoin de "precompilés" quoique se soit, la génération du code template est faite on demand.  


 
Je sais pas si tu te rends compte, mais c'est exactement ce qu'il dit : la génération du code template est faite on-demand, donc pas besoin de générer des .o (ou .lib, .so, .a, i.e. avoir une lib pré-compilée). La structure en .h est donc une bonne solution. Tu as peut-être mal lu  :whistle:  mais j'ai l'impression que tu es d'accord avec lui (si tu utilises la STL et que tu conseille GIL, ca semble cohérent avec cette idée).
Comme dit dans ton premier lien de forum, ca a en plus l'avantage de donner des executables assez petits puisque seules les fonctions utilisées dans ton programme sont effectivement compilées.
 

Citation :


Breaking NEWS from 1998 : on peut inclure des .h dans des .h :o
Ensuite, une lecture de http://www.gotw.ca/gotw/084.htm s'avère nécessaire. L'inter-dépendance ne signifie pas écrire du spaghetti moche.  
Et parler de gain parce qu'il faut pas inclure un .H , je reponds en 3 lettres : L,O,L


 
Nuance, il ne dit pas qu'il y a du gain à avoir un seul .h, il dit qu'il n'y a pas de gain d'en avoir plusieurs.
Il a raison, la vitesse de compilation n'est pas affectée par le fait d'avoir un seul .h plutôt que plusieurs.
Invoquer la vitesse de compilation comme frein à avoir un seul .h est un non-sens (comme fait dans ton deuxième lien du forum).
 

Citation :


Breakign news from 1550 :
avoir eu 4 .h séparés aevc des forward et un CIMg.h qui aurait juste fait :
 

Code :
  1. #include <fichier1.h>
  2. #include <fichier2.h>
  3. #include <fichier3.h>
  4. #include <fichier4.h>


 
aurait donner le même résultat sans faire planter mon emacs, faire ramer eclipse pendant 50 ans ou peter le word wrap de Ultraedit et de VC6 :E


 
Ca sert à quoi d'avoir 4 fichiers .h si au final il faut les inclure tout le temps ? J'utilise un peu CImg, et je confirme : on a tout le temps besoin de toutes les classes en même temps. Maintenant, si la raison de ta séparation en différents .h, c'est juste parce que emacs ou eclipse rament ou ne savent pas ouvrir un gros fichier texte, je rigole et je conseille de changer d'éditeur de texte.  :jap:  
En passant, je ne vois pas l'intérêt d'ouvrir un tel fichier quand on ne comptes pas le modifier (ce qui est le cas, est-ce que tu modifies les headers de la STL quand tu les utilises toi ?  :lol: )
 
Bref, je vois pas trop ce que tu as démonté ici, et tu ne m'as pas vraiment convaincu.  
Cela dit, n'hésite pas si tu as d'autres arguments, ca m'intéresse. J'ai fait un peu le tour des autres bibliothèques de traitement d'images ou Vision par ordinateur (vigra, gil, opencv, ...), et j'ai jamais trouvé quelque chose de plus agréable à utiliser que CImg. Il me génère des binaires très compacts et il se transporte facilement (pratique pour donner des TD à l'IUT par exemple), en plus d'être multi-plateforme.
Voilà pourquoi je le défend et je le conseille.


---------------
-- Tournevissette --
n°1740960
Joel F
Real men use unique_ptr
Posté le 03-06-2008 à 17:21:46  profilanswer
 

Je ferais une reponse avec de l'entrequote plus tard, je suis un peu occupé là.
Mais encore une fois, les features de CIMg sont très bons ... je critique juste sa forme. Ca fait très 1880 c'est tout.

 
tournevissette a écrit :

[quote]
Ca sert à quoi d'avoir 4 fichiers .h si au final il faut les inclure tout le temps ?

 

Genre à simplifier la maintenance ...

 

J'avais pas vu non plus, il y a des wrapper LAPACK (incorrects en plus) dedans :[ C'est plus CIMg là , c'ets CLibrary :€


Message édité par Joel F le 03-06-2008 à 17:25:11
n°1740971
tourneviss​ette
Posté le 03-06-2008 à 17:31:59  profilanswer
 

Citation :


Genre à simplifier la maintenance ...


 
Ca tombe bien c'est pas toi qui t'occupes de la maintenance   :D .
J'imagine que les gars qui s'en occupent trouvent ça bien maintenables sinon ils auraient changé çà depuis longtemps tu crois pas ?
(ca me parait pas bien compliqué de splitter un gros fichier en 4 plus petits.. :sarcastic: ).

n°1741014
tpierron
Posté le 03-06-2008 à 20:16:51  profilanswer
 

tournevissette a écrit :

Ca tombe bien c'est pas toi qui t'occupes de la maintenance


 
De la lib non, mais du programme qui va l'utiliser oui. Le moins qu'on puisse dire c'est que ce n'est vraiment pas une approche conventionnelle qu'il a utilisé. Alors c'est sûr pour un hello world qui tiens en dix lignes, développé par une personne, qui utilise 0.001% des capacités de cette "lib", ça te ponds un exe de 0.7Ko, cross plateforme et refactoré en 15 nano secondes.
 
Maintenant, dans la vraie vie avec des applis de plusieurs dizaines de milliers de lignes de code, c'est plus vraiment la même histoire. Genre :
* Portabilité : croire qu'une application d'une telle taille est portable parce qu'elle n'utilise que des libs et du code portable, sans avoir fait le moindre test, relève au mieux de la naïveté, au pire du mensonge.
* Utilisation : l'approche de CImg t'oblige à faire des wrappers pour instancier explicitement les classes et éviter de dupliquer ton code aux quatres coins de l'application, et accessoirement pour éviter de faire exploser la taille de l'exe. Comme le font quasiment toutes les autres libs...
* C'est vraiment pas conventionnelle comme approche. Je sais bien que c'est souvent un voeux pieux, mais je préfère avoir une certaine marge pour "porter" vers d'autre APIs, au cas où la lib s'avère inadaptée. Là ça ressemble à rien de ce que j'ai pu voir ailleur, proprio ou open source (gdi, gdi+, cairo, et une tétrachié de lib proprio).
* Quid si tu veux améliorer ce truc, c'est sûr que pour du niveau Hello World, ça doit tout prendre en charge. Mais prétendre tout couvrir dans un domaine aussi vaste que le traitement d'image, c'est ridicule. Alors un peu de modestie, et toujours convecoir un outil avec l'idée en tête que quelqu'un d'autre va faire mieux (si possible en ne repartant pas de zéro).
* Genre la gestion de la mémoire. C'est sûr pour des images 800x600, ça doit défourailler à mort cette lib. Mais si on refait le test avec des images de 200000x150000px ? Comment améliorer / optimiser un tel pavé ?
 
Dommage, ses algos de traitement d'images sont pas mal. Les capacités 3D sont intéressantes. Mais à avoir faire tout et n'importe quoi, on obtient souvent n'importe quoi plutôt que tout. Au lieu d'être bon dans un domaine, on est moyen dans plusieurs. En tous les cas quand je vois le code, je n'ai qu'une envie : fuir.
 
 

n°1741073
tourneviss​ette
Posté le 03-06-2008 à 23:12:48  profilanswer
 

Citation :


De la lib non, mais du programme qui va l'utiliser oui. Le moins qu'on puisse dire c'est que ce n'est vraiment pas une approche conventionnelle qu'il a utilisé. Alors c'est sûr pour un hello world qui tiens en dix lignes, développé par une personne, qui utilise 0.001% des capacités de cette "lib", ça te ponds un exe de 0.7Ko, cross plateforme et refactoré en 15 nano secondes.


 
Mais justement, c'est pas spécialement fait pour utiliser toutes les capacités de la lib cette approche. C'est comme quand tu utilises la STL. Franchement, qui peut prétendre utiliser toutes les fonctionnalités de la STL dans un programme C++ ? personne ! Les gens prennent ce qui leur est utile (99% du temps les vector<>...) et personne ne se plaint que la STL c'est énorme et qu'on utilise pas tout. C'est bien çà l'intérêt de ce genre de bibliothèques templates, ca ne compile que ce qu'on utilise vraiment, c'est çà que j'aime bien moi ! C'est pour ça que c'est léger au final.
 

Citation :


* Portabilité : croire qu'une application d'une telle taille est portable parce qu'elle n'utilise que des libs et du code portable, sans avoir fait le moindre test, relève au mieux de la naïveté, au pire du mensonge.


Qui te dit qu'il n'a pas testé ? Les quelques exemples compilés proposés sur le site fonctionnent au moins sous MacOSX, Linux et Windows, et avec des compilos différents comme g++, icc et visualcpp. En plus d'après mon expérience, tu peux compiler en ayant aucune dépendance autre que la libc. Donc à priori c'est bel et bien portable (même si je l'admet je n'ai jamais eu trop besoin de m'en servir).
 

Citation :


* Utilisation : l'approche de CImg t'oblige à faire des wrappers pour instancier explicitement les classes et éviter de dupliquer ton code aux quatres coins de l'application, et accessoirement pour éviter de faire exploser la taille de l'exe. Comme le font quasiment toutes les autres libs...


Jamais eu ce problème. J'ai un gros doute sur ton affirmation. Certains exemples fournis avec la lib sont relativement complexes (voir la demo principale) et la taille des exes correspondants reste très faible.  
 

Citation :


* C'est vraiment pas conventionnelle comme approche. Je sais bien que c'est souvent un voeux pieux, mais je préfère avoir une certaine marge pour "porter" vers d'autre APIs, au cas où la lib s'avère inadaptée. Là ça ressemble à rien de ce que j'ai pu voir ailleur, proprio ou open source (gdi, gdi+, cairo, et une tétrachié de lib proprio).


C'est pas conventionnel donc c'est forcément à chier ? hum... Moi je pense que heureusement qu'il y en a qui osent ce genre de truc, surtout si ca permet de s'apercevoir que ça marche avec des projets qui ne sont pas des cas d'écoles. Si ça peut ouvrir l'esprit de certains c'est pas plus mal.
 

Citation :


* Quid si tu veux améliorer ce truc, c'est sûr que pour du niveau Hello World, ça doit tout prendre en charge. Mais prétendre tout couvrir dans un domaine aussi vaste que le traitement d'image, c'est ridicule. Alors un peu de modestie, et toujours convecoir un outil avec l'idée en tête que quelqu'un d'autre va faire mieux (si possible en ne repartant pas de zéro).


Personne n'a affirmé à ma connaissance que c'était censé couvrir tout le traitement d'images. Tu utilises ce que tu veux, et si tu n'as pas ce que tu cherches, rien n'empêche d'utiliser CImg en complément avec d'autres libs (perso j'utilise aussi openCV en complément pour certaines fonctionnalités). Les structures d'images sont assez proches pour faire des passerelles très facilement et utiliser l'une ou l'autre des fonctionnalités des deux libs. *Aucune* bibliothèque de traitement d'image au monde actuellement ne couvre de toute façon tous les besoins, et à mon avis c'est pas pour demain (et si tu en connais une, n'hésite pas, j'ai déjà pas mal cherché).
 

Citation :


* Genre la gestion de la mémoire. C'est sûr pour des images 800x600, ça doit défourailler à mort cette lib. Mais si on refait le test avec des images de 200000x150000px ? Comment améliorer / optimiser un tel pavé ?


La encore, c'est une fonctionnalité spéciale et effectivement je ne pense pas que CImg soit spécialement adapté pour les images de très grandes tailles. Mais donne moi une biliothèque qui le gère bien (genre VIPS?) , et bien je peux te trouver surement une fonctionnalité qu'elle n'aura pas et qui sera dans CImg et dont j'aurais besoin. Ton raisonnement est valide mais malheureusement s'applique à toutes les libs de la terre en TI. Y a jamais rien de complet en ce bas-monde ma bonne dame.  :sweat:  
 

Citation :


Dommage, ses algos de traitement d'images sont pas mal. Les capacités 3D sont intéressantes. Mais à avoir faire tout et n'importe quoi, on obtient souvent n'importe quoi plutôt que tout. Au lieu d'être bon dans un domaine, on est moyen dans plusieurs. En tous les cas quand je vois le code, je n'ai qu'une envie : fuir.


Jamais utilisé les capacités 3D, perso je préfère OpenGL qui me semble comme tu dis bien plus complet (et en plus je connais déjà). Mais comme je l'ai dit plus haut, jamais utilisé ca veut dire aussi que les fonctions correspondantes sont jamais compilées et au final ne viennent pas polluer mon exe avec du code inutile. Moi ce genre de lib "à la carte" je trouve çà top (exactement comme la STL d'ailleurs).
Je vois plus çà comme une boite à outil ou tu pioches juste les fonctionnalités qui t'intéressent (et qui sont compilées on-demand), sans avoir à linker avec un pavé de bibliothèques qui contiennent 100 fois plus de code que tu ne l'utilises. En ce sens, je trouve ces approches templates bien plus légères que les approches "conventionnelles" (c'est un des gros intérêt du C++ à mon avis).

n°1741086
bjone
Insert booze to continue
Posté le 04-06-2008 à 00:12:53  profilanswer
 

tournevissette a écrit :

Citation :


De la lib non, mais du programme qui va l'utiliser oui. Le moins qu'on puisse dire c'est que ce n'est vraiment pas une approche conventionnelle qu'il a utilisé. Alors c'est sûr pour un hello world qui tiens en dix lignes, développé par une personne, qui utilise 0.001% des capacités de cette "lib", ça te ponds un exe de 0.7Ko, cross plateforme et refactoré en 15 nano secondes.


 
Mais justement, c'est pas spécialement fait pour utiliser toutes les capacités de la lib cette approche. C'est comme quand tu utilises la STL. Franchement, qui peut prétendre utiliser toutes les fonctionnalités de la STL dans un programme C++ ? personne ! Les gens prennent ce qui leur est utile (99% du temps les vector<>...) et personne ne se plaint que la STL c'est énorme et qu'on utilise pas tout. C'est bien çà l'intérêt de ce genre de bibliothèques templates, ca ne compile que ce qu'on utilise vraiment, c'est çà que j'aime bien moi ! C'est pour ça que c'est léger au final.
 

Tout à fait et dans la STL lorsque tu utilise uniquement le vector<> tu fais un include<vector> et tu as -juste- le code nécessaire au vector d'inclus. Pas un header de 1.54 Mo.
 
La STL c'est assez important en terme de proposition, tout comme boost, mais tu inclus uniquement ce que tu as besoin.
Dans ce cas c'est léger pour tout le monde.  
Toi, le compilo, le mec qui va suivre ton boulot 10 ans plus tard.
 
Une architecture dont les concepts sont assez clairement explicites et proprement formalisés et dont l'implémentation est décomposée logiquement comme le sont la STL & Boost, sont une invitation au voyage:
tu as envie d'étendre ces bibliothèques, d'épouser leur philosophie.
 
Dans le CImg.h, tu le parcours, après 8Km de #define, on sait pas où sont les conteneurs on sait pas où sont les algorithmes. C'est tellement mal partitionné, que ça ne donne pas envie de venir rajouter son expertise. (Je parle pas spécialement pour moi)
 
Boost attire du monde parce que c'est propre, tout le monde s'en sert et en retour tout le monde essaye de proposer des choses.
C'est du vrai open-source, avec un travail collaboratif inter-spécialité.
 
Les ingés d'Adobe l'utilisant en interne, ont fini par épouser la philosophie et de proposer leur expertise dans le traitement de l'image.
 
Un truc comme CImg j'aimerai bien par exemple connaitre le nombre de contributions externes de communautés open-source et propriétaire.
 
CImg il est comme il est il ne changera plus. no future
 

Citation :


* Genre la gestion de la mémoire. C'est sûr pour des images 800x600, ça doit défourailler à mort cette lib. Mais si on refait le test avec des images de 200000x150000px ? Comment améliorer / optimiser un tel pavé ?


La encore, c'est une fonctionnalité spéciale et effectivement je ne pense pas que CImg soit spécialement adapté pour les images de très grandes tailles. Mais donne moi une biliothèque qui le gère bien (genre VIPS?) , et bien je peux te trouver surement une fonctionnalité qu'elle n'aura pas et qui sera dans CImg et dont j'aurais besoin. Ton raisonnement est valide mais malheureusement s'applique à toutes les libs de la terre en TI. Y a jamais rien de complet en ce bas-monde ma bonne dame.  :sweat:  
 
boost::gil doit pouvoir, mais je sais plus :D
 

Citation :


Dommage, ses algos de traitement d'images sont pas mal. Les capacités 3D sont intéressantes. Mais à avoir faire tout et n'importe quoi, on obtient souvent n'importe quoi plutôt que tout. Au lieu d'être bon dans un domaine, on est moyen dans plusieurs. En tous les cas quand je vois le code, je n'ai qu'une envie : fuir.


Jamais utilisé les capacités 3D, perso je préfère OpenGL qui me semble comme tu dis bien plus complet (et en plus je connais déjà). Mais comme je l'ai dit plus haut, jamais utilisé ca veut dire aussi que les fonctions correspondantes sont jamais compilées et au final ne viennent pas polluer mon exe avec du code inutile. Moi ce genre de lib "à la carte" je trouve çà top (exactement comme la STL d'ailleurs).
Je vois plus çà comme une boite à outil ou tu pioches juste les fonctionnalités qui t'intéressent (et qui sont compilées on-demand), sans avoir à linker avec un pavé de bibliothèques qui contiennent 100 fois plus de code que tu ne l'utilises. En ce sens, je trouve ces approches templates bien plus légères que les approches "conventionnelles" (c'est un des gros intérêt du C++ à mon avis).
 
Le code est ptet compilé à la demande, mais le header est parsé pour tout et n'importe quoi. Heureusement que les Core 2 Duo Penryn ont 3Mo de cache L2 par core, ça doit roxer à la compilation d'un fichier objet incluant CImg.h.
 


Message édité par bjone le 04-06-2008 à 00:14:56
n°1741123
tourneviss​ette
Posté le 04-06-2008 à 07:42:18  profilanswer
 

Citation :


Tout à fait et dans la STL lorsque tu utilise uniquement le vector<> tu fais un include<vector> et tu as -juste- le code nécessaire au vector d'inclus. Pas un header de 1.54 Mo.  


Tu serais surement surpris de voir le nombre de lignes de codes qui sont parsées par le compilo et qui correspondent à des fonctionnalités de la STL que tu n'utilises pas à mon avis... :whistle:  
 

Citation :


CImg il est comme il est il ne changera plus. no future  


 
Mouais, çà fait juste 9 ans que ca existe. Depuis 2 ans que je m'y intéresse, il y a en moyenne une release tous les 4 mois (et ce n'est pas que des corrections de bugs). Je suis clairement pas sûr du côté non-évolutif de ce projet. Va voir les stats du projet avant de dire que ce n'est pas évolutif ou actif.
 :non:  
 

Citation :


Le code est ptet compilé à la demande, mais le header est parsé pour tout et n'importe quoi. Heureusement que les Core 2 Duo Penryn ont 3Mo de cache L2 par core, ça doit roxer à la compilation d'un fichier objet incluant CImg.h.
 


Haa c'est la meilleure celle là, maintenant c'est au programmeur d'aider le compilo ! Moi je croyais que c'était le contraire à la base... Si il faut pas faire trop chauffer les machines, à ce moment là, autant faire de l'assembleur directement, il n'y a pas de phase de compilation..
Grosse idée reçue, j'ai compilé du code basé CImg sur un portable 1Ghz de proc, avec 512 Mo de Ram, ca n'a pas pris plus de temps que quand j'utilise la STL toute seule par ailleurs. Faut croire que le compilo sait faire son travail de parsing correctement..
 
Bon sur ce, on a carrément dévié du sujet initial, je n'interviens plus. J'ai donné quelques arguments pour CImg, et vous contre, aux gens de se faire leur avis (ceux qui lisent encore).
Je vous laisse, j'ai des slides de cours à préparer  :lol:  

n°1741217
IrmatDen
Posté le 04-06-2008 à 11:10:06  profilanswer
 

(J'espère que c'est pas des cours d'archi :sweat:)

n°1741295
bjone
Insert booze to continue
Posté le 04-06-2008 à 12:24:26  profilanswer
 

C'est cool tu va pouvoir leur faire une démo de refactorisation de code.

n°1741334
tourneviss​ette
Posté le 04-06-2008 à 13:35:53  profilanswer
 

Bah venez, ça vous ferait pas de mal apparemment :D

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  Comment lire une image d'un fichier en C++

 

Sujets relatifs
Problème erreur ifafficher des image stocker dans bdd mysql
C# datagridviewcomboboxcolumnproblème pour valider un fichier xml avec un xsd composé
Liaison avec un autre fichiertuto C++
creation et ecriture dans un fichier en C[C#] Appeller plusieurs méthodes asynchrones ?
PB socket C et fcntl() 
Plus de sujets relatifs à : Comment lire une image d'un fichier en C++


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR