mala05

Membre
  • Compteur de contenus

    573
  • Inscription

  • Dernière visite

  • Last Connexion

    Soon available - 49925

Messages posté(e)s par mala05


  1. Attention à la densité 3,8 avec un 5D. Ne surtout pas mettre l’œil dans l’œilleton du reflex: danger pour la rétine. Réglage uniquement avec l'écran ou mieux un PC en déporté pour le confort.

     

    Il y a 22 heures, boss351 a dit :

    mon boitier est un 5D markII non défiltré avec un objectif  canon 300 f/d4 +extender *2 . Je fais les essaies pour une utilisation lors de l'eclipse de soleil du 8 avril . Du fait que le boitier est non défiltré il ne doit pas passer grand chose avec 700nm non ? Peut on espèrer gagner un peu en netteté avec un filtre UV/IR cut  par rapport a un simple UV? 

     

    Si l'appareil n'est pas défiltré, il filtre déjà les UV et IR.

    • J'aime 1

  2. Il y a 2 heures, Olivier Meeckers a dit :

    Restons rationnels et objectifs  : 

     

    Lunette de 80mm => PS = 1,5"

    Le calcul du pouvoir séparateur ne tient pas compte du contraste. Ce n'est qu'un indicateur et en rien une limite absolue. L’œil peut percevoir un fil électrique sur un ciel bleu à plusieurs kilomètre alors que cela dépasse de très loin son pouvoir séparateur.

     

    Il y a 2 heures, Olivier Meeckers a dit :

    Or, sur ton image, un seul pixel couvre 4x la largeur de la faille dans Vallis Alpes! Tu ne crois pas qu'il y a un petit problème pour envisager une détection potentielle?

    Un bon objectif de 70mm permet de détecter des failles lunaire telles que Triesnecker sans aucune ambiguïté. La rainure dans la vallée des Alpes, pour peu d'avoir un éclairage légèrement rasant, cela passe sans problème. La photo de lyl détecte bien des parties de la faille sans ambiguïté à mon sens.

    • J'aime 2

  3. il y a 38 minutes, gehelem a dit :

    ce qui me soucie vraiment et que je répète encore, c'est que soupçonne la méthode de calcul du subpixel d'être à coté de la plaque : 

    j'ai une oscillation très présente, très régulière, bien constante, dont la fréquence semble bien correspondre au passage d'un pixel entier à l'autre.

    J'ai aussi des réserves sur la précision de cette technique. Cela me fait penser à l'amélioration que j'avais apporté sur le bibliothèque arduinoFFT à l'époque...

    https://github.com/kosme/arduinoFFT/issues/41

     

    Pour l'estimation des pics de fréquence, je reconstruisais une parabole sur la base de 3 points...

    72839447-9cb1a100-3c92-11ea-9c33-6e8e61886db0.jpg

    Le gain était notable mais ce n'est pas parfait.


  4. Il y a 11 heures, gehelem a dit :

    Sur la compensation j'ai aussi un peu de mal, je pense qu'il il faudrait que je mette en place un PID...

    Oui en boucle fermée un PID c'est encore ce qu'il y a de plus simple à mettre en place et à tester. Sur mon premier proto, j'étais parti sur une régulation adaptative mais c'est plus complexe à mettre en œuvre.

     

    Pour le CD tu voudrais en faire ta mire ou c'est juste pour tester en visuel? j'ai peur que la régularité du pattern des pistes puissent poser plus de problèmes qu'autre chose par rapport à tes anciennes mires non?


  5. Il y a 1 heure, gehelem a dit :

    Pfff

    Suis pas loin du découragement 

    Je patauge et je vous enquiquine avec des trucs qui semblent simples, à un moment il faut savoir dire qu'on est une buse...

    Je vais continuer ce WE, mais après ça rejoindra l'immense tiroir des tentatives de bidouilles avortées.

    Besoin de dormir un peu...

    Cyrille me rependra si j'ai pas bien suivi mais au moment où tu bascules de mire tu appliques le delta de position entre les deux mires à tes nouvelles mesures pour ne pas décrocher et ainsi de suite.


  6. Le 10/11/2023 à 09:51, gehelem a dit :

    e suis passé à la même étape que toi @mala05 : un petit soft pour gérer en direct parce qu'avec excel/OO c'est galère

    En OpenCV, j'ai testé CvPlot. C'est basique mais ça fonctionne...

     

    il faut que je teste OpenCVGUI qui intègre également des graphiques et permet d'aller bien plus loin avec notamment des éléments d'interface  (boutons, checkbox, etc). Cela a l'air pas mal.


  7. Je reprends un peu ce soir.

    Le 06/11/2023 à 09:46, Cyrille Thieullet a dit :

    Il y a une image de référence (m_matReference) et celle en cours (m_matCapture)

    Quand le delta de position entre les deux est > à 2/3 en X, la capture courante devient la capture de référence.

     

    Ca permet de faire la mesure n'importe où car il est possible de calculer le delta entre de portions d'images.

    Une clôture à 20m c'est parfait, le mur d'en face depuis un balcon aussi.

     

    Cyrille

    Merci Cyrille. Oui je connais. J'utilisais matchTemplate() sur un logiciel de HDR pour recaler la perspective sur des bracketing à main levée. Dans ce cas cela suffisait mais cela m'interpelle un peu en terme de précision pour une mesure d'EP. Il y a intérêt d'être sacrément suréchantillonné pour obtenir une précision correcte non?

     

    Le 06/11/2023 à 13:22, Cyrille Thieullet a dit :

    Très intéressant ça! Il faudra que je teste aussi à l'occasion. :)

     

    Il y a 3 heures, gehelem a dit :

    Donc @mala05 je vais probablement arrêter de polluer ton fil et je vais aller implémenter tout ça proprement dans mon "observatoire sans tête" en face.

    Au passage merci encore pour le regain de motivation, ça tue ce truc.

    Vas-y pollue on s'en fou! :D Tu nous fais un retour de tes tests dans l'observatoire? Enfin le jour où on revoit un peu de ciel bleu. En ce moment c'est pas gagné. xD

     

    Moi de mon côté, j'ai mis un peu le code de mon analyseur d'EP au propre et je commence à intégrer les graphiques à la volée pour remplacer Excel. En l'état c'est très bon niveau précision des mesures. Pour estimer le bruit résiduel, je me suis amusé hier soir à analyser la variation de la distance moyenne entre les fausses étoiles. Mon échantillonnage étant quasi de 1pix/",  on est largement en subpixel comme le montre ce graph sur un peu plus d'une vingtaine de secondes. Je pense que les quelques pics sont même liés à des légères turbulences lors des mesures dans la cave...

    654d5d748f939_Capturedecran2023-11-09a23_18_42.thumb.jpg.fd62dbb13f26725d4dd2ae7977ad61f1.jpg

     

    Je vais voir pour intégrer le pilotage de l'ASI dans le soft comme ça je pourrai vraiment faire des tests en temps réel et plus traiter des png après coup.

     

     

    • Merci 1

  8. Il y a 11 heures, fedele a dit :

    Yes..is very good. but probably the Mewlon210, will give me more dettailed  stacked images that need less processing and with more contrast
    Also i will have a best telesocpe for viewing planets. 
    To be clear i m yet happy with my C8Edge. But i want something that show me what i see in my TSA120 but sitting comfortably on a chair

    In that case, I think a C11 or a Mewlon 250 would be a better option. I doubt that the Mewlon 210 could make a big enough improvement.

    • J'aime 2
    • Triste 2

  9. Le 25/10/2023 à 08:57, Pascal C03 a dit :
    Le 23/10/2023 à 18:44, mala05 a dit :

    Mais c'était sans compter sur le défaut de précision du montage de l'encodeur sur la vis sans fin

     

    Si j'ai bien tout compris, il y a une erreur de principe dans cette solution. Tu vérifies la vitesse de rotation de la VSF... Celle-ci est fonction de la chaine cinématique en amont de la VSF. Mais tu ne prends pas en compte le défaut de faux rond de la vis qui induit au 1er ordre l'EP sur la roue...

    Cela ne correspond au graphique publié ici. En fait je ne pouvais pas prendre en compte le défaut de montage de l'encodeur sur l'axe de la vis sans fin. La fameuse banane que tu évoque ensuite. Pour les premiers essais j'avais été contraint de faire une rallonge en impression 3D pour pouvoir positionner la roue codeuse car son axe était trop court. Et avec les coutures d'impression ce n'était pas assez précis. Il va falloir que je vois pour faire fabriquer une petite rallonge en usinage. J'avais laissé ça en plan à l'époque. Je vais en profiter pour mettre un nouveau encodeur ABZ pour avoir un zéro sur la position de la vis. Il est dans un carton.

     

    Je rebondis sur le graphique que tu as crayonné. J'ai trouvé d'où vient le décrochage que tu as marqué en violet. Mon PC c'est mis en veille pendant la mesure. Je pensais avoir touché le clavier assez vite mais cela a généré un trou dans les mesures.  J'ai constaté de visu en passant en revue les images dans cette zone.

     

    Le 25/10/2023 à 01:07, gehelem a dit :

    je n'en suis pas certain, tu peux utiliser Stellarsolver sans trianguler quoique ce soit, perso je le trouve très rapide, il faudrait que je teste pour voir s'il est capable d'avaler du 25im/s

    Mais c'était juste pour ramener ma fraise après la bataille, pour faire genre que j'ai pigé la manip...

    Mais tu as bien raison. C'est un outil au demeurant intéressant. :)

     

    Le 25/10/2023 à 01:07, gehelem a dit :

    Et comme ça m'intéresse par ailleurs, est-ce que OpenCV permet de faire du "subpixel" ??

    Oui aucun problème pour les calculs. C'est pour l'affichage qu'il ne gère qu'au pixel près par défaut à ma connaissance. Mais en faisant quelques recherches, cela semble avoir évolué:

    many drawing functions can handle pixel coordinates specified with sub-pixel accuracy. 
    This means that the coordinates can be passed as fixed-point numbers encoded as integers. 
    The number of fractional bits is specified by the shift parameter and the real point coordinates are calculated as 𝙿𝚘𝚒𝚗𝚝(x,y)→𝙿𝚘𝚒𝚗𝚝𝟸𝚏(x∗2−shift,y∗2−shift) . 
    This feature is especially effective when rendering antialiased shapes.

    Source: https://docs.opencv.org/3.4/d6/d6e/group__imgproc__draw.html

     

    Si tu es curieux, voici mon code C++ qui s'occupe de trouver tous les centroïdes d'une image.

    /**
     * @brief Structure pour stocker les informations sur un centroïde.
     *
     * @struct Centroid
     */
    struct Centroid
    {
        double x; ///< Coordonnée X du centroïde.
        double y; ///< Coordonnée Y du centroïde.
        double mass;
        int minX; ///< Bordure gauche de la boîte englobante.
        int maxX; ///< Bordure droite de la boîte englobante.
        int minY; ///< Bordure supérieure de la boîte englobante.
        int maxY; ///< Bordure inférieure de la boîte englobante.
    };
    
    /**
     * @brief Trouve les centroïdes des taches lumineuses dans une image.
     *
     * Cette fonction traite une image pour y détecter des taches lumineuses
     * et détermine la centroïde ainsi que la boîte englobante de chacune.
     *
     * @param image L'image en niveaux de gris à traiter.
     * @param thresholdLevel Le seuil pour la binarisation de l'image.
     * @param margin La marge à ajouter aux boîtes englobantes.
     * @param smoothingPasses Nombre de passes de lissage.
     *
     * @return Une liste des centroïdes détectés.
     */
    vector<Centroid> findLightSpotsCentroids(const Mat &image, int thresholdLevel, int margin, int smoothingPasses)
    {
        // Duplique l'image pour travailler dessus
        Mat blurredImage = image.clone();
        Mat mask;
    
        // Applique un filtre de flou
        // Note: 1 passe: suppression de la matrice Bayer
        for (int i = 0; i < smoothingPasses; i++)
        {
            boxFilter(blurredImage, blurredImage, -1, Size(2, 2));
        }
    
        // Binarise l'image selon le seuil donné
        threshold(blurredImage, mask, thresholdLevel, 255, THRESH_BINARY);
    
        // Trouve les contours dans l'image binarisée
        vector<vector<Point>> contours;
        findContours(mask, contours, RETR_EXTERNAL, CHAIN_APPROX_SIMPLE);
    
        // Parcourt des contours détectés pour extraire les centroïdes
        vector<Centroid> centroids;
        for (const auto &contour : contours)
        {
            int minX = INT_MAX;
            int maxX = -INT_MAX;
            int minY = INT_MAX;
            int maxY = -INT_MAX;
    
            // Extraction de la boite englobante du contour
            cv::Rect boundingBox = cv::boundingRect(contour);
    
            Centroid c;
            c.minX = boundingBox.x - margin;
            c.maxX = boundingBox.x + boundingBox.width + margin;
            c.minY = boundingBox.y - margin;
            c.maxY = boundingBox.y + boundingBox.height + margin;
    
            // Vérifie si la boîte englobante ne touche pas les bords de l'image
            if (c.minX >= 0 && c.minY >= 0 && c.maxX <= image.cols - 1 && c.maxY <= image.rows - 1)
            {
                // Calcul barycentrique
                double totalX = 0.0;
                double totalY = 0.0;
                double totalWeight = 0.0;
                for (int y = c.minY; y < c.maxY; y++)
                {
                    for (int x = c.minX; x < c.maxX; x++)
                    {
                        double weight = static_cast<double>(blurredImage.at<uchar>(y, x));
                        totalX += x * weight;
                        totalY += y * weight;
                        totalWeight += weight;
                    }
                }
    
                // On obtient le centroïde
                c.x = totalX / totalWeight;
                c.y = totalY / totalWeight;
    
                // Ajout du centroïde à la liste
                centroids.push_back(c);
            }
        }
    
        // Trie des centroides par ordre croissant des coordonnées X
        std::sort(centroids.begin(), centroids.end(), [](const Centroid &a, const Centroid &b)
                  { return a.x < b.x; });
    
        return centroids;
    }

    La base pour n'importe quel système de suivi stellaire. ;)

     


  10. Il y a 13 heures, gehelem a dit :

    Passionnant !! je vais suivre ça de près

    Petite suggestion : utiliser Stellarsolver pour détecter tes centroïdes, c'est ce qui est utilisé sur Ekos pour le guidage (entre autres), c'est très simple à utiliser

    Merci gehelem mais cela n'apporterait rien si ce n'est de plomber les performances. Ici on a pas besoin de triangulation et le calcul d'une centroïde est simple à faire avec OpenCV: recherche de contours, on en déduit les boites englobantes et on termine par un simple calcul de barycentre sur les pseudos étoiles.

    2023-09-18-2003_8-CapObj_0252_contours.thumb.jpg.95486e6a69ee9083c7aecbae5e70c77c.jpg

    Et pour ce qui est de "suivre une étoile" d'une image à une autre, il suffit de vérifier les boites englobantes qui se chevauchent comme le mouvement est très lent. :)

     

    Une illustration de ce qu'on peut faire en quelques lignes de code avec OpenCV: https://learnopencv.com/find-center-of-blob-centroid-using-opencv-cpp-python/


  11. Il y a 5 heures, Pascal C03 a dit :

    Tu dois pouvoir avoir une EP sur la distance inter led !? 9_9

    Je ne vois pas bien l'idée. En l'état, je n'exploite pas la distance entre les leds si ce n'est pour déterminer le coefficient d'atténuation en bord d'image lorsqu'elles sortent ou entrent dans le champ. Pour le reste, je me base uniquement sur la vitesse moyenne de déplacement des leds présentes. La distance inter led n'intervient donc quasiment pas.

     

    Il y a 5 heures, Pascal C03 a dit :

    Tu n'es pas loin du tout de mettre en place un système de rétroaction de pilotage des moteurs ? Remplacer les encodeurs par des trucs moins onéreux te parait possible ?

    Si tu te rappelles, j'avais réalisé en 2019 des tests avec un encodeur basse résolution de 1000 lignes (soit 4000 positions) à quelques dizaine d'euros en sortie de vis sans fin...

    D28B6694.jpg

    L'idée est là aussi de partir sur une analyse de la vitesse en temps réel et non de la position absolue comme ils sont utilisés habituellement.

     

    Les premiers résultats étaient très intéressants...

    Capture d’écran 2019-03-10 à 00.19.21.jpg.png

    Mais c'était sans compter sur le défaut de précision du montage de l'encodeur sur la vis sans fin. J'avais fini par laisser le truc en plan en 2019.  Le nouveau système de mesure d'EP à la cave devrait me faciliter le travail pour reprendre où j'en étais.

     

    Le gros avantage que j'y vois, si cela tombe en marche ;), c'est qu'on obtiendrait alors un système PEC capable de s'auto corriger tout seul en amont de la vis sans fin. Et c'est gros plus car les engrenages de démultiplication en amont ne sont pas forcément des sous multiples de la période de la vis sans fin d'AD. Cela les rends quasi impossible à corriger avec un PEC standard.

     

    Bref, il y a de quoi s'amuser. :D

     

    Il y a 5 heures, Pascal C03 a dit :

    ça sent l'agreg en interne ! Tu es prof dans quelle matière ?

    Non, au final après avoir préparé le CAPET en Sciences de l'ingénieur (que j'ai raté 9_9 ), j'ai finalement passé le concours interne d'éco gestion cette année. Mais je te rassure en spécialité informatique... :D

    Aujourd'hui, je suis enseignant de spécialité SLAM (Solutions Logicielles et Applications Métiers) en BTS SIO et je me régale.

    • J'aime 2
    • J'adore 1

  12. Il y a 14 heures, Pascal C03 a dit :

    Les causes doivent se tenir dans les roulements ? Ces bestioles là sont assez mal dimensionnées je trouve pour l'essentiel des montures.

    Bonne remarque pour les roulements. Effectivement, cela doit jouer aussi. Je vais essayer d'isoler les éléments petit à petit.

     

    Il y a 14 heures, Pascal C03 a dit :

    Il te manque une décomposition de Fourier mais ça doit pas être le truc qui te fait peur !

    J'avais déjà commencé à travailler sur le sujet il y a un peu plus de 3 ans avant de mettre en pause l'astro. A l'époque j'avais passé un peu de temps sur l'étude de la bibliothèque arduinoFFT et une grosse amélioration de sa précision dans l'idée de l'intégrer à mon projet. C'est tout à fait exploitable sur le PC également vu que c'est du C++. Je l'avais d'ailleurs déjà adaptée avec une IHM pour valider mes devs avec le concepteur de la bibliothèque...

    72839957-89530580-3c93-11ea-9b79-22201df

     

    Il y a 15 heures, Pascal C03 a dit :

    Ce qui est super dans ta manip est que tu élimines le bruit important crée par la turbulence. Tu as à 95% le comportement mécanique de la monture.

    Oui et là on est vraiment en bout de chaine. Et c'est d'autant plus intéressant que les données peuvent être recoupées avec mon analyseur d'EP de moteur pas à pas que j'avais mis au point déjà en 2017 en montant une mire directement sur l'axe moteur... :)

    d28b3127.jpg

     

    analyseur-de-precision.jpg

     

     

    Il y a 15 heures, Pascal C03 a dit :

    Est-ce qu'un stroboscope aurait pu remplacer tes leds ?

    Je ne sais pas. Intuitivement cela me semblerait ajouter de la complexité là où il n'y a pas lieu d'être. Sans parler du coût. Là on en a pour moins de 5€ avec un bandeau leds sur pile de chez Action.

     

    Sur ce, je retourne un peu à Flutter et Dart pour préparer les TPs de mes élèves! C'est bien beau d'avoir mis l'astro en pause à l'époque pour préparer un concours. Mais maintenant il faut assurer aussi... xD

    • J'aime 1

  13. Je profite du mauvais temps pour reprendre un peu le traitement notamment de la deuxième image prise en seconde partie de nuit. Plus douce encore et avec 75% d'images retenues sur 10x1min contre 25% pour la première version. On ne gagne pas en détails mais je trouve que visuellement on gagne encore en sensation de "réalisme".

    2023-10-14-0114_6-jupiter-mewlon-250-brlw-2x-ad-zwo-ir-cut-red75-sat.png.88419cc342713878140f57a3fc6fe19a.png

    Avec un suréchantillonnage à 0,1"/pix je trouve que ça passe encore bien pour 250mm. Par contre il faut vraiment le ciel qui suive.

    • J'aime 1

  14. Le 20/10/2023 à 23:11, pierrot1674 a dit :

    bonjour a tous

    excelente manip je suis interessé

    sa peut se faire en exterieur avec un laser pointé sur des billes en acier ?

    mala 05 peut on esperer avoir ton logiciel de traitement Merci

    Merci Pierrot. Pour l'instant je n'en suis qu'à l'étape du "proof of concept" bricolé avec des bouts de code en C++ et OpenCV. Le principe reste à affiner. On est loin d'un logiciel sur étagère.

     

    Je ne conceptualise pas très bien ton idée de l'usage d'un laser pointé sur des billes d'acier. A 10m, le télescope se déplace sur la mire d'environ 45cm/10min. C'est pour cela qu'on a besoin d'une bande led avec une multitude de fausses étoiles. Qui plus est Ici l'idée est d'être en intérieur pour limiter au maximum les effets de la turbulence.

     

    Le 21/10/2023 à 06:46, Pascal C03 a dit :

     

    Une fois de plus tu démontres ton génie manipulationnel...

    J'ai fait puis abandonné la collim de mon C11 dans un couloir de l'IUT de 70 m de long avec une étoile artificielle. Abandonné car la meilleure collim est celle que l'on fait sur site avant d'imager.

     

    Je vois une monture AP, l'avez-vous testée pour voir son EP ?

    Pour ta Taka, l'EP est de +/- 20 " d'arc si on interprète l'échelle en ordonnée ?

    Merci Pascal! :) Génie manipulationnel! Rien que ça! xD

     

    Je ne sais pas sur les C11 mais sur les Mewlons 250 la collimation tient bien et l'horizontalité de la manip ne pose pas de problème. Par contre, il faut faire bien attention aux flexions côté bagues allonges. Là on avait des bagues allonges vissantes qui sont vraiment parfaites une fois serrées. On a fait différents essais et pas de soucis de flexion

     

    Sinon on pas encore testé l'AP. Il faut qu'on voit pour l'adaptation de mon 400mm dessus. Je pense que la prochaine étape va être déjà de tester mon moteur de Dec (comme je programme moi même la carte d'asservissement de mes moteurs c'est tout con de switcher les deux moteurs logiciellement). Et l'étape suivante sera je pense de tester ma vieille EM200 comme j'ai la même embase.

     

    Sinon oui tu es dans le bon ordre de grandeur à vue d’œil pour l'EP à +/- 20 " si l'on ne tient pas compte de l'engrange fatigué. Mais je pense qu'il n'est pas le seul. En données constructeur elle est à +/- 10 " et je pense qu'elle les tenait bien à l'époque il y a 25 ans.


  15. Il y a 4 heures, teko38 a dit :

    Superbe trouvaille

    Pas de pb avec les bagues allonges

    Merci teko38. :)

     

    Heureusement qu'on en avait en rab car malgré les 40m il a fallut bien rallonger comme on l’aperçoit sur la photo avec le Mewlon CRS de mon ami. J'avais un peu peur que cela puisse fausser l'alignement mais non ça l'a fait parfaitement. Pour l'Epsilon 180 par cela a été plus simple.

     

    Il y a 4 heures, exaxe17 a dit :

    C'est super ta manipulation ! Merci du partage ! En tout cas ta monture serait parfaite pour les poses courtes et le problème de walking noise!

    Merci exaxe17 :) Oui mais non pour walking noise. On va faire en sorte de corriger ça à terme. xD

     

    Il y a 3 heures, guy03 a dit :

    Et ben je dis chapeau!!! Bravo!

    Merci Guy :)

    • J'aime 2

  16. Il y a 2 heures, polorider a dit :

    Bon alors celle-là je ne l'avais jamais entendue... :D xD    Génial ton montage 9_9

    Merci Polorider! :) Avec la pluie qui tombe en ce moment dans les Alpes mon côté Breton remonte pour palier au temps!  On pas de pétrole mais on a des idées! xD

     

    Il y a 2 heures, ALAING a dit :

    Quelle ingéniosité :x superbe manip :)

    Mais bon encore faut-il avoir une grande cave :)

    Bonnes observations,

    AG

    Tu veux voir encore mieux Alain? :ph34r:

     

    J'ai également dégoté un couloir souterrain de 40m pour tripoter nos gros engins dans le noir avec les copaings...  ^_^

    382978054_699576408261567_2388005282191828340_n.thumb.jpg.51f4c6860c6b29a6b49d9bb3ae184d50.jpg

     

    374950158_1090807512331946_3717986557975530532_n.thumb.jpg.af838f66a6571b204b6bc533e0a6c3a8.jpg

    Température très stable et très peu de turbulence. Le top pour la collimation sur étoile artificielle... :x

    374989689_1298653674188568_7989711810361155482_n.thumb.png.32f4213f24ab9d7bcd33cc09f2bf3e2c.png

     

    Il y a 2 heures, Marc S a dit :

     

    Ingénieux.  Méthode à méditer car ils nous manquent le  "code perso"  d'analyse.¬¬

     

    On ne parlera plus  désormais de voüte celeste étoilée mais bien de cave celeste étoilée. A moins que la cave soit voutée...:D

    Merci Marc. Et oui on innove avec la météo! :P

    • J'aime 4
    • J'adore 4