J'ai longuement hésité avant de posté ceci comme journal ... Je m'excuse si vous trouvez qu'il n'est pas approprié ...
Suite à ce journal (http://linuxfr.org/~ElVirolo/14220.html(...)) où je vous demandais conseil sur le choix d'un langage de programmation pour la manipulation d'images. Grâce à vos (nombreuses) réponses éclairées, je me suis (re)plongé dans le Python pendant quelque temps ... pour ensuite décider que ce langage ne répond pas vraiment à mes attentes (pour ce projet-ci, attention)...
C'est alors par hasard que je suis tombé sur FreePascal [1], un formidable EDI libre pour Pascal en mode texte. J'ai été fort surpris lorsque je me suis aperçu que tous mes anciens programmes composés pour Turbo Pascal 7.0 sous DOS se recompilaient sans problème sous FreePascal!
J'ai poursuivi mes recherches, et je suis tombé sur encore mieux : Lazarus [2], un EDI cette fois graphique (et tout aussi libre) pour FreePascal... C'est un outil on ne peut plus impressionnant, semblable à Kylix/Delphi mais distribué sous licence GPL ...
C'est à partir de ce moment que je me suis replongé avec grand plaisir dans le Pascal, dont j'ai retrouvé la puissance, l'élégance et la simplicité ... Bien que je ne possède que des bases dans ce langage, la découverte d'un compilateur libre aussi performant que FreePascal me donne envie d'aller plus loin...
Il faut de plus noter que FreePascal s'intègre parfaitement à Kdevelop, ce qui est un vrai bonheur.
Il me faut maintenant revenir à mon projet : pensez-vous que Pascal soit adapté à la manipulation d'images (mes besoins sont toutefois assez sommaires dans ce domaine, simplement trifouiller les valeurs RGB des pixels), ce qui m'arrangerait bien ?
J'ai vu que libpng venait avec FreePascal... Pourquoi ne pas l'utiliser ? Il est vrai que cela limite l'utilisation du programme (seulement avec des images PNG) mais puisque c'est un format libre...
J'ai essayé un
Uses libpng; mais on me répond que l'unité libpng est introuvable (pourtant elle est bien là!).Merci d'avance pour votre aide,
Alex.
[1]http://www.freepascal.org/(...)
[2]http://www.lazarus.freepascal.org/(...)
# Même en m'étant relu trois fois ...
Posté par ElVirolo (site web personnel) . Évalué à 2.
s/posté/poster
# curiosité
Posté par manatlan (site web personnel) . Évalué à 2.
c'est pas pour troller, c'est juste de la curiosité
car je ne vois pas où ça pourrait pêcher en python ...
[^] # Re: curiosité
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: curiosité
Posté par ElVirolo (site web personnel) . Évalué à 1.
Alex.
[^] # Re: curiosité
Posté par manatlan (site web personnel) . Évalué à 2.
en python, il y a 3 objets de bases qui peuvent un peu s'apparenter aux tableaux ... je vais faire simple
- les lists : ["a","b","c"]
c'est une liste ! on peut ajouter des elements, en enlever
et les index: t[0] == "a"
- les tuples : ("a","b","c")
c'est comme une liste, mais c'est fermé ! on peu ni rajouter, ni
enlever ... on les index pareils t[0] = "a"
- les dicos : { 1:"a", 2:"b", 3:"c", 7:"d"}
c'est un hashtable(key/value) ! on peut ajouter/enlever des elements
et on index aussi t[0] == "a"
les tuples sont moins utilisés, mais pratique par exemple pour stocker un coordonné x,y ... a = (10,20) ... ou pour un retour de fonction de plusieurs éléments ... (comme ces des objets où on est pas censé ajouter/enlever des éléments)
python devrait largement couvrir tous tes besoins ... si PIL te convient pas, il y a des bindings sur d'autres libs (imagemagick et autres) mais PIL est très très bien ... et très puissante
[^] # Re: curiosité
Posté par manatlan (site web personnel) . Évalué à 2.
troll ?
tu serai surpris de la vitesse de python ... rien à envier à java ou dot.net
dans certains cas, le binaire issu de C est plus rapide ... mais on s'y rapproche de plus en plus ... (ils bossent beaucoup sur l'optimisation)
si problème de vitesse il y avait vraiment ... ce ne serait qu'une question de temps ... ;-)
on attends toujours le compilateur starkiller de py -> binaire, ou le pypy : réimplémentation de python en python ...
d'ici "peu de temps" ; ce "viel argument" infondé sera définitivement révolu ;-)
regarde les progrès du parser cElementTree de python, ces derniers jours, il dépasse haut la main msxml, libxml2(déjà très rapide) ou les parsers java ... en vitesse et en ressources ... tout en étant pythonique (en profitant de toutes les merveilleuses facultés du langage python)
[^] # Re: curiosité
Posté par TImaniac (site web personnel) . Évalué à 1.
CQFD.
[^] # Re: curiosité
Posté par manatlan (site web personnel) . Évalué à 2.
Dans la classe des langages avec bytecode/VM, python n'a rien à envier à java ou dot.net en terme de rapidité ... tout en étant plus que portable (python est la langage (de haut niveau) qui possède le plus de plateformes, j'ai une liste qqpart) ...
Bref, je ne comprends pas ce que tu veux dire, et vu ton cv ... tu devrais un peu taquiner le python ;-)
[^] # Re: curiosité
Posté par TImaniac (site web personnel) . Évalué à 2.
Et c'est justement parcque sans Psyco (qui ne marche que sur x86) Python n'est pas du tout comparable avec .NET ou Java que je ne comprend pas du tout comme tu peux affirmer qu'il n'a rien à envier en terme de rapidité... En l'état actuel où Java et .NET utilisent un JIT, Python est plus lent (sans Psycho puisque Psycho n'est pas portable et dénature donc le langage)
Bon évidemment on pourrait parler de IronPython ;-)
# bibliotheque
Posté par Erwan . Évalué à 3.
* En Python, tu as PIL:
http://www.pythonware.com/products/pil/(...)
* Autrement ImageMagick qui a des bindings vers plein de langages, incluant Ruby:
http://www.imagemagick.org/(...)
* Java a sa propre API de traitement d'images
http://java.sun.com/products/java-media/jai/(...)
* etc...
Bref, il y en a pour tous les gouts, il suffit de trouver la bonne bibliotheque. Maintenant si ces bibliotheques ne te suffisent pas, que tu veux implementer tes propres algos (mais visiblement ce n'est pas ton cas) alors il vaut mieux passer par un langage permettant d'atteindre un niveau plus bas, comme le C ou le C++.
Par contre, en attaquant directement la libpng, tu risques de te compliquer la vie pour rien.
Enfin bon, tout ca a deja ete plus ou moins dit a ton journal precedent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.