Optimisation traitement d'images

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Optimisation traitement d'images

thekraken

Bonjour,

c'est mon premier post et aussi mon premier script python !
travaillant sur maya+renderman sur windows et os X, il me fallait un solution multi-plateforme pour créer des scripts de traitement d'image.

j'ai donc fait un script python qui prend plusieurs images (couleur, normals, depths, id objets), qui effectue des calculs avec pour faire ressortir les contours, puis assemble une image final avec l'outline (associé à un cell shading, on a un rendu cartoon donc).

ceci simule la fonction contour shader de mentalray pour les connaisseurs, mais peut importe le probleme n'est pas la.

le probleme c'est que le script est super super lent (genre 5 minutes pour une image en 1240x1024), et il me faut vraiment un truc plus rapide (genre quelques secondes).

la problématique se situe au niveau de la boucle qui traite l'image pixel par pixel..

je n'y connais rien en python a part ce qu'il y a dans le script, alors je sais pas trop quelle approche utiliser pour que ca boost vraiment, merci de me donner des conseils peut etre sur la manipulation des sequences, etc.. j'ai pas tout capter, ou mieux si vous avez ZE solution

voici mon script :

Code :

#parameters
ndiff = 0.10 / 100.
zdiff = 5. / 100.
sampling = 3 #MUST be the same than renderman global's sampling size
line_width = 4
if (len(sys.argv) > 1) :
file = sys.argv[1]
elif (len(sys.argv) > 2) :
file = sys.argv[2]
else :
file = "C:/download/3D/Render_toonz/renderman/toon/rmanpix/untitled.0001.tga"
#contour processing on tga files. kraken@machinemolle.com
import Image
import ImageFilter
import ImageEnhance
import ImageOps
import ImageTk
import ImageChops
import commands
import os
import sys
import math
import array
def seq_set_brush(pixels, x, y, width, height, size) :
#TODO : find correct side value (diff)
len = round(size / 2)
diff = (float((size + 1) % 2) / 2.)
for dx in range(- len, len) :
for dy in range (- len, len) :
fx = x + dx
fy = y + dy
if fx >= 0 and fy >= 0 and fx < width and fy < height :
if abs(dx) < len or diff == 0 :
seq_set_pixel(pixels, fx, fy, width, height, 255)
else :
seq_set_pixel(pixels, fx, fy, width, height, 255 * diff)
def seq_set_pixel(pixels, x, y, width, height, value) :
if x >= 0 and y >= 0 and x < width and y < height :
pixels[x + y * width] = value
#pixels[x + y * width * 3 + 1] = value
#pixels[x + y * width * 3 + 2] = value
def seq_get_pixel(pixels, x, y, width, height) :
if x >= 0 and y >= 0 and x < width and y < height :
return pixels[x + y * width]
def dot(v1, v2) :
if (v1 and v2) :
return v1[0] * v2[0] + v1[1] * v2[1] + v1[2] * v2[2]
else :
return 0
def norm(vector) :
if (vector) :
return math.sqrt(vector[0] * vector[0] + vector[1] * vector[1] + vector[2] * vector[2])
def normalize(vector) :
result = [0, 0, 0]
vnorm = norm(vector)
if vnorm != 0 and vector :
result[0] = vector[0] / vnorm
result[1] = vector[1] / vnorm
result[2] = vector[2] / vnorm
return result
base = os.path.basename(file)
fields = base.split("." )
prefix = fields[0]
num = fields[1]
format = fields[2]
suffix = num + "." + format
im = Image.open(prefix + ".normals." + suffix)
imdepths = Image.open(prefix + ".depths." + suffix)
imids = Image.open(prefix + ".ids." + suffix)
mask = im
pixels = mask.getdata()
depths = imdepths.getdata()
depths = depths.convert("L" )
ids = imids.getdata()
ids = ids.convert("L" )
contours = [0] * len(pixels) * 3
#print len(contours)
width = mask.size[0]
height = mask.size[1]
for x in range(0, width):
if (x % 10 == 0) :
print "ALF_PROGRESS " + str(50 + int((float(x*height)/float(width*height))*50)) + "%"
for y in range(0, height):
p1 = seq_get_pixel(pixels, x, y, width, height)
d1 = seq_get_pixel(depths, x, y, width, height)
id1 = seq_get_pixel(ids, x, y, width, height)
if d1 : d1 = d1 / 255.
p1 = normalize(p1)
a = 0
d = 0
for dx in range(-1, 1) :
for dy in range (-1, 1) :
if dx + x >= 0 and dy + y >= 0 and dx + x < width and dy + y < height :
p2 = seq_get_pixel(pixels, x + dx, y + dy, width, height)
d2 = seq_get_pixel(depths, x + dx, y + dy, width, height)
id2 = seq_get_pixel(ids, x + dx, y + dy, width, height)
if (d2) :
d2 = d2 / 255.
d = abs(d2 - d1)
p2 = normalize(p2)
if (norm(p2) == 0 and norm(p1) == 0) :
pa = 1
else :
pa = dot(p1, p2)
if ((p1 and p2) and (pa < (1 - ndiff))) or d > zdiff or (id2 and id1 != id2) :
a = 1 #a = 255
if a : seq_set_brush(contours, x, y, width, height, line_width)
contours_array = array.array('B')
contours_array.fromlist(contours)
mask = Image.frombuffer("L", (width, height), contours_array)
mask = mask.transpose(Image.FLIP_TOP_BOTTOM)
mask.save(prefix + ".contour." + num + ".ppm", "PPM" )
mask = mask.filter(ImageFilter.SMOOTH)
mask = ImageOps.invert(mask)
im1 = mask.convert("RGB" )
im = Image.open(file)
im = im.convert("RGB" )
out = ImageChops.multiply(im, im1)
out = out.resize((im1.size[0] / sampling, im1.size[1] / sampling), Image.ANTIALIAS)
out.save(prefix + ".final." + num + ".tif", "TIFF" )
os.system('cmd.exe /C "%MAYA_PLUG_IN_PATH%/it.exe" ' + prefix + ".final." + num + ".tif" )

Publicité

Joel F

Real men use unique_ptr

PYTHON est pe pas assez performant pour ca tout court ?

HelloWorld

Salut tout le monde!

T'utilises la dernière version de Python ?
Sinon c'est vrai que les scripts c'est pas l'idéal pour du traitement d'images.

---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite

Taz

bisounours-codeur

Joel F a écrit :

PYTHON est pe pas assez performant pour ca tout court ?

toi t'es marrant : un bleu bite de matheux fait son premier programme. 150 lignes de python (on à qu'à dire qu'en C ça ferait sans doute 700 lignes), tout ça en un seul fichier. et bien offuscé en plus, même très bien. tout est bien illisible. on a gus qui fait des matrice dans un tableau ... tout ça est ridicule. python a des super bibliothèques de math (SciPy, Numarray, etc) de très très bonne facture, il suffit qu'un amateur poste un message juste après avoir terminer son application pour la première fois, et hop tu perds tout rationnel ...

Taz

bisounours-codeur

HelloWorld a écrit :

T'utilises la dernière version de Python ?
Sinon c'est vrai que les scripts c'est pas l'idéal pour du traitement d'images.

mon ***, c'est du poulet : je fais de la transparence et de l'antialiasing en temps réel là dedans http://gdesklets.gnomedesktop.org/, je t'assure que ça marche aussi vite que le C, voir plus sur certains points grace à de meilleurs algorithmes.

et si ça vous suffit pas, un coup de JIT avec pysco, et on en parlera plus

thekraken

oui la derniere version !

bon je suis deg
pourtant je fais pas des calculs tres compliqué comme vous pouvez voire, le meme genre de calcul que pour une convolution (filtre par matrice 3x3).

Pour du 640x480, je dois calculer à 3x la résolution, ca fait environ 3Mo de données à traiter, pixel par pixel, sachant que pour chaque pixel j'accede aux pixels autour, ca fait dans les 30 millions d'acces mémoire pour une image (et encore en lecture seulement).

Dois-je donc me rabattre sur du compilé (c.. voire java), pour pouvoir traiter autant d'informations avec une performance correcte ??

Kristoph

thekraken a écrit :

On t'a dit d'utiliser SciPy et numarray ( et peut-être aussi PIL pendant que tu y es )

Taz

bisounours-codeur

et on te dit surtout de profiler ton programme et de passer un coup de psyco par dessus

la seule personne qui ne peut pas traiter autant d'informations avec une performance correcte, c'est toi.

thekraken

Taz : je fais pas de calcul de maths particuliers (que des opération de base..), le probleme c'est le grand nombre d'accès mémoire en python.
j'ai pas séparé mon script car il est tres court, et de toutes façon ca le fera pas aller plus vite, non ?

j'ai essayé de compiler le script optimisé (pyc, pyo..), et psyco aussi mais ça n'est pas plus rapide (meme un poil plus lent des fois).

Kristoph

Au fait, psyco ne sert à rien si tout le code ne se trouve pas dans une fonction. Et jete un coup d'oeil du coté de ScyPy et numarray quand même

Publicité

schnapsmann

Zaford Beeblefect

moi je dis que les accès tableau sont mal faits et font des page fault dans tout les sens. Ca serait aussi lent en C.

Message édité par schnapsmann le 27-09-2004 à 21:16:22

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"

Taz

bisounours-codeur

ouais.

quant à psyco, je crois qu'on est pas sur de l'utilisation que tu en fait ('import psyco' ne suffit pas hein)

et bordel de foin, spa compliqué de profiler tout ça !

et après, y a des trucs bidon dans ton code

range(-1, 1) j'ai jamais vu plus compliqué pour écrire (-1, 0)

thekraken

okok..
j'ai testé numarray, le profiling.. mais vu que j'avais pas mis dans une fonction ca peut pas etre optimisé. je test demain en profilant comme il faut, car pour le moment c toujours pareil.. j'ai bien testé numarray aussi..
effectivtement je peux bidouiller 2/3 trucs dans mon code comme le range mais ca changera pas trop le pb, et schnapsmann meme si peu y avoir des pagefault (code pas finit encore), c pas ca qui changera le pb de la vitesse, nivo algo je peut pas etre bcp plus rapide je pense.. ptet bien qu'en C ca serait lent aussi
je reviens quand ca sera profilé comme il faut !

el muchacho

Comfortably Numb

Non, amha en C, tel que le programme est fait, ça serait quand même probablement bcp plus rapide.

Je connais pas trop Python, mais je pense que ce qu'il faut que tu fasses, c'est :
1. que tu optimises ta fonction normalize. Là, tu calcules bcp (trop) de sqrt à mon goût. Es-tu bien sûr que c'est nécessaire ? Les trois divisions, tu peux les remplacer par 3 multiplications. Ca ne va pas changer grand-chose, mais ça peut aider quand même.
2. des trucs du genre apply(ma fonction, mon tableau) partout où c'est possible, de façon à minimiser les opérations pixel par pixel. Dans ce genre de langage il faut minimiser les boucles imbriquées et utiliser au mieux leurs fonctionnalités natives de façon à bénéficier de la vitesse des opérations compilées en natif, en particulier la traversée d'un tableau. Cela implique de penser l'algo différemment / l'habitude.
3. as-tu utilisé les librairies correctement ? Si tu les as utilisées avec ton script (doubles boucles imbriquées, etc), c'est sûr que ça n'arrange rien. Mais la fonction produit vectoriel, il y a des chances qu'elle soit implémentée plus efficacement dans ce genre de librairie.
Et si y'a vraiment pas moyen de faire autrement que pixel par pixel (je pense notamment à une convolution), ben t'as aussi vite fait d'écrire la routine en C.

Message édité par el muchacho le 28-09-2004 à 07:57:10

Taz

bisounours-codeur

2) pas apply, ça a le surcout d'un appel de fonction, la syntaxe d'appel étendue est bien plus rapide. d'ailleurs c'est pas pas apply, mais map

el muchacho

Comfortably Numb

ok :jap:

Ceci dit c'est vrai qu'en y regardant de plus près, y'a un paquet de trucs à optimiser simplement dans le code, entre les divisions par des constantes, les calaculs de racines carrées à tout va, les boucles for (dx in -1, 1) imbriquées qui peuvent être déroulées, les multiples appels de fonctions qui n'ont guère lieu d'être, il doit y avoir moyen de diviser ses temps d'éxecution par 3.

Message édité par el muchacho le 28-09-2004 à 21:33:55

Joel F

Real men use unique_ptr

Taz a écrit :

c'etait juste une question [:amandine75011] [:joel f]

thekraken

ca y est a devient exploitable, merci pour les infos

j'ai galerré avec les profile, d'abord avec psyco mais je journal n'est pas tres revelateur, alors j'ai utilisé le module profile/stats, et la j'ai vu que c'était surtout l'appel massif aux fonctions qui prenait du temps (mais bien sur d'autres choses aussi n'allaient pas)

j'ai donc presque tout mis dans la meme fonction compute() et en plus j'ai simplifié les calculs a faire (quantisation de 0-255 vers -1,1 pour les normals, plus de normalisation, dot product en expression étendue).

je vous remets le nouveau code, il est pas trop long est plus lisible :

Code :

import math
#from numarray import *
def seq_set_brush(pixels, x, y, width, height, size) :
len = size / 2
diff = ((size + 1.) % 2.) / 2.
for dx in range(- len, len + 1) :
for dy in range (- len, len + 1) :
fx = x + dx
fy = y + dy
if fx >= 0 and fy >= 0 and fx < width and fy < height :
if (abs(dx) < len and abs(dy) < len) or diff == 0 :
pixels[fx + fy * width] = 255
else :
color = int(pixels[fx + fy * width] + (255 * diff))
if color > 255 : color = 255
pixels[fx + fy * width] = color
def compute(width, height, pixels, depths, ids, ndiff, zdiff, line_width) :
#take pixels, depths, ids sequences and output contour numarray
ndiff = 1. - ndiff;
contours = [0] * len(pixels)
#contours = zeros(len(pixels) )
for x in xrange(0, width):
if (x % 100 == 0) :
print "ALF_PROGRESS " + str(50 + int((float(x*height)/float(width*height))*50)) + "%"
for y in xrange(0, height):
p1 = pixels[x + y * width]
d1 = depths[x + y * width]
id1 = ids[x + y * width]
if d1 : d1 = d1 / 255.
computep = 0
for dx in (0, 1) :
for dy in (0, 1) :
if (dx or dy) :
fx = dx + x
fy = dy + y
if fx >= 0 and fy >= 0 and fx < width and fy < height :
p2 = pixels[fx + fy * width]
d2 = depths[fx + fy * width]
id2 = ids[fx + fy * width]
if (d2) :
d2 = d2 / 255.
d = d2 - d1
if d < 0 : d = - d
else :
d = d1
if (p2 == p1) :
pa = 1
else :
#normalize(p1)
if not computep and max(p1) : p1 = [(px - 128) / 128. for px in p1]
computep = 1
p2 = [(px - 128) / 128. for px in p2]
pa = sum([px*py for (px,py) in zip(p1, p2)]) #dot product
if (pa < ndiff) or (d > zdiff) or (id1 != id2) :
seq_set_brush(contours, fx, fy, width, height, line_width)
return contours

je mets environ 25s (duron 1.8Ghz) pour traiter une image de 1600x1200 24bpp, sachant que le calcul est bien plus lourd qu'une convolution.. (de toutes façons le temps dépend du contenu de l'image)

j'ai essayé avec un filtre de detection de contour sur la normal map, mais ce n'est pas suffisemment precis, il faut qu'on puisse choisir les contours en fonction des normals, des profondeurs et des Ids, donc 3 maps a traiter, et le calcul n'est pas faisable en convolution proprement.

par contre j'ai un truc bizar, en utilisant numarrays, c'est 5x plus lent car il créer des objets numarray lors de la génération de list dans ce genre d'opérations :
p2 = [(px - 128) / 128. for px in p2]
(d'apres ce que j'ai pu analyser, mais ce n'est ptet pas la cause de la lenteur)

je sais pas comment lui forcer de pas traiter ca, je voudrai utiliser numarray uniquement sur mon image de résultat (contours[]), du coup j'utilise pas numarray

par contre, du fait que l'image final soit générée a partir de 3 listes d'entrée hétérogènes, je ne vois pas trop comment optimiser tout ça avec des map(list,func), une idée ?

pour info, l'utilisation de psyco.bind() sur ma fonction compute divise presque par 3 le temps de calcul (24s vs 61s)

Message édité par thekraken le 28-09-2004 à 22:05:02

Kristoph

thekraken a écrit :

ca y est a devient exploitable

par contre, du fait que l'image final soit générée a partir de 3 listes d'entrée hétérogènes, je ne vois pas trop comment optimiser tout ça avec des map(list,func), une idée ?

pour info, l'utilisation de psyco.bind() sur ma fonction compute divise presque par 3 le temps de calcul (24s vs 61s)

La syntaxe de map, ce n'est pas ce que tu as ecris mais ça :

Code :

>>> help(map)
map(function, sequence[, sequence, ...]) -> list

Comme ça, c'est très clair non ?

Taz

bisounours-codeur

# for dx in (0, 1) :
# for dy in (0, 1) :
# if (dx or dy) :

déjà, ça tu peux dérouler ...

ou faire tou simplement

for dx, dy in ((1, 0), (0, 1), (1, 1))

faut que tu fasse gaffe que les list compréhension sont très puissante [] mais que ça crée un nouvelle liste complète à chaque fois, ce qui peut bouffer un peu de mémoire pour pas grand chose

n'hésite pas à faire des pré-calculs
plutot que d'évaluer 4 ou 5 fois ce genre de chose fx + fy * width

ruse avec les propriétés des nombres
if color > 255 : color = 255 devient color &= 0xff

sauf preuve du contraire, dans ton cas, range est sans doute plus rapide que xrange

Kristoph

Taz a écrit :

ruse avec les propriétés des nombres
if color > 255 : color = 255 devient color &= 0xff

:heink: :heink:

thekraken

vip merci j'avais meme pas pensé a ca tellement j'étais dedans..
enfin ca m'a fait gagné encore 2s (22s sur la meme image que t'alleur), c'est déjà ça de pris !

merci pour tout

Taz

bisounours-codeur

tu devrais essayer avec les itertools sur cette portion

# p2 = [(px - 128) / 128. for px in p2]
# pa = sum([px*py for (px,py) in zip(p1, p2)])

thekraken

au fait, kristoph a raison, pour le
color &= 0xff
ce n'a pas le meme effet.. (modulo)

du coup j'ai mis
pixels[pos] = min(int(pixels[pos] + (255 * diff)), 255)

Taz

bisounours-codeur

ah oui, j'ai po fait attention. oops

thekraken

pour les itertools je vois pas trop, il faudrait passer de itérable à list (imap par exemple), alors que map() par exemple me permet de récupérer une list directement..

j'ai d'ailleurs essayé de remplacer les list comprehension par des map(lambda:,list), mais c'est beaucoup plus lent !! (50% plus lent)

Kristoph

Si tu veux transformer un iterrable en list, il suffit de faire list(iter). Je ne vois pas trop pourquoi tu voudrais faire map(lamba:,list) sinon

thekraken

au fait, voila le genre de truc que ca permet de faire :

scene de base avec un shader façon dessin/peinture, le script calcul le contour des objets (outline autour des spheres ici). la tesselation des spheres est basique ici alors c'est normals s'il y a des petites cassures dans l'outline (on voit que c de la 3D comme ça )

Taz

bisounours-codeur

dans

# p2 = [(px - 128) / 128. for px in p2]
# pa = sum([px*py for (px,py) in zip(p1, p2)])

il me semble que tu construits inutilement 3 listes
- p2
- le résultat de zip
- l'argument de sum

thekraken

par exemple moi j'ai essayé
p2 = map(lambda xp : (xp - 128) / 128., p2)

a la place de
p2 = [(px - 128) / 128. for px in p2]

en itertools ca donnerait un truc genre
p2 = list(imap(lambda xp : (xp - 128) / 128., p2))

si j'ai bien compris, je connais pas bcp python, mais je vois pas pkoi le fait de passer par de iterateurs serait plus rapide ??

on parle peut etre pas de la meme utilisation ?

Taz

bisounours-codeur

les LC sont très souvent plus rapide que map.

quand aux iterateurs : techniquement ils sont plus lent, mais si t'es listes sont grosses, ça t'évite de les créer, ici, tu évites 3 listes temporaires. vois les itérateurs comme des générateurs, qui fournisse 1 élément à la fois. en fonction de la taille de tes listes, il faut faire des mesures, ça peut être intéressant

en gros ta transformation, faut pas repasser par la case list, sauf sum (qui retourne une liste donc c'est bon)

faut mesurer et voir

Message édité par Taz le 29-09-2004 à 00:14:12

thekraken

taz : les listes ce sont des vecteurs a 3 composantes, donc c'est pas bien grave d'utiliser des variables de calculs intermediaires ?

-pour l'arguement de sum, je suis obligé, il faut bien d'abord que je calcul le produit de chaque composant puis la somme des produits calculés.
-pour p1 et p2, ca m'evite d'ecrire une ligne de code de 200 caracteres, y a une autre solution ?
-pour zip je doit associé chaque composant des 2 listes, par concaténer les listes, je vois pas comment faire ça plus simplement..

je vois pas trop comment faire autrement, ptet que je connais pas assez python pour comprendre ces subtilités..

thekraken

ok je comprend pour les itérateurs, la c'est des vecteurs 3D donc c'est pas util a priori.

les LC ça tue

Taz

bisounours-codeur

si c'est des vecteurs 3 éléments, je comprends pas pourquoi t'écris pas une jolie fonction toute simple et bien plus lisible ! surtout que c'est typiquement ce genre de petite fonction qui font déjà partie des bibli

thekraken

parceque, comme j'ai dis plus haut ("appel massif aux fonctions qui prenait du temps" ), c'est bcp plus rapide de passer par cette LC que par une fonction, interne ou déjà existante dans une lib..

j'ai fais les tests et les écarts sont non négligeables !

si les calculs étaient plus lourd que ca (ici c'est encore que quelques +*-), le temps d'appel d'une fonction de manière systématique (avec l'impilage des arguments..) serait rentabilisé par la longueur des calculs..

et puis ici j'utilise le calcul qu'1 et 2 fois dans ma boucle donc c'est pas génant pour l'écriture du script (je mets ce que c'est en commentaire et voila..)

Taz

bisounours-codeur

et alors ? entre créées 3 listes inutilement, appeler sum, appeler zip et appeler uniquement 1 seule fonction, tu sais plus compter ?

faut arrêter la paranoia du débutant : tu dis que les appels de fonctions sont lents, d'accord, maintenant faut l'appliquer :

# p2 = [(px - 128) / 128. for px in p2]
# pa = sum([px*py for (px,py) in zip(p1, p2)])

est clairement améliorable dans ton cas

thekraken

ollaaa je sais pas ce que j'ai merdé mais j'ai merdé !
j'ai du faire des erreurs avec les index dans le LC qui me faisaient croire que c'était plus rapide (débutant..)

en mettant

pp1 = [0, 0, 0]
pp1[0] = (p1[0] - 128) / 128.
pp1[1] = (p1[1] - 128) / 128.
pp1[2] = (p1[2] - 128) / 128.

pa = p1[0] * p2[0] + p1[1] * p2[1] + p1[2] * p2[2]

au lieu des LC c'est bien plus rapide (fonctions ou pas fonctions, donc j'ai mis des fonctions )

8s au lieu de 15s !!!

bon j'avoue la que j'ai bien merdé, ca m'apprendra a taffer tout fatigué.

merci d'avoir insisté et heureusement que j'ai retesté, ça m'intriguait qd meme !

du coup ca va, 8s pour traiter 3 images en 1280x1024 (soit 640x480 apres antialiasing), c'est tres correct en utilisation !

Message édité par thekraken le 29-09-2004 à 14:23:06

el muchacho

Comfortably Numb

Donc tu es passé d'une image 1280x1024 en 5 minutes à 3 images en 8 secondes et ce sans écrire une ligne de C ? Si oui, ça valait le coup d'optimiser.

thekraken

j'étais en vacances dc pas pu répondre plus tot..

non c'est le meme traitement (3 images à traiter à chaque fois), mais passé de plusieurs minutes a une 10aine de secondes pour la même taille d'image. Donc oui ça valait le coup et je pense qu'en C ça aurait pas été beaucoup plus rapide (et puis ca aurait été plus relou car la j'utilise PIL pour supporter plus de formats d'images facilement)..

Publicité

FORUM HardWare.fr

Programmation

Python

Optimisation traitement d'images

Sujets relatifs
[HTML sur IIS6] Problème d'images se rechargant à chaque fois	traitement des codes à barres
Cadre dynamique autour des images ?	Collision entre deux images pour un jeu ...
Récupération du contenu d'un fichier et traitement	Images et Mailing List
Problême pour coller des images pour un menu	Images. palette de couleurs + les regions
[PHP] Modifier JBrowser pour visualiser les images d'un autre serveur	DotClear : répertoire des images
Plus de sujets relatifs à : Optimisation traitement d'images

Page générée en 0.166 secondes