Discussion :

[Discret68]

Bonjour

Encore un problème lié à la publication de mon projet (analyse d'images astronomiques).

J'ai un form dans lequel j'ai une picturebox qui me permet de visualiser une image. Sur cette image, lorsque je balade mon pointeur de souris, j'ai une indication en temps réel des composantes RVB du pixel sur lequel se situe le pointeur (voir copie d'écran).

Lorsque je clique sur une étoile ou très proche, j'ai une première phase d'analyse de la zone qui me permet de trouver précisément le centre de l'étoile. Au final, j'ai une courbe de luminosité de l'étoile qui se trace, avec une coupe horizontale (courbe jaune) et une coupe verticale (courbe verte).



J'utilise un bout de code récupéré sur le net et qui me permet de déterminer les valeurs RVB du pixel survolé. J'utilise également cette même fonction pour déterminer le centre de l'étoile et établir la courbe de luminosité de l'étoile pointée.

Voici le code que j'utilise :

Code :

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

1
2
3
4
5
6
7
8
9
Private Declare Function GetPixel Lib "gdi32" Alias "GetPixel" (ByVal hdc As Int32, ByVal x As Int32, ByVal y As Int32) As Int32
 
Dim win, rgb, hdc As Int32
Dim g As Graphics = Graphics.FromHwnd(New IntPtr(win))
hdc = g.GetHdc.ToInt32
rgb = GetPixel(hdc, COORD_X, COORD_Y)
PRed = rgb And &HFF
PGreen = (rgb And &HFF00) / 256
PBlue = (rgb And &HFF0000) / 65536

Bref, dans mon projet, tout fonctionne parfaitement.

Souhaitant utiliser ce programme sur d'autres ordinateurs, j'ai publié mon projet. Et là, patatra, la fonction ne marche pratiquement plus. En clair, j'ai essayé sur 4 autres ordinateurs et un seul fonctionne ! Sur tous les autres, la valeur de n'importe quel pixel est à &HFFFFFF et donc, tout le processus est un échec.

J'ai vérifié que la gdi32.dll est bien présente sur les ordinateurs de test.

J'ai passé des heures de recherche sur le ne, en vain.

Une bonne âme aurait-elle une solution pour mon problème ?

Merci à vous.

[François DORIN]

Bonjour,

Petite vérification à faire : quelle est l'architecture sur les PC où le programme marche ? Et ne marche pas ? 32bits ? Ou 64 bits ?

Je pose la question car le type IntPtr représente un pointeur dont la taille dépend de l'architecture. Or, GetHdc retourne un IntPtr, sur lequel tu appelles toujours ToInt32 quelque soit l'architecture. Donc si mon diagnostique est bon, ton programme fonctionne correctement sur une architecture 32 bits, mais te renvoie une valeur erronée sur une architecture 64 bits (car convertir un pointeur 64 bits sur un entier 32 bits à de grande chance de te retourner une valeur erronée).

Pour avoir une version qui fonctionne quelque soit l'architecture, voici ce que je ferais :

• je modifierai le type du paramètre hdc de la fonction GetPixel. Utilse IntPtr au lieu de Int32
• je supprimerai l'appel à ToInt32 pour utiliser directement le retour de la méthode GetHDC (qui est de type IntPtr)

[Discret68]

Bonsoir François.

L'ordi sur lequel j'ai développé mon projet est sous Win10 64 bits et tout fonctionne sans problème.
Les 2 autres ordinateurs sur lesquels j'ai des problème sont sous seven 64 bits.

Concernant le problème de getPixel, j'ai créé un petit projet avec une image sur laquelle j'utilise le GtPixel. A force de parcourir le net, j'ai trouvé une syntaxe très légèrement différente de celle que j'utilise. A priori, sur ce petit projet, ça fonctionne sur l'ordi Win10 et sur un des ordi avec seven. Je n'ai pas essayé le 3ème.

Une fois que j'intègre ce code à jour dans mon projet principal, ça ne marche que partiellement. La valeur RGB des pixels s'affiche correctement sur une partie de l'image et sur le reste, j'ai une valeur de 255 sur chacune des composante, même sur du noir.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    Dim rgb As Int32
    Dim hdc As IntPtr
 
  Using g As Graphics = Graphics.FromHwnd(PictureBox1.Handle)
            hdc = g.GetHdc
            rgb = GetPixel(hdc, X_Pointeur, Y_Pointeur)
            PRed = rgb And &HFF
            PGreen = (rgb And &HFF00) / 256
            PBlue = (rgb And &HFF0000) / 65536
            LBL_RVB.Text = Hex(rgb)
            LBL_Rouge.Text = PRed
            LBL_Vert.Text = PGreen
            LBL_Bleu.Text = PBlue
            ' LBL_hdc.Text = Hex(hdc)
            g.ReleaseHdc(hdc)
End Using

Je vais poursuivre les essais demain pour essayer de trouver ce qui cloche.

[electroremy]

Bonjour,

je travaille sur des images BMP mais en les traitant comme un tableau d'octets

en fait je ne charge même pas les images dans des picture box, je lit les fichiers, et, au fil de l'eau, je créé un tableau d'octets

on peut faire tous les tests qu'on veut, de façon très rapide, en utilisation des fonctions alignées sur 4 octets, ou des fonctions rapides comme << ou >> au lieu de divisions

Une solution serait de ne pas utiliser GetPixel mais de travailler "en binaire" sur les données de l'images dans le .bitmap de ton image.

En gros dans la RAM de l'ordi ton image est un tableau d'octet au format bitmap - attention selon le nombre de couleurs de l'affichage (32 bits, 24 bits, 16 bits...) la fonction GetPixel ne sera pas identique !

Cette façon de travailler "en binaire" sera bien plus rapide que de faire de nombreux GetPixels si tu dois faire un traitement sur un gros morceau de l'image ou surtout l'image entière

Pour faire simple, ton image est une liste des octets R, V, B de tous les pixels, de gauche à droite, chaque ligne l'une après l'autre

Il faut faire un calcul pour retrouver, à partir des coordonnées X et Y, le n° de l'octet

Attention il y a un piège, une ligne sera toujours composée d'un nombre d'octets égal à un multiple de 4 (donc il y a "un bourrage" de 0 non significatifs à la fin de la ligne.

Attention également sur les ordinateurs l'axe Y est "inversé" par rapport à un repère scientifique XY orthonormé

A bientôt

[François DORIN]

Comment est déclarée ta fonction GetPixel ?

[Discret68]

Bonjour electroremy

Pour moi, il est impératif de visualiser l'image à l'écran car c'est une photo où se trouvent des étoiles (je fais de l'astronomie !). L'objectif de cette visualisation est de choisir une des étoiles présentes de manière à pouvoir faire la netteté de l'image, en manuel ou en automatique.

La courbe qui résulte du traitement traduit la mise au point. Plus la courbe est étroite et haute, meilleure est la mise au point.

Lorsque je clique sur une étoile (ou très proche de l'étoile), je prends un carré de 20x20pixels. J'analyse chaque pixel (400) dans le but de déterminer le centroïde de l'étoile, c'est à dire le centre ou les pixels sont les plus lumineux. J'utilise donc la fonction GetPixel (400 fois). Une fois que les coordonnées X et Y du centre de l'étoile sont déterminées, je fais une analyse de 20 pixels (10 de part et d'autre du centre) en horizontal puis la même chose en vertical. Là aussi, c'est le GetPixel qui permet de récupérer les valeurs et tracé la courbe.

Une fois l'étoile "verrouillée", on déplace progressivement le dispositif de mise au point qui est motorisé et piloté directement par mon projet pour trouver le meilleur réglage.

Par contre, je retiens ton idée de traitement en "aveugle" car l'idéal serait de pouvoir traiter plusieurs étoiles de manière à avoir une moyenne (ou les extrêmes) et là, les rapidité de calcul pourrait être appréciée.

[electroremy]

Que l'image soit affichée ou non le principe du calcul sans passer par GetPixel est le même, et sera plus rapide

Ton logiciel est raccordé à un reflex ou une caméra couplée sur un télescope avec monture motorisée ?

Si oui, et si ta focale est longue, la rotation de la terre se voit à l’œil nu, il faut déplacer le télescope en temps réel

Avec mon reflex APS-C et un objectif à mirroir de 500 mm (focale équivalente 24-36 de 750mm) je me suis amusé à photographier la dernière éclipse de lune



http://electroremy.free.fr/28092015Eclipse

Je devais réorienter mon appareil toutes les deux minutes

De même regardes du côté du traitement du signal et des FFT en 2D il y a des choses très utiles

Notamment cherche du côté de l'auto-correlation, c'est ce qu'il te faut pour caler une image sur une autre, ou une image sur une "carte" avec la position désirée des étoiles.

[Discret68]

Dans le cadre du projet que je développe, je ne suis pas sur du traitement d'images (il existe suffisamment de logiciels dans ce domaine sur le marché), mais sur du pilotage d'acquisition photo. Dans le domaine de la photographie astro, il existe de nombreuses caméras CCD spécifiques sur le marché qui fonctionnent très bien. Certains APN sont également utilisés (principalement Canon et Nikon). Tous ces appareils sont pilotés via des logiciels standards de photographie astronomique (pointage des objets à photographier, mise au point, suivi dans le temps, correction de position, ...).

Mon projet n'est pas là pour refaire ce qui existe déjà. En ce qui me concerne, Sony a sorti un appareil, le A7S, dont la caractéristique principale est d'avoir des pixels ultra-sensibles. Cela permet de réduire considérablement les temps de pose. C'est un peu comme de passer d'une 2CV à une Ferrari en terme de rapidité.

L'inconvénient majeur, c'est que Sony ne met aucun kit de développement à l'attention des "grands développeurs" de logiciels astro, ce qui fait qu'aucun logiciel actuel n'intègre le pilotage de cet APN. Il n'est donc pas possible d'automatiser les séquences photos avec cet appareil. Tous ceux qui utilisent cet APN "travaillent" essentiellement en manuel. Ils visent un objet à photographier, font la mise au point en manuel et lance une séquence photo (1 à 2h par poses de 30s) à l'aide d'une commande à distance. Pour l'objet suivant, braquage de l'instrument sur l'objet et reprise de la séquence photo.

Ayant acheté cet APN, j'ai décidé de contourner le problème, et de développer moi-même un logiciel de pilotage spécifique dont le rôle principal est de programmer des séquences photos automatisées de plusieurs objets célestes (galaxies, nébuleuses, ...) dans une même nuit. La monture du télescope est pilotée par l'ordinateur et par le biais du logiciel que je développe. Elle réalise le pointage de l'objet selon les coordonnées célestes que je lui envoie, et se charge du suivi de chaque objet pointé (en clair, elle compense la rotation de la Terre). Aujourd'hui, tout fonctionne depuis mon PC de développement qui tourne sous win10.

Par contre, une fonction essentielle ne marche pas sur l'ordinateur qui pilote l'installation et qui fonctionne sous seven, c'est la mise au point, avec l'utilisation du GetPixel. En terme de développement, je dirais que je ne suis pas loin de l'arrivée, mais les derniers mètres semblent impossible à parcourir !

Mon télescope est un newton avec un miroir de 300mm de diamètre et 1200mm de focale. L'équipement complet est proche des 30kg. Ce tube est installé sur une monture équatoriale entièrement pilotée par ordinateur.

Pendant que nous y sommes, voici une copie de l'écran principal du logiciel que je développe :

[electroremy]

Je comprends et je compatis

SONY fait régulièrement du bon matos, avec des fonctionnalités originales, et de bonnes performances

Pour faire de la photo et de la vidéo de concert, j'ai porté mon choix sur les transluscents A33 et A77

Malheureusement SONY ne sait pas gérer le volume sonore de l'enregistrement , et c'est encore pire avec un micro externe

Ce n'est pas faute d'avoir envoyé des tas de message à SONY pendant 6 ans...

Quel dommage d'avoir du matos si bien adapté à la photo et à la vidéo de concert pour l'image MAIS auquel il manque juste... le réglage du volume !

De plus SONY étant un outsider sur le marché de la photo, trouver des accessoires est difficile...

Par exemple la très bonne focale fixe 35mm f1.4 de SIGMA n'existe pas en version ultrasonic pour SONY

On va dire que SONY est le Apple de la photo : matos et logiciels fermés !

Revenons à ton problème : tu veux automatiser la MAP et le déclenchement.

Pour la MAP je suppose que ton soft pilote un moteur qui ajuste une bague sur l'objectif ou le téléscope (ton appareil est probablement monté en direct sur le télescope, le téléscope étant un super télé-objectif) ?

On considère généralement que tous les objets célèstes sont, du point de vue photo, à l'infini, donc la MAP peut se faire pour toute l'image

Ton système est en fait, du point de vue traitement de signal, un régulateur dont la consigne est "image la plus nette possible"

Sauf que ton signal est un peu spécial : c'est le facteur de netteté d'une image 2D !

Je pense qu'il faut calculer la dérivée première ou seconde de toute l'image, puis faire une moyenne pondérée, et maximiser ce signal

Compte tenu de l'inertie mécanique et du temps de traitement, la MAP se fera par approximations successives de plus en plus fines, il faut un filtre PID ou quelque chose dans le genre.

Une difficulté sera, au début de l’algorithme, de trouver dans quel sens corriger la MAP.
En gros :
- image de départ
- mesure netteté N1
- on avance de 100
- mesure netteté N2
- si N2 mieux que N1 alors continuer à avancer
- sinon, essayer en reculant de 50

Ton projet est passionnant, et si les gens de SONY était plus "ouverts" ils pourraient acheter ton programme ou au moins te faciliter la vie en te donnant un SDK

S'il avaient écouté ma requête de demande de réglage de volume, SONY aurait vendu énormément d'appareils à tous les photographes de concerts, mais non...

A bientôt

[Discret68]

Développeurs du soir, bonsoir

On va dire que SONY est le Apple de la photo : matos et logiciels fermés !

C'est tout à fait ça, mais on éprouve quand même un certain plaisir à utiliser ce genre d'équipement.

Pour la MAP je suppose que ton soft pilote un moteur qui ajuste une bague sur l'objectif ou le téléscope (ton appareil est probablement monté en direct sur le télescope, le téléscope étant un super télé-objectif) ?

Exactement. Le télescope est à considérer comme un objectif photo, mais de plus grande taille. Sur le télescope, il y a un système de mise au point motorisé (on appelle ce genre d'accessoire un focuser). Un moteur pas à pas piloté par une raquette ou par l'ordinateur permet d'effectuer la mise au point.

Vu la distance qui nous sépare des objets célestes, ils sont tous couverts par le même point de focalisation. Que ça soit pour la lune qui est à environ 385000 km comme pour les galaxies qui se trouvent à des millions d'années lumières. D'un coté, ça simplifie les choses.

Les logiciels du marché proposent des solutions de mise au point automatisées. D'une manière générale, les logiciels effectuent ce qu'on appelle couramment une courbe en V. En astronomie, on mesure la netteté d'une étoile en calculant la FWHM ou la HFD. Ce sont des abréviations anglaises pour lesquelles je ne vais pas expliquer en détails, mais qui consistent globalement à mesurer, comme sur ma courbe en haut à droite, un rapport entre la largeur de la courbe à mi-hauteur, et la hauteur de la courbe de luminosité.

En terme simple, plus la valeur de FWHM est faible, meilleure est la focalisation.

Un petit exemple : supposons un focuser qui a une course de 30mm et qui est mis en rotation par un moteur pas à pas qui nous donne 10000 pas pour l'ensemble de la course. Pour établir la mise au point auto, on ne part pas de n'importe quelle position. Il faut être assez proche de la zone de focalisation. Disons que notre focuser se trouve à la position 6000 pas du moteur pas à pas. Pour faire ce qu'on appelle une courbe en V, on va par exemple réaliser 11 points de mesure avec une position décalée du focuser de 30 pas par point de mesure, soit 10 intervalles. Les 11 points de mesure vont être répartis pour moitié de part et d'autre du point de départ. Dans notre exemple, on va placer le focuser à la cote 6150 (5 intervalles de 30 pas), le logiciel prend une photo et détermine la FWHM de l'étoile. Vu que nous sommes certainement moins bien focalisé qu'au point de départ, la FWHM est supérieure à celle du point initial. On décale le focuser de 30 pas pour arriver à la cote 6120 pas. Le logiciel reprend une photo et mesure la FWHM de notre étoile. Vu qu'on se rapproche du point de focalisation idéal, la FWHM diminue. On continue ainsi le cycle jusqu'à la cote 5850 pas. Dans toute cette séquence, au fur est à mesure que le focuser se déplace, la FWHM diminue puis remonte à partir du moment où on dépasse le focus idéal. Lorsqu'on regarde la courbe qui est tracée, elle ressemble à un V, d'où son nom. On calcul la dérivée des 2 pentes et le point de croisement des 2 droites donne le meilleur point de focalisation.

Le focuser est placé à cette cote et on lance la séquence photo.

Dans le meilleur des mondes, on pourrait s'arrêter là. Or, vu les variations de la température qu'on rencontre dans une nuit (en général une baisse progressive de la température), les équipements se contractent, et le focus se dérègle. Il faut donc reprendre périodiquement la focalisation du système, sinon, les photos deviennent floues.

Il y a plusieurs parades à ce genre de problèmes :

• Lancer une séquence de focalisation toutes les X photos, de manière à reprendre le focus.
• Utiliser des matériaux à très faible coefficient de dilatation. Le tube de mon télescope est en fibre de carbone, qui a un coefficient de dilatation nettement inférieur à l'acier ou l'aluminium. Les reprises de focalisation sont extrêmement faibles sur une nuit.
• Les "bons" focuser sont équipés d'une mesure de température. Il suffit de faire des relevés du point de focalisation à différentes températures, et on détermine le coefficient de correction en nombre de pas moteur par degré. Le logiciel de pilotage repositionne régulièrement le focuser à la bonne cote de focalisation en fonction de la température ambiante

.

Je pense qu'il faut calculer la dérivée première ou seconde de toute l'image, puis faire une moyenne pondérée, et maximiser ce signal

Tu peux développer un peu car ton point de vue est intéressant, mais je ne vois pas à quelle dérivée tu fais référence. De quelle mesures faudrait-il partir pour calculer cette dérivée ?

si les gens de SONY était plus "ouverts" ils pourraient acheter ton programme ou au moins te faciliter la vie en te donnant un SDK

Si Sony produisait un SDK pour ce type d'appareil, tous les logiciels d'imagerie astro l'auraient pris en compte et je ne m'evertuerais pas à développer mon propre logiciel.

S'il avaient écouté ma requête de demande de réglage de volume, SONY aurait vendu énormément d'appareils à tous les photographes de concerts, mais non...

Les gens de chez Sony sont assez réputés pour n'écouter qu'eux-mêmes.

Ce qu'il y a de bien dans le domaine de l'astronomie pilotée par ordinateur, c'est qu'il y a un protocole de communication standard entre les équipements. Et là, le SDK est disponible, ce qui fait qu'il est facile de piloter les équipements en VB.NET ou en C#.

En tout cas, je n'ai pas beaucoup progressé dans la résolution de mon problème de GetPixel et tant que ça ne fonctionne pas sur l'ordi (sous seven) qui gère le télescope, je ne peux pas faire les tests de focalisation automatique en réel.

Pour finir, une petite photo de mon équipement. On voit en haut à droite, la caméra CCD (qui est en cours de remplacement par le Sony A7S) et juste à gauche, en rouge et contre le tube, le focuser avec sont moteur pas à pas.


A+

[electroremy]

Salut,

Je vois que c'est du sérieux !

Tu as même protégé ton matériel du vent et fait en sorte que tu soit au chaud avec tes ordis tandis que ton téléscope est dehors

Le capteur de température c'est pas bête du tout... pas mal de kits Elektor ou autres permettent de faire des mesures de t° via USB, il doit même exister des kits tous faits, tu peux récupérer la valeur de la température et la gérer depuis le soft. Il est même judicieux de mesure la température en plusieurs points.

Après avoir recueillis assez de données (variation de la MAP et de la température) il est facile de trouver la relation mathématique liant la MAP et la t°
En gros, en fonction de la température, tu corriges / adaptes les paramètres de ton algo de mise au point qui sera ainsi plus performant. Ta mise au point auto tiendra compte à la fois du contraste de ton image et de la température.

Pour en revenir à nos moutons, à savoir le traitement d'image, voici quelques infos utiles :

A peu près tout ce que je sais sur le travail "en octets" avec les bitmaps ce trouve dans ce post :
https://www.developpez.net/forums/d1...t/#post7792865
Dans ce post il y a une classe permettant de travailler avec des BMP de 1 à 24 bits, cela pourra t'être utile

Concernant le traitement d'image et les histoires calcul pour la mise au point :
Malheureusement le sujet est assez ardu mathématiquement...
Plusieurs méthodes existent... mais puisque tu analyses l'image et que tu n'as pas accès au firmware tu ne peux utiliser que le contraste, dommage car les appareils photos utilisent en interne des méthodes plus performantes (télémétrie, détection de phase, ...)
On peut chercher à maximiser le constraste :
- soit en calculant le constraste global qui est la somme des contrastes locaux
- soit en analysant l'histogramme (un image nette a un histogramme avec plus de pixels aux extrémités et moins au centre)

Ci-dessous quelques docs intéressants :
- http://hautiere.nicolas.free.fr/pdf/...tiere-ts06.pdf
- https://hal.archives-ouvertes.fr/cel...868v4/document
- https://www.lri.fr/~mbl/ENS/IG2/cour...mentImages.pdf
- http://www.edgar-bonet.org/physique/af/
- https://perso-sdt.univ-brest.fr/~del...s4_TraitImage/
desvignesgretsi03.pdf

Une petite remarque : pour la mise au point travailles en niveau de gris, cela fait 3 fois moins de données à traiter.
Concrétement ta capture d'image sera convertie en une deuxième image en niveaux de gris sur laquelle tu travailles.
Mieux : ta conversion en niveaux de gris peut être "intelligente" en éliminant les couleurs diffuses ; par exemple si ton ciel a un fond diffus dans le rouge ou l'infrarouge (je suppose que tu as du retirer le filtre passe haut du capteur de ton appareil photo), construit ton image en niveau de gris en ne prenant que les composants bleues et vert. Ton contraste sera meilleur.

Enfin, la référence (en anglais) sur tout ce qui est graphique : http://www.faqs.org/faqs/graphics/algorithms-faq/

A bientôt

[Discret68]

Bonsoir à tous

@ electoremy : Désolé pour ma réponse tardive mais j'étais absent ces derniers jours. Je vais regarder de près les liens que tu as mis.

Sinon, j'ai à peine progressé dans la résolution de mon problème de GetPixel.

En fait, j'ai réceptionné un nouvel ordinateur sur lequel est installé Windows10 64 bits (comme celui qui me sert au développement). J'ai installé Visual Basic 2010 Express et transféré mon projet complet.

Sur ce PC, mon projet fonctionne et la fonction GetPixel répond normalement. Aucun problème !!!

Donc, aujourd'hui, ce que je peux dire, c'est que sur les 2 PC équipés Windows10, la fonction GetPixel fonctionne. Par contre, sur les 2 équipés Seven et celui avec XP, ça ne fonctionne pas !!!

Quelqu'un a t'il une idée de ce qui pourrait bien se passer avec les différentes versions de Windows ?

[François DORIN]

Je repose la question qui est donc passée à la trappe

Comment est déclarée ta fonction GetPixel ?

[Discret68]

Je repose la question qui est donc passée à la trappe

Comment est déclarée ta fonction GetPixel ?

Bonjour François

Désolé de ne pas avoir répondu à cette question que j'avais pourtant bien vu, mais que je croyais destinée à eletroremy suite à sa proposition de travailler l'image comme un tableau d'octets.

Pour répondre à ta question, voici le code :

Code :

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

    Private Declare Function GetPixel Lib "gdi32" Alias "GetPixel" (ByVal hdc As Int32, ByVal x As Int32, ByVal y As Int32) As Int32

Pour mémoire, tous mes ordis ont un système d'exploitation 64 bits, mais il est fort possible que quelqu'un utilise mon projet sur un système 32 bits.

Par rapport au bout de code que j'évoquais le 05/04 à 23h56 et pour lequel je disais que j'obtenais des valeurs incohérentes, je pense avoir trouvé la raison. Au lieu de faire les essais avec une image lambda, j'ai créé une mire, une image qui contient des carrés de couleurs pures (R, V et B) ainsi de des carrés avec des mélanges de couleurs de base (R+V, R+B, V+B, ...).

Promener le pointeur sur cette mire m'a permis de comprendre que les coordonnées du pointeur de souris sur mon image et les coordonnées du GetPixel sont décalées.

En clair, lorsqu'on regarde la copie écran que j'ai posté avec mon premier message, l'image que j'affiche peut être affectée d'un facteur de réduction, de manière à pouvoir être visualisée en entier (facteur à 25% et pas d'ascenseurs) ou à l'échelle 1 (facteur à 100% et apparition des ascenseurs). Lorsque je déplace les ascenseurs, les coordonnées du GetPixel ne correspondent plus avec les coordonnées du pointeur sur la zone ou apparait l'image.

Avec une image vue en entier (facteur à 25%), le GetPixel renvoie de bonnes valeurs sur toute la zone. Lorsque je passe à un facteur supérieur, le Getpixel renvoie de bonnes valeurs tant que les ascenseurs restent à zéro. Dès que je déplace un ascenseur, l'image se déplace bien, mais je vois que les valeurs renvoyées par le GetPixel ne correspondent pas à la position du pointeur mais à une position décalée de l'image correspondant au décalage de l'ascenseur.

Avec l'ancienne formule de GetPixel, je n'avais pas ce problème ! Quel que soit le déplacement de l'image à l'aide des ascenseurs, je récupérais bien la valeur du pixel situé sous le pointeur.

Alors, est-ce qu'au fil des modifications, des essais et des retours en arrière, j'aurais perdu une correction de position ? Je suis quand même assez étonné et je n'y crois pas trop.

Ou alors, y'aurait-il un comportement différent au niveau des coordonnées X et Y entre les différentes formulations du GetPixel ? Je vais continuer à me remuer les méninges pour résoudre ce problème.

Il faudra peut-être que j'intègre la position relative des ascenseurs pour corriger les coordonnées du GetPixel par rapport aux coordonnées du pointeur !

A suivre ....

[François DORIN]

Code :

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

    Private Declare Function GetPixel Lib "gdi32" Alias "GetPixel" (ByVal hdc As Int32, ByVal x As Int32, ByVal y As Int32) As Int32

Code :

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

Private Declare Function GetPixel Lib "gdi32" Alias "GetPixel" (ByVal hdc As IntPtr, ByVal x As Int32, ByVal y As Int32) As Int32

Modifie la déclaration de la fonction comme ci-dessus. Car en 64 bits, IntPtr, qui représente un pointeur, est sur 64 bits et non 32 !!! Du coup, cela peut faire que tu aies un comportement inattendue puisque le paramètre hdc peut être "tronqué".

Pour l'instant, je ne suis que sur le problème du ça marche sur un PC et pas sur un autre. Le deuxième soucis que tu abordes, c'est un problème d'algorithmie, qui est indépendant du premier

[electroremy]

Bonsoir,

oui c'est vrai il faut faire attention avec les types de données :

Integer était sur 16 bits avant et maintenant c'est 32 bits
Long était sur 32 bits avant et maintenant c'est 64 bits

Les déclarations Int32 / UInt32 sont nettement préférables !

Si ton programme est gourmand en ressources ça vaut le coup de faire une version 64 bits et une version 32 bits. La version 64 bits sera plus rapide sur les PC 64 bits (avec un de mes programmes je gagne presque 30% de temps d’exécution en moins). Pour cela passe à Visual Studio 2015 Community Edition.

Ensuite je vois un gros soucis avec ton utilisation de GetPixel : tu travailles sur l'image affichée (réduite) et pas sur les données originales

Tu perd énormément en précision

Pire : sur les écrans LCD des ordinateurs modernes, les pilotes peuvent adapter les couleurs des pixels pour améliorer l'antialiasing... Bref une image affichée est une image dégradée.

Voilà une raison de plus pour travailler sur l'image brute venant de ton appareil photo et pas sur l'image affichée

A la limite ton logiciel pourrait fonctionner et faire la mise au point sans affichage (l'affichage serait alors juste une option)

A bientôt

[Discret68]

Bonjour François

Code :

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

Private Declare Function GetPixel Lib "gdi32" Alias "GetPixel" (ByVal hdc As IntPtr, ByVal x As Int32, ByVal y As Int32) As Int32

Modifie la déclaration de la fonction comme ci-dessus. Car en 64 bits, IntPtr, qui représente un pointeur, est sur 64 bits et non 32 !!! Du coup, cela peut faire que tu aies un comportement inattendue puisque le paramètre hdc peut être "tronqué".

J'ai effectué la modification mais il n'y a aucune différence de fonctionnement.... Ca fonctionne ! Le problème actuel semble se réduire à la différence de coordonnées entre pointeur et GetPixel.

[CODE]Pour l'instant, je ne suis que sur le problème du ça marche sur un PC et pas sur un autre. Le deuxième soucis que tu abordes, c'est un problème d'algorithmie, qui est indépendant du premier

Tout à fait. Je m'étonne juste de l'apparition de ce dommage collatéral. C'est effectivement un "simple" problème d'algorithme que vais traiter rapidement.

Je vais faire de nouveaux tests sur d'autres ordinateurs pour confirmer le bon fonctionnement de la formulation actuelle.

Petite question annexe : que représente concrètement le paramètre "hdc" ? Lorsque j'ai rédigé un petit projet de test pour la fonction GetPixel avec ma mire et ses carrés de couleur, j'ai affiché la valeur de ce paramètre hdc lorsque mon pointeur survole l'image. Je constate à la fois une valeur qui évolue mais qui reste stable sur certaines zones de l'image. De plus, la valeur restituée ne m'évoque rien.

J'ai consulté la description de cette fonction sur le site msn.Microsoft mais ce n'est pas plus clair.

[Discret68]

Bonjour electroremy

Bonsoir,

Ensuite je vois un gros soucis avec ton utilisation de GetPixel : tu travailles sur l'image affichée (réduite) et pas sur les données originales

Tu perd énormément en précision

Pire : sur les écrans LCD des ordinateurs modernes, les pilotes peuvent adapter les couleurs des pixels pour améliorer l'antialiasing... Bref une image affichée est une image dégradée.

Voilà une raison de plus pour travailler sur l'image brute venant de ton appareil photo et pas sur l'image affichée

A la limite ton logiciel pourrait fonctionner et faire la mise au point sans affichage (l'affichage serait alors juste une option)

A bientôt

Tu as certainement raison. Néanmoins, compte-tenu de mes connaissances actuelles en développement, il faut que je procède par étape pour éviter d'avoir plusieurs problèmes à traiter en parallèle. Je ne ferais que m'enliser !

Il faut que j'arrive à faire fonctionner le processus complet de focalisation automatique, même si le résultat n'est pas optimal coté GetPixel. Maintenant que cette fonction semble fonctionner, il faut que finalise le processus avec tests en situation réelle d'acquisition photo. De plus, il me reste quelques fonctions à intégrer dans on projet.

Après, je pourrai effectivement travailler plus en profondeur le traitement de l'image en mémoire.

Autre difficulté (relative) que je rencontre actuellement, et qui concerne directement le format image, c'est que pour pouvoir la traiter, je récupère un jpg alors que le format de meilleure qualité disponible est le raw. Mais pour le moment, je n'ai pas réussi à décrypter et afficher le format raw de chez Sony. Donc, effectivement, j'empile les dégradations de l'image dans mon processus ! mais bon, je fais avec les moyens du bord.

Le format raw est néanmoins utilisé pour les séquences d'acquisition des objets célestes. Là, pas de soucis, le logiciel de traitement image spécifique astronomie prend en compte le format raw Sony.

A+
JP

[François DORIN]

J'ai effectué la modification mais il n'y a aucune différence de fonctionnement.... Ca fonctionne !

Et sur les machines où cela ne fonctionnait pas ?

Petite question annexe : que représente concrètement le paramètre "hdc" ? Lorsque j'ai rédigé un petit projet de test pour la fonction GetPixel avec ma mire et ses carrés de couleur, j'ai affiché la valeur de ce paramètre hdc lorsque mon pointeur survole l'image. Je constate à la fois une valeur qui évolue mais qui reste stable sur certaines zones de l'image. De plus, la valeur restituée ne m'évoque rien.

J'ai consulté la description de cette fonction sur le site msn.Microsoft mais ce n'est pas plus clair.

Il faut voir le paramètre hdc comme un pointeur (d'ailleur hdc = Handle Device Contexte si ma mémoire est bonne). Donc si tu affiches la valeur du paramètre, tu affiches une adresse mémoire. Il est donc normal que la valeur en elle-même ne te parle pas. Par contre, cela devrait rester stable pour une image donnée. Ce n'est pas normal que la valeur bouge, car pour récupérer un HDC, tu ne précises que l'image, pas les coordonnées !

[Discret68]

J'ai testé sur les 2 PC avec seven sur lesquels ça ne fonctionnait pas et maintenant, ça fonctionne sur les 2.

Je vais essayer unpeu plus tard sur un PC XP pour voir ce que ça donne.

Concernant la valeur de hdc, je confirme que la valeur varie constamment en fonction de la position du curseur. J'ai fait l'essai sur 2 PC (seven et win10) et valeur varie d'un pixel à l'autre.

J'avais vu sur le site msdn.Microsoft que le hdc est un handle, mais comme la valeur variait sans cesse, je ne comprenais pas le fondement de cette valeur qui, comme tu le dis, devrait rester fixe.

Encore une bizarrerie !

A+
JP