@MoiOlivier:
L'utilisation est Long rend les algos plus rapides car le Long est de 32 bits et nos processeurs (pour la plupart) sont 32 bits et sont donc optimisés pour etre au plus rapide avec ces valeurs ! celà explique pourquoi un long est plus rapide qu'un integer ou meme qu'un byte !!!
@Progmeister:
pas mal mais tu pourrais accélérer en cochant les cases pour optimiser la rapidié comme le dit MoiOlivier et surtout NE PAS UTILISER de progressbar !!! la progressbar il faut la rafraichir à intervals réguliers sinon tu perds énormément de temps !!!
et juste une petite astuce aussi quand tu inverse l'image. le calcul c'est effectivement NouvelleComposanteDeCouleur = 255 - AncienneComposanteDeCouleur
mais il s'agit de byte, donc d'octet et celà revient au même résultat de faire NouvelleComposanteDeCouleur = Not AncienneComposanteDeCouleur
Salut,
Merci, merci et merci, etc.
J'aime bien.
Vraiment bien.
Juste une (toute petite) chose : pense à cocher toutes les case dans la fenêtre "options avancées" des options de compilation, ça fait gagner pas mal de temps lors du calcul des effets...
Ah oui, toujours pour l'optimisation (et c'est encore un détail) : utilise des Long, toujours des Long, et non des Integer quand tu peux (perso, j'ai remarqué que c'était plus rapide aussi...)
Bon les gars je sais bien que je n'ai pas inventé les apis SetDIBits et GetDIBits, c'est d'ailleurs sur VB que j'en ai eu l'idée et d'ailleurs grace à DarkSidious mais:
1 - L'API était mal utilisée, le tableau de Bytes passé en paramètre pour récupéré les pixel était mal dimensionné ce qui le rendait inutilisable pour des filtres plus complexe, et les paramètres de la structure BITMAPINFO étaient mal définis si bien que l'on ne pouvait pas appliquer de filtre sur la plupart des images chargées avec la fonction loadpicture (ou avec les apis pour les puristes)
2 - Je déplore que sur VBFrance, 98% des effets graphiques programmés, aussi bons soient ils, utilisent les fonctions GetPixel et SetPixel (SetPixelV si tu veux, ca ne change pas grand chose ici) qui sont particulièrement lentes...
Voila ma source est donc à but pédagogique, pour faciliter l'utilisation de ces deux fonctions si peu utilisées
De plus cette source était à la base faite pour présenter l'effet de produit de convolution, utilisé par tous les logiciels de retouche d'image
Merci pour tes idées ScSami mais j'ai d'autres projets pour le moment....
C'est clair, Bozzo a raison. Y'a plein de sources sur VBF concernant Get et Set DIBits (cf. les sources, entre autre, de DarkSidious)!!!
De plus, si tu connais un moyen plus rapide que SetPixel, ben ça ne peut être que SetPixelV qui, je le rappel, n'a pas la précision colorimétrique du premier!
Mais bon, l'intention est bonne.
Cependant, si tu veux vraiment faire un truc inédit sur VBF, fait nous une bonne source pour faire des panoramas (voir même des anaglyphs panoraniques ;-)
Ou alors une source de stéréogrammes.
- Messages postés
-
14847
- Date d'inscription
- vendredi 14 mars 2003
- Statut
- Modérateur
- Dernière intervention
- 19 janvier 2022
160L'utilisation est Long rend les algos plus rapides car le Long est de 32 bits et nos processeurs (pour la plupart) sont 32 bits et sont donc optimisés pour etre au plus rapide avec ces valeurs ! celà explique pourquoi un long est plus rapide qu'un integer ou meme qu'un byte !!!
@Progmeister:
pas mal mais tu pourrais accélérer en cochant les cases pour optimiser la rapidié comme le dit MoiOlivier et surtout NE PAS UTILISER de progressbar !!! la progressbar il faut la rafraichir à intervals réguliers sinon tu perds énormément de temps !!!
et juste une petite astuce aussi quand tu inverse l'image. le calcul c'est effectivement NouvelleComposanteDeCouleur = 255 - AncienneComposanteDeCouleur
mais il s'agit de byte, donc d'octet et celà revient au même résultat de faire NouvelleComposanteDeCouleur = Not AncienneComposanteDeCouleur
sauf que c'est plus rapide pour le processeur =)
bonne continuation