Bonjour à tous,
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.

boost::gil

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

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.

 
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

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)

[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.

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 ?

[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.

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

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.

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

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 :
 

 
et hop ! ton image est chargée !
 

 
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...

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

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.

 
La bonne blaque !  
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..
 

 
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.

 
j'ai dit 1 .h pas des .h  
et je passe sur le fait de m'apprendre comment marche les templates
 
CImg est une atrocité en bien des points ...

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.

 
  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.

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...

 
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.

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..

 
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

Un lien pour étayer tes propos ?

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.
 

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.  
 

Breaking NEWS from 1998 : on peut inclure des .h dans des .h
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
 

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

 
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
 

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

 
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    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.
 

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

 
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.    
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 ?   )
 
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.

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.

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

 
Ca tombe bien c'est pas toi qui t'occupes de la maintenance   .
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.. ).

 
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.
 
 

 
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.
 

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

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.  
 

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.
 

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é).
 

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.    
 

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

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...  
 

 
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.
   
 

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    

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

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

Bah venez, ça vous ferait pas de mal apparemment