Journal ISS : le flim

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
59
11
août
2012

Sommaire

Je suis en vacances quelques jours dans le sud, et comme tous les étés, les belles soirées étoilées sont ponctuées par les passages de la Station Spatiale Internationale (AKA ISS) . Muni d'un appareil photo réflexe et d'un téléobjectif puissant, je me suis demandé si c’était suffisant pour lui tirer le portrait.

Le matos

La zoli nimage relevant de la pornographie photographique:

DSLR

C'est donc un Canon EOS 5D Mark II au bout d'un téléobjectif Canon EF 100-400mm 1:4.5-5.6 L IS .

Pour traiter les images, un Mac Book Pro sous Linux GNU/Linux Ubuntu .

Et une connexion internet.

La préparation

Pour savoir quand l'ISS passe au dessus de chez soi, un site indispensable, celui de la Nasa : on choisit son pays, on prend la grande ville la plus proche, et on obtient la liste des passages
de la station dans les jours a venir.

Pour plus de précision, on peut installer XEphem, l'usine a gaz le logiciel a tout faire de l'astronome amateur pour Unix(-likes) (pas libre, mais sources disponibles) ( attention! contient du Motif! ) (si quelqu'un connaît une alternative a ce dinosaure, je prends!) . Le manuel comprend une section expliquant dans le détail comment télécharger les derniers paramètres orbitaux de la station et calculer ses prochains passages, projeter son orbite sur le globe terrestre ou encore afficher sa trajectoire dans le ciel suivant votre localisation.

Trajectoire ISS

Ici la croix jaune représente ma position, la croix bleue la position de la station spatiale, la ligne bleue sa trajectoire. Le plus grand des cercles bleu représente la zone ou la station est visible depuis le sol (quand la croix jaune touche ce cercle bleu, la station pointe a l'horizon). Ce jour la, la trajectoire de la station était particulièrement favorable, celle-ci me passant exactement au dessus.

La cible

La Station Spatiale Internationale est en orbite a 400 kilomètres d'altitude en moyenne (car même a cette altitude il reste une atmosphère résiduelle qui freine la station et la fait lentement retomber, de façon plus ou moins imprévisible. Il faut donc régulièrement la "remonter" , ce que font les différents vaisseaux qui s'y arriment. D’où la nécessité de régulièrement télécharger ses paramètres orbitaux, qui changent sans cesses).

Elle mesure 108.5 mètres de large pour 72.8 de long.

Le shooting

Ceux qui ont déjà assiste a un passage de l'ISS le savent: c'est un objet très lumineux. J'ai donc réglé mon appareil photo de la sorte:

  • ouverture: f/10.0
  • temps d'exposition: 1/500s
  • ISO: 3200

C’était réglé un peu au pifomètre, aux vues des résultats c’était un peu surexposé, j'aurais sans doute mieux fait de baisser les ISO, ce qui aurait limité le bruit (qui est tout de même fort raisonnable sur mon boîtier a ce réglage).

J'ai laisse l'auto-focus branché, décidant qu'il ferait sans doute un meilleur travail que moi, ce qui s'est révélé un bon choix.

J'ai donc photographié en rafale la plus grande partie du passage de 6 minutes de la station, a main levé (vu sa vitesse de déplacement c'est plus simple qu'avec un trépied).

Le traitement des résultats

Je me suis donc retrouvé avec près de 400 images de 5616 sur 3744 pixels avec un tout petit objet très brillant quelque part dedans, pas toujours au centre, comme sur cette image .

J'ai donc écrit un petit script python utilisant la python image library pour détecter le "spot" lumineux dans l'image, et produire une image de 80x60 pixels avec l'ISS bien au centre (après quelques menues optimisations, sur ma machine le script passe encore plus de 8s par images, je laisse comme exercice au lecteur le soin de faire mieux (tout ré-écrire en C n'est pas jouer)).

Titre de l'image

Un petit coup d'ImageMagick par dessus (un tout petit coup en fait, car mes tentatives de corrections ont toutes données des résultats moins lisibles que les images brutes, je me suis donc contenté de les agrandir), puis un coup de mencoder pour produire une video, et voila le résultat final:

Conclusion

C'est petit, c'est flou, c'est moche, ça ondule de partout a cause de la perturbation atmosphérique, mais oui, on peut filmer l'ISS depuis chez soi avec un téléobjectif. On voit bien la forme générale de la station et on distingue les panneaux solaire de couleurs brune de part et d'autre.

Pour ce qui est de la perturbation atmosphérique, je pense qu'on peut trouver de bien meilleurs conditions. En hiver, en altitude, en fin de nuit.

Est-ce que j'aurais obtenu plus de détails en exposant moins? Peut-être. Le prochain passage favorable n'est pas pour tout de suite, je ne sais pas si je pourrais renouveler l’expérience de si tôt.

Pourrais-je grossir plus? Rajouter un doubleur de focale? Je ne sais pas si il sera encore possible de "trouver" la station dans le ciel avec un tel grossissement. De plus un doubleur de qualité coûte le même prix qu'un petit télescope, qui peut grossir beaucoup plus…

En parlant de télescope, d'autres ont fait bien mieux que moi, mais ce ne sont pas les mêmes moyens: https://www.youtube.com/watch?v=nsc80evqJ88

Voila, c'est tout pour cette petite digression, et n'oubliez pas que pendant ce temps, la NASA flash le firmeware de son rover , mais c'est un peu trop loin pour mon téléobjectif…

P.S: il y a des fautes d'orthographe et de grammaire dans ce journal. Il y a aussi quelques anglicismes. Je suis convaincu que tu es capables de toutes les trouver. Cela dit, il est totalement inutile que tu perdes ton temps a poster un commentaire a ce propos: ça ne m'aidera pas a moins en faire. Merci de t'abstenir. Bisou.

  • # Détection du spot dans l'image

    Posté par  . Évalué à 4.

    Très sympa comme expérience!

    Mais photographier à main levé, même au 500ème de seconde, ça me parait risqué… c'était au moins avec le télé appuyé quelque part ?
    Pourquoi ne pas augmenter un peu l'ouverture pour diminuer encore le temps d'exposition ?

    Concernant le petit script python, je suppose qu'on pourrait aller plus vite en faisant la corrélation entre la photo et un "spot" blanc d'une taille proche ( = multiplication dans le domaine de Fourier).

    • [^] # Re: Détection du spot dans l'image

      Posté par  (site web personnel) . Évalué à 6.

      Non le télé appuyé sur rien du tout.
      Faut bien se rendre compte qu'en l’occurrence, la station me passe exactement au dessus de la tête. Même a main levée, j'ai ete oblige de m’interrompre, pivoter a 180 degrés, puis reprendre la rafale (ça se voit dans le flim). En s'appuyant sur quelque chose c'est l'assurance de se retrouve bloqué ou gêné a un moment ou un autre.

      De toute manière, j'ai eu très peu de photos avec du flou de bougé. Le flou vient de la perturbation atmosphérique et que l'objet est quand même très très petit sur l'image. Je ne pense pas que j'aurais eu un meilleur résultat en baissant le temps d'exposition. Je n'ai pas ouvert plus car je n'avais pas super confiance en l'autofocus et je me suis dit que plus je fermais, plus je m'autorisais de marge d'erreur.

      Pour le petit script python, je suis pas un matheux, j'ai fait "low tech" :) . La lenteur vient de ce qu'il faut quand même itérer au moins une fois sur chaque pixel, le reste est insignifiant. Je ne sais pas si ce que tu propose permet d’éviter ça.
      Les solutions auxquelles je pensais évitaient de passer sur l'ensemble de l'image en commençant l'exploration par le centre et en s’arrêtant quand un spot suffisamment lumineux est trouvée, ou commencer l'exploration la ou etait le spot sur l'image précédente, etc.

      • [^] # Re: Détection du spot dans l'image

        Posté par  . Évalué à 3.

        Ok. Concernant le script, le gain de vitesse viendra de la transformée de Fourier que Numpy peut faire.
        La première image de la série (A) peut être récupérée comme image de test pour la corrélation.
        Ensuite, pour chaque image suivante (B), faire:

        Af = fft2(A); Bf = fft2(B);
        // La corrélation dans le domaine de Fourier revient à une multiplication terme à terme par le conjugué complexe de B
        Cf = Af * conj(Bf);
        C = fftshift(ifft2(Cf)); // On repasse dans le temps
        Trouver le max de C, qui est décalé relativement au centre d'une image de la taille de A.

        Il suffit ensuite de faire un crop de la taille désirée autour.

      • [^] # Re: Détection du spot dans l'image

        Posté par  (site web personnel) . Évalué à 2.

        En descendant à f8 tu aura normalement un meilleur piqué, il me semble qu’après f8, tu as des problèmes de diffraction. L'idéal est entre f4 et f8, selon l'objectif.

        Si tu utilises un doubleur, tu as auras juste une image flou plus grande. La résolution optique du zoom ne monte pas avec le doubleur.

        Je tenterais avec un f8 et une baisse des ISO, voir un shoot en "raw" pour faire la retouche après.

        "La première sécurité est la liberté"

      • [^] # Re: Détection du spot dans l'image

        Posté par  . Évalué à 3.

        Je n'ai pas ouvert plus car je n'avais pas super confiance en l'autofocus et je me suis dit que plus je fermais, plus je m'autorisais de marge d'erreur.

        Sur un objet à 300 bornes ta zone de netteté est de toute façon monstrueuse même en ouvrant au max ton télé, f/10 ne te sauve rien du tout. Maintenant pour ce genre de photo, balance moi cet autofocus et fais ta map en manuel au liveview. Ca sera beaucoup plus net, toutes tes photos seront identiques sans raté.

        Pour le 100-400 en bout de range il faut pas le fermer plus que f/11 et le fermer d'un stop de plus que PO est pas une mauvaise idée pour la qualité d'image.

  • # Autofocus ?

    Posté par  (site web personnel) . Évalué à 8.

    Vu la distance tu es toujours en infini pout la mise au point, non?
    A mon avis l'autofocus risque surtout de faire perdre du temps et de la batterie, voire de faire le focus sur autre chose

    • [^] # Re: Autofocus ?

      Posté par  (site web personnel) . Évalué à 3.

      A priori oui, mais je n'en suis pas certain du tout.
      Dans un télescope, quand on observe la Lune, il y a une différence de mise au point selon qu'on regarde au centre de l'astre (plus près de nous) ou la périphérie (plus loin). La on grossit beaucoup moins, mais entre le levée de la station et son passage au plus près, elle passe de 1000km a 400km… Bref, l'auto-focus, c’était la sécurité. Si j'ai l'occasion je testerais sans.
      (et effectivement l'autofocus a parfois "perdu" la station, même s'il n'y avait rien d'autre autour sur lequel faire le focus)

  • # Autre méthode

    Posté par  . Évalué à 10.

    Avec du matos un poil plus coûteux et pas mal de planification, ça donne ça : http://legault.perso.sfr.fr/eclipse101221_lunar_transit.html

    • [^] # Re: Autre méthode

      Posté par  . Évalué à 10.

      Génial…
      Et hop, mon nouveau fond d'écran en attendant une belle photo HD provenant de Mars par Curoisity
      Effectivement, il faut pas mal d'organisation pour par rater le passage de la station.

      Il y a eu des précédents moins réussi :

      truc vert qui vole

      • [^] # Re: Autre méthode

        Posté par  . Évalué à 2.

        Et hop, mon nouveau fond d'écran

        Tu as un écran carré?

        • [^] # Re: Autre méthode

          Posté par  . Évalué à 6.

          Arf, non mon écran n'est pas carré, sa résolution est de 1920x1080.
          Par contre, mon "GNU/Linux prêt pour le desktop" me propose avec KDE 4.9 de pour le positionnement de l'image "Adapté, conserver les proportions", rajoutez à cela une couleur noir en fond et le tour est joué.

    • [^] # Re: Autre méthode

      Posté par  . Évalué à 4.

      ça peut donner ça aussi :

      http://legault.perso.sfr.fr/iss_atlantis_transit.html

      l'iss en transit devant le soleil avec la navette atlantis en phase d'amarrage.

      joli calcul :)

  • # Excellent travail

    Posté par  . Évalué à 4.

    Que dire de plus. Si, j'ai effectivement eu un nœud au cerveau quand j'ai vu la station faire un demi-tour :) Heureusement qu'il y a ton explication après.

    Je ne savais pas non plus que les différents vaisseaux "remontaient" la station régulièrement.

  • # merci

    Posté par  . Évalué à 2.

    je l'ai vu avant hier et je me disais que pour un satellite c’était quand même vachement plus lumineux que d'habitude, souvent les panneaux solaires reflète pas mal mais c'est assez rare, mais la c’était vraiment comme un spot en mouvement.

    Cou de bol je l'ai montré a pas mal de monde, je vais pouvoir leur dire qu'il s'agit de la station spatiale internationale

  • # Compositage ?

    Posté par  . Évalué à 2. Dernière modification le 11 août 2012 à 22:13.

    Tu as essayé de "compositer" tes images en virant les plus mauvaises ? (voir en gardant les 20 meilleures)

    Je suppose qu'il existe des outils pour faire ça sur GNU/Linux.

    Please do not feed the trolls

    • [^] # Re: Compositage ?

      Posté par  (site web personnel) . Évalué à 2.

      Je viens d'essayer avec un autre script maison de compositage, ça ne donne rien, ca ne fait que lisser le flou… Je n'ai pas trouvé d'outils pour faire ca sous Linux, si quelqu'un en connait de bons, je prend…

  • # Alternative à XEphem

    Posté par  . Évalué à 2.

    Est-ce que kstars ne conviendrait pas ? Sinon que lui manquerait-il ?

    • [^] # Re: Alternative à XEphem

      Posté par  . Évalué à 2.

      Oui ou celestia. Après je suis pas sûr que ce soit aussi fiable que les données du site de la NASA…

    • [^] # Re: Alternative à XEphem

      Posté par  (site web personnel) . Évalué à 2.

      Je viens de me battre un bon moment avec kstars, j'ai fini par trouver ou dans la conf "activer" les satellites (et l'ISS en particulier) mais je n'ai pas trouvé comment la faire s'afficher sur la carte du ciel… Donc c'est probablement faisable, mais mon chemin de moindre résistance passe par XEphem pour le moment :)

      ( Celestia est tres joli mais n'est pas fait pour aider un astronome amateur, on aurait aussi pu citer Stelarium … )

    • [^] # Re: Alternative à XEphem

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Perso, j'utilise Gpredict pour l'anticipation du passage couplé avec le plugin satellite de Stellarium pour la visu en temps réel. Les 2 softs téléchargent les TLE automatiquement (après configuration, œuf corse).

  • # Enfin !

    Posté par  . Évalué à 2.

    Ça me rassure de savoir qu'elle existe vraiment ! Ce n'est pas une conspiration gouvernemental de plus :p.
    Maintenant, j'attend avec impatience la personne qui pourra photographier les traces des missions Apollo sur la Lune. Pourquoi est-ce toujours "impossible" à l'heure actuel !? Ça ferai taire ces adeptes du complot….

    Hors sujet: Tiens, je vois que tu as aussi le Nexus S ! Bienvenu au club :)

    • [^] # Re: Enfin !

      Posté par  . Évalué à 7.

      Depuis un satellite d'observation lunaire : http://www.nasa.gov/mission_pages/LRO/multimedia/lroimages/apollosites.html

      Depuis la Terre c'est plus dur, les téléscopes n'ont apparamment pas la résolution suffisante pour voire les trucs laissés sur place (qui sont déjà petits pris avec un satellite fait pour, cf. lien ci-dessus).

      Les gros doivent être optimisés pour voir très loin, et ceux qu'on peut se payer ne doivent pas être assez gros :)

      On a bien un jeu de miroirs sur la lune qui reflète un laser envoyé depuis le Texas et la France, et qui sert à mesurer la distance Terre-Lune (cf. http://physics.nist.gov/News/Update/940718.html), mais si les gens ont décidé de pas croire aux missions sur la Lune, je vois pas ce qui va les convaincre que le laser est réellement reflété par un miroir posé là bas :)

    • [^] # Re: Enfin !

      Posté par  . Évalué à 6.

      Que dalle!

      Regardez ces photos de plus près: on voit clairement que les tâches ne ressemblent pas à une station spatiale, et qu'il s'agit donc d'images produites par ordinateur.

      De plus, tout le monde sait que dans l'espace, il fait noir, et que même si on allume la lumière à l'intérieur de cette hypothétique station, de si loin, ça ne sera pas aussi brillant.

      Et en plus…
      Bon, j'ai plus d'argument pseudo-scientifique foireux, mais je peux l'avoir quand même, mon diplôme de conspirationniste?

      • [^] # Re: Enfin !

        Posté par  (site web personnel) . Évalué à 2.

        Oui et en plus, là aussi y'a un problème avec les ombres !! Décidément, ils ont du mal avec les ombres ! /o\

    • [^] # Re: Enfin !

      Posté par  (site web personnel) . Évalué à 2.

      Justement, d'après wikipedia ils ont bien laissé des traces « visibles » depuis la terre. L'article catadioptre mentionne que quelques uns de ces objets ont été déposés par les missions Apollos. À priori, n'importe qui, équipé d'un bon laser et des talents de viseur appropriés, peu donc vérifier que ces réflecteurs sont bien là.

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

      • [^] # Re: Enfin !

        Posté par  . Évalué à 4.

        Ou alors ce sont les conspirateurs de la NASA qui interceptent tous les rayons lasers qui partent de la Terre vers la Lune et qui les réfléchit avec le bon décalage temporel.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Enfin !

      Posté par  . Évalué à 2.

      Il y a des réflecteurs sur la lune. On peut faire un tir laser dedans depuis quelques (pas mal d'?) observatoires sur terre pour vérifier qu'ils sont bien là bas en admirant la lumière de retour via un téléscope, lumière qui ne serait pas aussi forte si les reflecteurs n'y étaient pas (au delà des calculs, on peut tout simplement contrôler en tirant à côté).

    • [^] # Re: Enfin !

      Posté par  . Évalué à 1.

      Cela faisait très longtemps que je n'avais pas entendu cette histoire.

  • # "On voit bien la forme générale de la station"

    Posté par  . Évalué à 3.

    On dirait un Kirby volant blanc.

    Et lumineux !

    Désolé, il est tard et je vais me coucher.

  • # Un 5d mk II avec un cailloux pareil ? en effet.

    Posté par  . Évalué à 1.

    Un 5D mkII avec un 100-400 série L IS….Pfff tu l'as loué ? Parce que l'ensemble coûte le prix d'une voiture d'occass …
    C' est un plein format tu peux pousser 3200 iso ça ne l'effraie pas lui …. Photo de spectacle ?
    Intéressant, mon 500D (aps-c) avec le 55-250 doit avoir le même rapport de grossissement … pas la même qualité c'est certain, mais ça ce tente …enfin en jpeg pour moi, le buffer vers la carte SD ne tiendra sinon…
    je vais vérifier, mais à F/10 tu dois quand même avoir pas mal de profondeur de champ…autofocus optionnel en ce calant sur l'infini…

    • [^] # Re: Un 5d mk II avec un cailloux pareil ? en effet.

      Posté par  (site web personnel) . Évalué à 7.

      Hum… Comment dire… Je ne conduit pas :)

      Sinon, oui ton 500D t'avantagera pour ce genre d'exercice par rapport a mon 5DmkII, mais pas vraiment pour la raison que tu évoques. En l’occurrence ici, ce qui importe ce n'est pas le rapport de grossissement (qui se rapporte a la différence de surface des capteurs), mais la taille des pixels du capteur, vu qu'on crop au milieu de l'image.

      Si on imagine 2 boitiers hypothétique avec des capteurs de meme densite de pixels, mais l'un full-frame et l'autre APS-C, avec le meme objectif, la photo du full frame aura simplement plus de "contexte" sur les bords, le centre des deux images sera completement superposable.

      Or, (je l'avais lu mais je viens de refaire les calculs), comme les capteurs full-frames sont vraiment énormes et coûtent un bras, les constructeurs mettent de plus gros pixels que dans les capteurs APS-C de meme génération. (comme ton 500D qui est sortit juste apres le 5DmkII).

      Donc le 5DmkII a un capteur de 36x24mm pour une résolution de 5616x3744 pixels, ce qui fait des pixels de 0.0064x0.0064mm ,
      et ton 500D a un capteur de 22.3x14.9mm pour une résolution de 4752x3168 pixels, ce qui fait des pixels de 0.0047x0.0047mm,
      ce qui est effectivement plus intéressant pour le genre d'exercice dont on parle.

      (et paradoxalement, je me rends compte que j'aurais eu meilleur compte a utiliser mon vieux boîtier 400D, qui a tout de meme des pixels de 0.0057x0.0057mm plutot que le 5DmkII :p )

      Bref le seul vrai avantage du full-frame, c'est que comme on a plus de contexte, c'est plus facile de trouver la station et de la maintenir en ligne de mire…

      (surement etais-tu conscient de tout ca en ecrivant ton commentaire mais je me suis dit que ca pouvais en interesser si je detaillais…)

      • [^] # Re: Un 5d mk II avec un cailloux pareil ? en effet.

        Posté par  . Évalué à 1.

        Euh oui, ce que tu dis est exact si j'avais un objectif identique au tien (et dieu sait que j'aimerai bien ;-)).
        Mais j'ai un 55-250 EFS, donc :250*1.6= 400mm (aps-c *1.6= fullframe)… on couvre le même angle, mais tu as plus de pixels sur ce même angle.
        Ton 400D est un aps-c donc la ça donnerait 400*1.6=640 mm, ton angle sera plus petit et donc la station plus grosse sur l'image …mais avec "seulement" 10.1 millions de pixels …
        Enfin un 400d à 3200 isos, je ne suis pas sur …. vaux mieux bosser en RAW. À ma connaissance Canon a fait de gros progrès à partir du 450d…. mais bon dans le cas qui nous occupe le bruit n'est pas forcément un pb..

      • [^] # Re: Un 5d mk II avec un cailloux pareil ? en effet.

        Posté par  (site web personnel) . Évalué à 4.

        Si les pixels sont plus petits, ils sont aussi plus sensible au bruit.

        "La première sécurité est la liberté"

  • # Amélioration du script

    Posté par  . Évalué à 8. Dernière modification le 12 août 2012 à 16:12.

    Je viens de jeter un petit coup d’œil à ton script.
    Ta méthode de détection est simple, concise, efficace, l'idéal quoi. Le seul reproche que je pourrai faire est sur le manque de commentaire explicatifs : on est obligé de se taper tout ton code juste pour comprendre ce que tu cherches à faire.

    Pour ton petit problème de performance, je pense que ça peut venir de 2 choses :
    - une mauvaise utilisation du cache
    - un mauvais choix de la valeur initiale pour LIMIT

    • Utilisation du cache :

    Avec les processeurs actuels, récupérer des données depuis la RAM est bien plus long que les lire depuis le cache (d'un facteur 10 à 20). Dès qu'on travaille avec des données qui risquent de ne pas totalement tenir dans le cache, le meilleur moyen d'avoir de bonnes performances c'est de s'arranger pour utiliser au maximum les données qui y sont déjà présentes avant d'effectuer le prochain chargement depuis la RAM.

    Le cache d'un processeur est de l'ordre de 2 à 4Mo.
    Tes images font 21Mpx, soit environ 60Mo en mémoire.
    Tu peux voir le problème que ça peut poser.

    Ta boucle principale, c'est :

        for x in xrange(W):
        for y in xrange(H):
            acc = sum(data[x+(y*W)])

    Ça veut dire qu'à chaque itération tu te déplaces de W éléments en mémoire.
    Quand on veut parcourir tous les pixels, c'est relativement peu efficace, mais il y a pire : rien que pour accumuler suivant chaque colonne tu fais défiler pratiquement toute ton image en mémoire.
    Au final, comme toute l'image ne peut pas tenir en cache, tu fais la fais charger en entier autant de fois qu'il y a de colonnes. Je te laisse imaginer le nombre de rechargements du cache que tu provoques.

    Je pense que tu pourrais significativement améliorer les performances en échangeant les 2 boucles :

        for y in xrange(H):
        for x in xrange(W):
            acc = sum(data[x+(y*W)])

    De cette manière la boucle ne se déplace que d'un élément à chaque itération.
    Tous les éléments présents dans le cache sont utilisés avant d'avoir besoin de charger depuis la RAM, et l'image entière n'est chargée qu'une seule fois.

    • Valeur initiale LIMIT :

    J'ai vu que si la valeur de LIMIT est trop haute tu recommences tout avec une valeur plus basse. Potentiellement tu peux donc multiplier ton temps d'exécution par un facteur 2 voire 3.
    Est-ce que tu saurais si ça arrive souvent ? Si c'est le cas tu devrais pouvoir baisser voire carrément supprimer cette valeur sans que ça influe trop sur les résultats.

    • [^] # Re: Amélioration du script

      Posté par  (site web personnel) . Évalué à 6.

      Merci pour le commentaire détaillé.

      Le seul reproche que je pourrai faire est sur le manque de commentaire explicatifs : on est obligé de se taper tout ton code juste pour comprendre ce que tu cherches à faire.

      Dire que j'avais justement rajouté des commentaires exprès pour ce journal :')

      Bon j'ai essayé d'inverser l'ordre des boucles, ça améliore marginalement les performances ( < 10% ).

      Par contre j'ai fait une autre optimisation: après la première image, au lieu de parcourir l'ensemble de l'image, je "crop" un zone de 500x500 pixels autour des coordonnées ou se trouvait le spot lumineux a l'image précédente. Si je ne trouve pas, je retourne au cas général d'exploration de l'image entière.

      Ça marche d'enfer: il n'y a plus qu'une dizaine d'image sur les 400 qui tombent dans le cas d'exploration intégrale de l'image, et les autres mettent entre 0.67 et 0.7s pour êtres traites, soit plus de 10 fois mieux…

      le cas ou LIMIT est trop haut est très rare, 1 ou 2 fois sur ce jeu de données, donc "won't fix".

      • [^] # Re: Amélioration du script

        Posté par  . Évalué à 4. Dernière modification le 12 août 2012 à 22:29.

        Il faudrait convertir les données en tableau numpy et faire le traitement sans boucle, en utilisant les facilités de numpy.

        Pour convertir je suis tombé sur ça :
        http://code.activestate.com/recipes/577591-conversion-of-pil-image-and-numpy-array/

        Par exemple, une fois que data est converti en un tableau numpy img :

        for x in xrange(W):
  for y in xrange(H):
    acc = sum(data[x+(y*W)])
    if acc > limit: # filter values according to brightness limit
      X[x] += acc
      Y[y] += acc

# find the brightest column
for x,v in enumerate(X):
  if v > maxX[0]:
    maxX = (v, x)

# find the brightest row
for y,v in enumerate(Y):
  if v > maxY[0]:
    maxY = (v, y)

        peut être habilement remplacé par :

        img_lim = sum(img, axis=2)
img_lim[img_lim <= limit] = 0
X = sum(img_lim, axis=0)
Y = sum(img_lim, axis=1)
maxX = (amax(X), argmax(X))
maxY = (amax(Y), argmax(Y))

        (sauf erreur de ma part)

        Et ça :

        # if no spot brighter than limit, lower limit, recurse
if maxX[0] == 0 or maxY[0] == 0:
  print "[ center not found, lower limit to", limit/2, ']',
  return getCenter(im, limit/2)

        pourrait être testé avant de faire toutes les sommes qui précèdent : il suffit de tester que le pixel maximum soit au-dessus de la limite.

        • [^] # Re: Amélioration du script

          Posté par  (site web personnel) . Évalué à 4.

          Alors moi aussi je mettais de grands espoirs dans numpy mais ne l'ayant jamais utilisé, j’étais resté sur du classique.
          J'ai implémenté ce que tu propose (en partant de la version initiale du script, qui itère sur toute l'image), et la, c'est le drame… 105s de moyenne par image… 10 fois moins bien que la première version! Triste… (les images produits sont identiques aux autres versions, donc il n'y a pas de bug d’implémentation…)

  • # numpy / scipy

    Posté par  . Évalué à 3.

    Pour ce genre de traitement, tu as tout intérêt à utiliser numpy / scipy. Il y a un tuto sympa ici : http://scipy-lectures.github.com/advanced/image_processing/index.html

    # on lit l'image en la convertissant en niveaux de gris
im = scipy.misc.imread('IMG_5858.JPG', flatten=True)

# pour seuiller 
im[im < 100] = 0

# pour récupérer les indices 2D du maximum
np.unravel_index(im.argmax(), im.shape)

    • [^] # Re: numpy / scipy

      Posté par  (site web personnel) . Évalué à 3.

      Yeah! ça marche bien… 2.5s par image!

      (sauf que la dernière ligne fait de la magie noire, même en lisant la doc je ne comprends pas comment ça marche… Et j'ai cru pendant un bon moment que ca ne marchait pas, avant de me rendre compte que ca retournait (Y,X) et pas (X,Y)…)

      • [^] # Re: numpy / scipy

        Posté par  . Évalué à 4.

        argmax renvoie l'indice du max mais en 1D (comme si l'image était un tableau 1D), bien qu'à lire la doc je pensait récupérer directement un indice 2D. Du coup unravel_index permet de calculer l'indice 2D correspondant (en lui donnant la taille du tableau, im.shape).

        J'ai finit par faire une petite fonction qui fait tout et renvoie l'imagette de l'objet (0.68s pour une image contre 14.7 auparavant avec le script et l'image que tu as donné ci-dessus, 1.5s en travaillant sur l'image entière au lieu d'une imagette 100x100): 

        def get_thumb(im, limit):

    # get the 2D indices of the max
    centerX, centerY = np.unravel_index(im.argmax(), im.shape)

    # work on a subimage to speed up things
    window_size = 100
    subim = im[centerX - window_size:centerX + window_size, 
               centerY - window_size:centerY + window_size]

    # threshold
    mask = subim > (0.25*subim.max())

    # get the bouding box
    label_im, nb_labels = scipy.ndimage.label(mask)
    slice_x, slice_y = scipy.ndimage.find_objects(label_im==1)[0]

    return subim[slice_x, slice_y]

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.