Discussion :

[Gilbert Geyer]

Bonjour,

A Speed41 :

1 )

Stratégies ... Ok mais pour chaque pixel de couleur rouge, je dois chercher dans toutes les directions le pixel de couleur rouge différent et une fois ces deux pixels obtenus je trace une ligne en faisant un dégradé (variation de la couleur rouge) donc je regarde chaque pixel de mon image plusieurs fois.

... oui mais pour une stratégie donnée le nombre de ces triturations est sensiblement le même dans la version Pixels[] et Scanline[] donc l'écart de durée d'exécution entre ces deux versions devrait logiquement mettre en évidence la plus grande rapidité avec ScanLine[].
... il y a peut-être une lourdeur dans ton code qui bride les performances de ScanLine.

2)

un dessin de 600 x 800 plus de 4 heures

... bigre t'as une sacrée patience !!! félicitations. Moi je craque lorsqu'un un test de mise au point m'oblige à admirer le sablier pendant plus de 5 minutes ... et je m'arrange généralement pour faire la plus grande partie des tests de mise au point sur des modèles réduits afin de réduire au max les tests sur modèle de grandeur réelle. A propos de "plus de 4 heures" : à ta place j'aurais pas encore mis le tag "Résolu" devant l'intitulé de cette discussion car il y a certainement de quoi gagner en vitesse d'exécution, et peut-être aussi de quoi enlever ce tag en attandant la suite.

3)

Il est claire qu'au vu de ton essai, je suis surpris du temps pris pour le tracé ... je vais regarder de plus près mon code et voir pour l'amérioration

... moi je suis surtout supris par la faiblesse de l'écart entre les temps mis avec Pixel[] et ScanLine[] car je comprends fort bien que tes temps soient supérieurs aux miens vu que dans mes codes de test il n'y a pas toutes ces triturations pour trouver les pixels de couleur rouge différente.
... tu peux aussi poster ton code ici, il y aura peut-être d'autres suggestions d'amélioration d'autant plus que les idées des uns donnent souvent des idées aux autres ce qui est l'intérêt d'un forum.

4)

Est ce que le fait de travailler sur un TImage et non sur un TBitmap cela impacte la vitesse d'execution ?

... dans mes codes de tests j'ai été obligé d'ajouter les deux lignes suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
          Bmp:=Image1.Picture.Bitmap;
          .... boucles de traitement ...
          Image1.Picture.Bitmap:=Bmp;

pour la bonne et simple raison que dans un 1er temps le code n'utilisait pas cette variable locale Bmp mais travaillait directement sur Image1.Picture.Bitmap sauf que ça ne changeait absolument pas les couleurs dans l'image affichée y compris après avoir ajouté un UpDate. Ma var locale Bmp récupère donc la version initiale du BitMap de Image1 en entrée de la routine et en fin du traitement je réaffecte le Bmp-modifé au BitMap de Image1 pour réactualiser son contenu et l'affichage et enfin ça marchait.
Donc en réponse à ta question : cela impacte avant tout sur l'obtention du changement des couleurs visibles à l'écran sinon la vitesse d'exécution d'un Ligne := Bmp.ScanLine[Y]; et d'un Ligne := Image1.Picture.Bitmap.ScanLine[Y]; devrait être à peu près la même sauf que dans un cas on travaille sur une var locale et dans l'autre sur la propriété d'un composant ce qui donnerait un avantage à la var locale ... et comme ce n'est qu'avec elle que ça a marché impossible d'en savoir davantage sur cette différence de vitesse.

5) A Linkin

Ne serait-il pas plus efficace de faire travailler sur un bitmap de cache?

... cela revient à faire ce que je viens d'évoquer ... sauf que dans mon code cela se fait en 2 instructions au lieu de 4 ... et comme ça marche, ça allège le code.

A+

[Linkin]

J'ai fait un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
bmp := Image1.Picture.Bitmap;
Image1.Picture.Bitmap.Free;

la variable bmp est à nil. Donc j'ai supposé que ça travaillait directement sur le bitmap à l'écran.

Edit: faute de frappe

[Speed41]

Voulez vous rire ? de ma stupidité ?

Je n'ai pas fait le test entre scanline est pixel mais maintenant je suis descendu à 30 secondes pour un dessin de 200 x 200

Voulez vous l'explication montrant, de ma part une erreur non escusable ?



Et tout est de ma faute et non celle du programme.

Pour vérifier les bon déroulement de mon programme j'utilisais 2 objets pour visualiser le poit de départ et le point comparé et je n'avais pas utilisé le même (pourquoi ???) et quand j'enlève lle deuxième objet je passe de 10 minutes à 30 secondes.

Ce qui me perturbais au début c'est que le dessin ne se dessinais pas correctement à l'écran et j'avais toujours remis cet objet et tout à l'heure débarassant la table une idée m'est passé par la tête et donc j'ai compris que ce n'était qu'un rafraichissement de l'image.

Voilà je vais pouvoir comparer plus résonnablement pixels et scanline et je suis heureux

et surtout merci de votre aide et excusez moi encore



Et la je pense que mon est bien mérité et il est vrai qu'il était précipité

Merci

[Gilbert Geyer]

Bonjour,

Speed41 :je suis descendu à 30 secondes pour un dessin de 200 x 200

... tu ne trouves pas que c'est encore un peu lent ? (lol)
... car pour le changement de toutes les couleurs de mon image de 384 x 256 avec Scanline je clique sur mon bouton et le changement de couleurs s'affiche immédiatement.
... y'a p'têtre encore des secondes à gratter, non ?
... mais je suis encore plus impatient de connaître l'écart des temps mis entre Scanline[] et Pixels[] pour ton dessin de 600 x 800 qui prenait plus de 4 heures.

A+

[Speed41]

Oui biensur il y a des secondes à gratter mais ce sont mes mises à jour d'affichage, un objet visuel et le fait de vouloir absolument voir ce qui ce passe en live.

Je pense qu'il faut que je fasse de petites modifs (utilisation d'objets non visuels opar exemple) et autre

Ce qui me surprends le plus c'est que le programme utilise 100% de mes ressources (à poffiner)

Bon promis, je lance rapidement ma comparaison scanline / pixels sur mon image 800 x 600 (disons fin de semaine, le programme est bien chargé)

A suivre

[Gilbert Geyer]

Bonjour,

A Speed41

Oui biensur il y a des secondes à gratter mais ce sont mes mises à jour d'affichage, un objet visuel et le fait de vouloir absolument voir ce qui ce passe en live.

... c'est normal et vachement utile en phase de mise au point, mais par la suite on peut se contenter de n'afficher que le résultat final.

Je pense qu'il faut que je fasse de petites modifs (utilisation d'objets non visuels par exemple) et autre

... et pourquoi pas plus simplement "suppression d'objets visuels" au lieu de "utilisation d'objets non visuels" qui eux-aussi bouffent des ressources ? Mais t'es mieux placé que moi pour faire le tri entre ce qui est indispensable de ce qu'on peut virer.

Ce qui me surprends le plus c'est que le programme utilise 100% de mes ressources (à poffiner)

... ben si tout est structuré pour traiter par exemple une image de 800x600 ça fait 480 000 points à mulitiplier pour un certain nombre de structures par le nombre des caractéristiques de ces points.
... mais si tu redimensionnes tes structures pour faire l'essentiel du traitement sur des BitMap de 200x200 qu'on place en phase terminale cote à cote en damier sur un BitMap final de 800x600 cela devrait alléger certaines structures avec peut-être même un gain de temps supplémantaire car avec des 200x200 c'est à dire 12 fois moins de points chaque case de ce damier sera à mon avis scanné beaucoup plus rapidement.

Bon promis, je lance rapidement ma comparaison scanline / pixels sur mon image 800 x 600 (disons fin de semaine, le programme est bien chargé)
A suivre

... y'a pas le feu, à chaque jour suffit sa tâche.

A+

[Speed41]

Super info

Je viens de passer à de 24 à 4 secondes pour un 200 x 200 en supprimant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

caption:=timetostr(time-t);

Je ne m'y attendais pas ...

Pour info je scrute 200 x 200=40 000 points, je viens de comptabiliser en plus 3 201 924 points pour ce dessin soit un total de 3 241 924 et je précise pour ce dessin. J'ai colorié 1 346 358 points

Soit un total de 4 588 282 scruté et coloriés pour un dessin de 200 x 200

Pour les 40 000 points je regarde si le pxel est rouge [0-255] (pas bleu ni blanc)

S'il est rouge, je regarde dans toutes les direction (360°) pour trouver le point rouge ou bleu le plus prêt

Si le point est rouge et d'intensité différent je trace un dégradé.

ce qui explique le temps mais j'en gagne

Je coloris des points que j'ai déjà coloriés car je scrute sur un dessin (TBitmap) et je trace sur un autre ce qui fait que mes tracés n'affectent pas le dessin scruté. Pourquoi car en scrutant le dessin que je colori j'ai trop de zones non coloriées et trop grandes.

A+

[Speed41]

Temps

le dessin 200 x 200

avec Pixels : 13 secondes
avec Scanline : 4 secondes

Pour info un dessin de 800 x 600 en 2'09" stisfaisant

A+

[Gilbert Geyer]

Re-bonjou,

Je viens de passer à de 24 à 4 secondes pour un 200 x 200 en supprimant caption:=timetostr(time-t); Je ne m'y attendais pas ...

... ça montre bien l'intérêt de supprimer le affichages superflus ... surtout à l'intérieur de boucles.

le dessin 200 x 200
avec Pixels : 13 secondes
avec Scanline : 4 secondes

... l'écart en faveur de Scanline commence à être cohérent ( car cela m'étonnait l'autre jour les 10 minutes dans les deux cas c'était pas normal )

Pour info un dessin de 800 x 600 en 2'09" stisfaisant

... ben voilà on y est arrivé.

A+

[Speed41]

Merci pour ton aide


Voici l'image de départ 200 x 200

Les zones en bordure gradués ne sont pas prises en compte, les zones bleu ne sont que scrutés

et voici le résultat


et ma carte 800 x 600


A+

[Gilbert Geyer]

Bonjour,

Pas mal le résultat, j'aurais juste fait un peu moins sombre (question de goût ... à chacun le sien).
Dire qu'on est descendu, pour le dessin de 600 x 800, de plus 4 heures à 2 min 09 ça valait le coup. (4x60/2 = coeff d'accélération de 120)

A+

[Speed41]

Oui, merci de ton aide