[R] PixelSearch ne prend pas en compte le Handle du GUI

[parazitenew]

Bonjour,

J’ai un problème avec la fonction pixelsearch, mon programme trace une courbe, sans rentrer dans les détails cette courbe est de couleur bleu (0000ec), sur un papier millimétré en BMP de (800, 578), dans un GUI de(800,598), 20px pour le menu.

http://www.heberger-image.fr/data/image ... apture.png

L’axe X correspond à des pourcentages, l’axe Y correspond à des élévations en mètres.
Ce que vous voyez en rouge en bas, 5% et 95%, sert à calculer le dénivelé spécifique, Ds = D5% - D95%.

Prenons exemple le D5%, c’est la projection sur l’axe des Y un point du graphe qui correspond au 5% sur l’axe des X. J’ai tracé en rouge les projections pour mieux illustrer.

En pixel le 5% se trouve à « 93px » du bord gauche du GUI, je me suis dit je connais l’x je connais la couleur, pourquoi ne pas utiliser le pixelsearch, il va me chercher tout les pixels bleu (0000ec) de la fenêtre, me les mettre en tableau, je n’aurai qu’à prendre celui qui aura comme x « 93px » et je connaitrai son y en px, pour moi c’était l’idée de l’année.

Seulement voilà, la fonction s’arrête au premier pixel qu’elle trouve, j’ai donc fait une boucle,
Ça n’a pas marché, j’ai toujours ce pixel qui ressort (298,294),

http://www.heberger-image.fr/data/image ... pture2.png

d’après ses coordonnées, ce pixel se trouverai dans le blanc du papier, du coup en cherchant j’ai trouvé que ce pixel est calculé par rapport à l’écran et non à la fenêtre, ça serai le premier pixel bleu du graphe. Pourtant le handle est correcte.
Questions :

1.Comment faire en sort que cette fonction cherche en fonction du GUI et non de l’écran ?
Comment tracé le réctangle en fonction du GUI et non de l'écran, ça revient au même.
2.Comment faire en sorte qu’elle ne s’arrête pas au bout du 1er pixel trouvé ?
3.Auriez-vous une meilleure idée ?

Pour la 2ème question, en cherchant sur le forum, j'ai trouvé un sujet qui parlait de ce problème, re tracer le rectangle en fonction du 1er pixel et ainsi de suite pour les autres.

J’ai une autre idée, réduire le rectangle de recherche, étant donnée que je connais la position en X « 93px », je fais en sorte que le rectangle aura comme dimensions (92, 0, 94, 578) le rectangle aurai 1px de largeur et 578px, de hauteur, le hic c’est que même le rectangle est calculé par rapport à l’écran. Ça doit être fait par rapport au GUI.

Pourquoi mon handle bug ?

► Afficher le texte

Code : Tout sélectionner

$hndl = WinGetHandle("Courbe Hypsométrique")
                                ;MsgBox(0,"",$hndl)
                             
                                If IsHWnd($hndl) Then
                                MsgBox(4096, "", "It's a valid HWND")
                                EndIf

                                     ;Le problème est là même si le handle est correcte d'après la condition précédente, il cherche par rapport à l'écran        
                                  $pixel = PixelSearch(0,0,800,578,0x0000ec,0,1,$hndl)

                                                                                                        

                                _ArrayDisplay($pixel)

[mikell]

Essaie PixelCoordMode avec params 0 ou 2

Mais "mon programme trace une courbe" donc il doit bien y avoir des coordonnées définies de points qui permettent de tracer cette courbe, pourquoi ne pas les mettre en array à ce moment-là ?

[parazitenew]

la courbé est tracée à partir d'un tableau, les X, (%) calculés dans le tableau, les Y des élévations entrées par l'utilisateur.

Si l'utilisateur rentre que 8 entrées, il y'aura que 8 points, la formule de la Ds est fixe, c'est D5% - D95% et les points correspondants ne font pas partit de ces 8 points.

La fonction qui trace le graphe _GDIPlus_GraphicsDrawCurve () utilise ces 8 points.

J'ai testé le PixelCoordMode avec le paramètre 2, (je la connaissais pas celle là) le résultat obtenue est correcte.

Merci mikell, c'est resolu maintenant.

Edit: Je ne sais toujours pas pourquoi le handle du GUI n'est pas pris en compte.

[mikell]

c'est resolu maintenant.

Donc tu peux mettre [R] dans la balise de titre de ton sujet que tu as oublié de mettre

Le handle de la gui n'est évidemment pris en compte qu'à partir du moment où tu spécifies le PixelCoordMode 0 ou 2

[parazitenew]

C'était fait expré car la dernière question n'était pas résolu, néanmois, l'aventure continue.

Sur le screen vous avez bien vu que je travaillais sous W7 et avec le thème classique, j'ai une bien bonne à vous raconter, j'ai juste remis le thème W7 par default (Aéro) le PixelSearch() ne fonctionne plus, c'est pas drôle ça ?
Classique fonctionne, défaut fonctionne pas, classique fonctionne, défaut fonctionne pas.

Mais "WTF ??????" Je vais devenir fou!!!!!!!!! Le rapport entre un thème et une fonction ????

Le problème est ceci:

► Afficher le texte

Code : Tout sélectionner

Subscript used with non-Array variable.:
If $pixel[0] = 93 Then

Tout simplement que le PixelSearch() ne retourne plus d'array, l'array est vide, enfin elle n'existe pas.

Attendez, la meilleure, j'ai rajouté un msgbox avant le pixelsearch, bin devinez ça fonctionne

Mais ce n'est pas une solution à garder, mais attendez, après compilation et déstribution de ce programme, il risque de pas marcher juste à cause d'un thème ??? Je vais m'arracher les cheveux.

=======================
Edit
=======================

Le msgbox m'a mis sur la voie, j'ai rajouté un Sleep(500) avant le PixelSearch() et ça refonctionne, une idée sur la question ? Et me dites pas ( W7 )
Le script chercherait-il un pixel qu'il n'était pas encore affiché sur l'écran ? Autoit serait-il plus rapide que son ombre ?

[jchd]

Je reviens sur un point plus fondamental.
Tu demandais s'il y aurait une autre piste ?
A mon sens, oui et certainement meilleure et plus rigoureuse que de partir à la pêche aux pixels dans un bitmap dessiné plus ou moins au pif par une spline dont tu ne maîtrises pas du tout les paramètres.

Puisque tu cherches une interpolation à 5% et 95%, pourquoi ne pas faire le calcul toi-même avec une interpolation que tu maîtrises, considérer les points obtenus comme faisant partie des relevés et injecter tes 8+2=10 points à la primitive de tracé ?

Tu gardes ainsi le choix des caractéristiques de l'interpolation et si le besoin s'en fait sentir, tu peux agir sur ses paramètres et recalculer tes points de façon prévisible.

Ceci dit, selon que tes relevés sont régulièrement répartis ou non, leur tolérance et d'autres critères (terrain montagneux ou plaine, ou autre critère), tu disposes d'une quasi infinité de fonctions d'interpolation éprouvées (mais plus ou moins prouvées !).

Comme dit très justement Paul Faget de Casteljau dans son formidable bouquin "Le lissage", chacune de ses merveilleuses fonctions est bien entendu "la meilleure", preuve à l'appui, puisqu'elle minimise une somme de carrés ou une autre quantité incongrue. Il va sans dire que je recommande chaudement une lecture appronfondie de cet ouvrage à chaque fois qu'on me parle d'interpolation ou même d'extrapolation de données !

[parazitenew]

La courbe est en fonction du relief, elle peut avoir n'importe quel tracé, il n'y a pas de fonction définie donc pas moyen de prévoir quoi que ce soit. Pour le reste de ton message j'ai pas du tout compris, c'est trop technique , sinon ça marche à merveille, j'ai des résultats justes.

[jchd]

C'est toi qui voit, du moment que ça ne concerne pas mon terrain

Une question qui me vient comme ça : le point (0, 550) est-il donné par ailleurs ou extrapolé ?
Il ne figure pas dans la liste des altitudes qu'on voit sur ta première image.

Ah oui, autre chose : tu aurais intérêt à faire coïncider le quadrillage horizontal avec l'échelle. Ce n'est pas très lisible ainsi.

[mikell]

le fait est que ce serait intéressant de pouvoir connaître la fonction correspondant à la courbe tracée par GdipDrawCurveI (pourquoi pas GdipDrawCurve2 ou GdipDrawCurve3 d'ailleurs ? une tension par défaut semble arbitraire) sans pour autant rentrer dans des prises de tête mathématiques
Microsoft n'en parle pas (ou alors j'ai pas trouvé..)

[jchd]

Exactement ça : une "cardinal spline", autant dire au pif. C'est là tout le problème du lissage et donc de l'interpolation et pire, de l'extrapolation. D'où ma question sur le point à 0% et ma référence appuyée au bouquin de De Casteljau.

Il m'est facile d'illustrer mon propos avec un rapide exemple si quelqu'un y voit intérêt.

Enfin ce que j'en dis moi, c'est juste comme ça, hein. Encore une fois, tant que la flotte ne m'atterit pas dans les chaussons, la question reste un tantinet académique bien que non sans conséquences pratiques selon le contexte d'utilisation.

[parazitenew]

:

Une question qui me vient comme ça : le point (0, 550) est-il donné par ailleurs ou extrapolé ?
Il ne figure pas dans la liste des altitudes qu'on voit sur ta première image.

le point (0, 550) c'est moi qui l'ai posé, car je délimite l'axe Y.

Ah oui, autre chose tu aurais intérêt à faire coïncider le quadrillage horizontal avec l'échelle. Ce n'est pas très lisible ainsi.

Je ne fais que coïncider l'élévation maximale et minimale, pour le reste ça se calcul, je n'ai pas de contrôle dessus, voici la formule:

► Afficher le texte

Code : Tout sélectionner

Global $array_points [$nb_line+2][2]
                        $array_points [0][0] = $nb_line +1
                        For $i = 1 to $nb_line

                            $eval_x = Eval("S"&"i"&"_"&"x"&$i)
                            $eval_y = Eval("S"&"i"&"_"&"y"&$i)
                            $eval_x = Round((_GUICtrlListView_GetItemText($lv,$i-1,4)*714)/100,1) + 57
                            $eval_y = (Round((($h_max - _GUICtrlListView_GetItemText($lv,$i-1,0))*513)/$D_h,1)) + 29

                            $array_points [$i][0] = $eval_x
                            $array_points [$i][1] = $eval_y

                        Next

513 = L'écart en pixel entre h_min et h_max, sur le Bitmap
$h_max = l'altitude maximale du bassin versant, dans cet exemple 550m
$D_h = L'écart en mètres entre h_min et h_max, dans cet exemple 75m
_GUICtrlListView_GetItemText($lv,$i-1,0) = lit l'altitude minimale du LV
29 = l'écart en pixel entre le top du GUI et le début de l'axe Y le (550m)

J'ai fait la règle de trois en prenant en compte les 29 px de cette façon je ne peux pas faire coïncider les élévations et c'est facile ainsi. L'utilisateur peut entrer 10,20 voir 50 données si il veut, je ne peux pas agrandir le Bitmap, donc je suis obligé de faire adapter l'échelle à la taille de l'image.

H_max de l'utilsateur va prendre la place de 550m, H_min celle de 475, et tout le reste en fonction de l'équidistance de sa carte sera calculé. Il pourrait mettre 1118m et 2000 m avec une équidistance de 25m si je dois faire coincider les élévations avec le quadrillage, la taille de l'image doit changer.

[jchd]

C'est parce que tu raisonnes d'entrée en pixels. Fais le calcul en unités à représenter et seulement ensuite convertis en pixels dispos. Il faut seulement choisir un quadrillage adapté, arrondi à des valeurs pseudo-rondes : trop fin ça fait fouillis, trop grossier ça ne sert plus à rien.

Ce que je voulais dire à propos de splines "au pif", c'est que la courbe change radicalement selon la méthode et le degré d'interpolation. Ci-dessous un exemple vite fait avec Mathematica et tes données d'entrée.

Première rangée de graphiques : interpolation d'Hermite = pas de continuité des dérivées entre les arcs. Rangées du dessous : interpolation par splines simples = plus de continuité entre arcs. De gauche à droite, on passe de l'ordre 1 (interpolation linéaire) à l'ordre 5 (avec des ressauts qui deviennent incontrôlables). Toutes ces courbes sont correctes, même si on se doute bien que les dérivées ne sont pas les bonnes.


Un graphique plus ou moins exploitable :

[parazitenew]

Peut-on contrôler l'ordre de la fonction _GDIPlus_GraphicsDrawCurve() ? Car j'ai un autre programme qui trace une courbe, je laisse l'utilisateur choisir entre cette fonction et celle-ci _GDIPlus_GraphicsDrawLine(), et même de les superposer pour voir la marge d'erreur, car la fonction curviligne se courbe trop au niveau des points à mon sens.

[mikell]

Comprends pas "l'ordre de la fonction"

la fonction curviligne se courbe trop au niveau des points à mon sens.

jchd va adorer ta remarque
Tu pourrais utiliser _GDIPlus_GraphicsDrawCurve2() où tu peux mettre le paramètre 'tension' en variable pour faire varier le degré de courbure
Avec une tension à 0 tu obtiens une suite de segments, probablement la représentation la plus 'objective' quand la courbe n'a pas de fonction définie

► Afficher le texte

Code : Tout sélectionner

Func _GDIPlus_GraphicsDrawCurve2($hGraphics, $aPoints, $nTension, $hPen = 0)
    Local $iI, $iCount, $iTmpErr, $iTmpExt, $pPoints, $tPoints, $aResult

    _GDIPlus_PenDefCreate($hPen)

    $iCount = $aPoints[0][0]
    $tPoints = DllStructCreate("float[" & $iCount * 2 & "]")
    $pPoints = DllStructGetPtr($tPoints)
    For $iI = 1 To $iCount
        DllStructSetData($tPoints, 1, $aPoints[$iI][0], (($iI - 1) * 2) + 1)
        DllStructSetData($tPoints, 1, $aPoints[$iI][1], (($iI - 1) * 2) + 2)
    Next

    $aResult = DllCall($ghGDIPDll, "uint", "GdipDrawCurve2", "hwnd", $hGraphics, "hwnd", $hPen, "ptr", $pPoints, "int", $iCount, "float", $nTension)
    $iTmpErr = @error
    $iTmpExt = @extended

    _GDIPlus_PenDefDispose()

    If $iTmpErr Then Return SetError($iTmpErr, $iTmpExt, False)
    $GDIP_STATUS = $aResult[0]
    Return $aResult[0] = 0
EndFunc   ;==>_GDIPlus_GraphicsDrawCurve2
 

@jchd
L'exemple est parlant et montre bien que le choix de la courbe affichée est effectivement arbitraire mais fondamentalement ça change rien au problème

[jchd]

Argh, je viens de me recoller sur le clavier pour voir que Mikell avait fait la même chose que moi...

A essayer avec des valeurs "raisonnables" de $fTension (entre 0.0 et 1.0) pour déterminer ce qui convient le mieux à tes sens

► Afficher le texte

Code : Tout sélectionner

; GDI+ draw spline with tension parameter

; #FUNCTION# ====================================================================================================================
; Name...........: _GDIPlus_GraphicsDrawCurve2
; Description ...: Draw a cardinal spline
; Syntax.........: _GDIPlus_GraphicsDrawCurve2($hGraphics, $aPoints[, $hPen = 0 [, $fTension]])
; Parameters ....: $hGraphics   - Handle to a Graphics object
;                  $aPoints     - Array that specifies the points of the curve:
;                  |[0][0] - Number of points
;                  |[1][0] - Point 1 X position
;                  |[1][1] - Point 1 Y position
;                  |[2][0] - Point 2 X position
;                  |[2][1] - Point 2 Y position
;                  |[n][0] - Point n X position
;                  |[n][1] - Point n Y position
;                  $hPen        - Handle to a pen object that is used to draw the spline. If 0, a solid black pen with a width of
;                  +1 will be used.
;                  $fTension    - spline tension parameter: 0.0 draws strait lines between points, 1.0 is maximum order, beyond
;                  results in spurious bounces
; Return values .: Success      - True
;                  Failure      - False
; Author ........: Paul Campbell (PaulIA)
; Modified.......: Gary Frost, jchd
; Remarks .......: A segment is defined as a curve that connects two consecutive points in the cardinal spline.  The ending point
;                  of each segment is the starting point for the next.
; Related .......:
; Link ..........: @@MsdnLink@@ GdipDrawCurve2I
; Example .......: Yes
; ===============================================================================================================================
Func _GDIPlus_GraphicsDrawCurve2($hGraphics, $aPoints, $hPen = 0, $fTension)
    Local $iCount = $aPoints[0][0]
    Local $tPoints = DllStructCreate("long[" & $iCount * 2 & "]")
    For $iI = 1 To $iCount
        DllStructSetData($tPoints, 1, $aPoints[$iI][0], (($iI - 1) * 2) + 1)
        DllStructSetData($tPoints, 1, $aPoints[$iI][1], (($iI - 1) * 2) + 2)
    Next

    __GDIPlus_PenDefCreate($hPen)
    Local $aResult = DllCall($ghGDIPDll, "int", "GdipDrawCurve2I", "handle", $hGraphics, "handle", $hPen, "struct*", $tPoints, "int", $iCount, "double", $fTension)
    Local $tmpError = @error, $tmpExtended = @extended
    __GDIPlus_PenDefDispose()
    If $tmpError Then Return SetError($tmpError, $tmpExtended, False)
    Return $aResult[0] = 0
EndFunc   ;==>_GDIPlus_GraphicsDrawCurve2
 

L'ordre, c'est (en gros) le degré du polynôme qui interpole entre deux points et la continuité de la dérivée seconde de part et d'autre des points. Pour que deux segments consécutifs se suivent sans "cassure" il faut que les dérivées d'ordre successives restent continues.

Le gros mensonge de ces approches de l'interpolation, c'est de prétendre construire une série de polynômes dont les dérivées successives sont inconnues mais doivent respecter des contraintes de continuité (l'ordre). En fait on intègre une fonction inconnue passant par des points connus en assignant à ces points des dérivées pifométriques. Comme on sait pas résoudre ce type de problème, on paramètre les dérivées et on en déduit [sic] la fonction qui produit ces dérivées. Pas étonnant qu'on ait ... un certain choix !

Zut, je n'ai plus rien à ajouter !

Désolé d'avoir insisté et débordé du strict cadre AutoIt mais je trouve qu'un exemple comme celui-ci dans l'indexation vaut l'usure du clavier et des yeux des lecteurs.

[parazitenew]

Ahn c'est ce que je voulais dire par ordre, la "Tension", je savais pas qu'on appelait ça comme ça. Votre fonction est la même, sauf que le $hPan et $nTension ne sont pas dans le même ordre, la fonction marche bien c'est ce que je cherchais .

@mikell l'idée de laisser l'utilsateur choisir la tesion est bonne.

les 2 fonctions __GDIPlus_PenDefDispose() et __GDIPlus_PenDefCreate() n'étaient pas reconnues je les ai rempalcé par _GDIPlus_PenCreate() et _GDIPlus_PenDispose() je supose qu'on a pas la même version d'autoit, car j'ai entendu dire que les mises à jours ont apportés des changements aux noms.

Bref, je pense qu'on a fait le tour ?

Merci pour votre aide, à la prochaine pour de nouvelles aventures.