Kaidan

Membre
  • Content Count

    2,544
  • Joined

  • Last visited

About Kaidan

  • Rank
    Banni

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Kaidan

    Confidentialité / Sécurité

    Le message envoyé par WA est loin d'être très clair donc. Ce message est de plus dans ma boîte de réception des messages ... De plus, cette "fonctionnalité" est probablement mal comprise quand on voit la teneur des autres messages d'autres personnes qui remontent ...
  2. Kaidan

    Confidentialité / Sécurité

    Bonjour, Depuis la mise à jour du site, j'ai remarqué que de nombreux message privés apparaissent dans le fil des "Derniers messages", même lorsqu'on consulte le site de façon ANONYME sans être connecté à son compte. On y trouve de tout : adresses de comptes PAYPAL, numéro de téléphone, histoires personnelles etc. en chargeant l'antériorité des activités. Est-ce normal que de telles informations confidentielles et correspondances soient divulguées sur le site à la vue de tous ???? En PJ à ce message, un exemple sur un MP me concernant d'une personne que je ne connais pas (spam ?). De plus, je n'ai pas souvenir avoir autorisé WA à m'envoyer un courriel pour m'avertir de la réception de nouveau MP : c'est en tout cas la première fois qu'il le fait depuis que je suis inscrit à ce site. Merci.
  3. MàJ : planche complète début > fin.
  4. Bonjour, Une petite planche de l'éclipse : Canon EOS 80D au foyer de la TMB130SS (APO 130/910) équipée d'un """filtre""" polymère (de qualité optique plus que discutable) montée sur la Losmandy G11. La vidéo est en cours de réalisation, petit soucis d'alignement automatique autour de la centralité. Le changement de température à la centralité ayant entraîner une chute drastique du vent et le retour des nuages, c'est beaucoup plus couvert après ...
  5. Kaidan

    PixInsight, pour avoir l'aide, il faut payer !

    1.8 actuellement, 1.9 bientôt et après ? 2.0 ... pas si loin que ça à mon avis. Je vois mal rester sur le même numéro de version un long moment.
  6. Kaidan

    PixInsight, pour avoir l'aide, il faut payer !

    Vive le logiciel propriétaire qui applique une pratique courante du logiciel "libre".
  7. Kaidan

    Crash airbus

    D'après ce que j'ai compris, le verrouillage de la porte d'accès depuis le cockpit n'est pas un bouton avec une position "open" ou une position "lock" : lorsque le code d'urgence est entré par le commandant de bord, le membre d'équipage encore à l'intérieur doit refuser l'entrée en effectuant la manipulation de refus, et ce pour chaque demande d'ouverture (soit probablement une fois par minute, si il n'y a pas de timer au niveau du code d'accès pour éviter les abus). Le copilote aurait donc, volontairement, pendant les 10 dernières minutes et à plusieurs reprises, refusé l'entrée du cockpit au commandant de bord. La molette qui permet de régler l'altitude du pilote automatique nécessite aussi, d'après les explications des pilotes, de nombreux tours pour passer un avion de 12000 à 2000m. Là encore, il ne peut pas s'agir d'un accident du bouton tourné par erreur suite à un malaise du copilote. Le procureur, aidé par le BEA, a eu accès aux retranscriptions de l'enregistrement des conversations : si il donne ce scénario, c'est que tous les éléments sont malheureusement contre le copilote. Il faudrait un concours de circonstances incroyable pour qu'il ne soit pas impliqué dans cet accident : malaise du copilote (qui continue à respirer normalement), problème de porte d'accès (mécanisme bloqué, code changé (bien que je suppose que dans la checklist d'avant vol, la vérification du code soit une des étapes)) et problème de pilote automatique qui diminue de façon linéaire l'altitude (et tous les autres réglages nécessaires pour faire continuer à voler l'avion de façon similaire malgré les changements de pression, de vent et de composition de l'atmosphère) ... et tout ça, juste quand, pas de bol, le commandant de bord quitte le cockpit. J'ai aussi une autre hypothèse : un hacker qui prend possession du vol : diminution de la pression dans le cockpit (vérification de la sortie du commandant de bord par la caméra de porte d'accès cockpit ?) pour endormir le copilote, blocage du code de sécurité de la porte, contrôle du pilote automatique à distance (c'est digne d'Hollywood). Moi ce qui me fait un peu halluciner c'est qu'aujourd'hui on a des montres connectées qui permet à ton pote en Alaska de suivre tes battements de cœur à Melbourne et pourtant, on continue à faire confiance aux boîtes noires au lieu d'envoyer les données en temps réel via satellite pour rapidement détecter les problèmes.
  8. Kaidan

    Mon logiciel d'acquisition perso (long post)

    Eric S Si tu as une idée d'un modèle économique viable tout en restant open-source et libre, je suis disposé à écouter tes arguments. Côté astrométrique, rien de révolutionnaire : je pilote, de façon optimisée, une installation de Astrometry.Net sous Cygwin. Techniquement on tombe dans la clause de "mere aggregation" de la GPL, les deux logiciels étant distincts et non livrés comme un package, mon code ne tombe pas sous la GPL. J'avais vu tes fichiers Excel pour une mise en station via astrométrie. Il faudrait que j'essaye à l'occasion pour voir si ça donne de meilleurs résultats que les différentes méthodes que j'ai mis en oeuvre. Eric S / banjo Mon PC de terrain est un HP4330 équipé d'un Pentium B960 et de 4 Go de RAM (processeur de 2011), chipset graphique intégré au processeur (4.5 sur Windows 7, 1700 sur CPU benchmark) c'est loin d'être un foudre de guerre et ça marche très bien pour la partie acquisition. Discret68 Merci. Certains fonctions d'automatisation ne sont pas terminée et je n'ai toujours pas de motorisation pour la MAP. J'ai un USB Focus mais c'est tellement daubique niveau driver ASCOM (et même pas compatible 64bits) que ça me gonfle grave. Fred_76 Par défaut, visualisation en CFA bien entendu.
  9. Kaidan

    Mon logiciel d'acquisition perso (long post)

    imarek / jgricourt : Sans entrer dans les détails de pourquoi je n'aime ni Qt, ni Java, je développe en .NET depuis la version 1.1 sortie en 2003 : c'est une technologie que j'aime et que je mets en application chaque jour dans mon activité professionnelle. De plus, un logiciel d'acquisition pilote du matériel et cette partie là, quoiqu'on en dise, n'est pas "multiplate-forme" (http://fr.wikipedia.org/wiki/Multiplate-forme ?), il faut donc réécrire beaucoup de code pour piloter le matériel : étant seul à développer, je ne veux pas rentrer dans ces contraintes. Le seul choix discutable est peut-être d'avoir utilisé WPF pour l'UI (ce qui rend incompatible avec Mono) au lieu de Forms mais bon, Forms est tellement archaïque. De plus, pour une application de niche comme celle ci, que représente la part d'utilisateurs sous Linux / MacOS X ? qui n'ont pas une VM Windows à côté... pagpatrice / michelsonia Merci. gerard33 Touché ! Quercus Comme je l'ai dit, l'application a toujours été prévue pour effectuer tous les calculs internes en 64bits, même si l'image d'origine est en 16bits (cas des CCD) : j'ai ajouté les traitements pour comprendre comment ça fonctionnait et voir ce qu'il était possible de réaliser rapidement : aucune intention de rivaliser avec PixInsight. Tout de même, la plupart des traitements sont utilisés dans des fonctions annexes essentielles : fonction de transfert, détection des étoiles. La gestion des caméras couleurs ou APN nécessitent une fonction de débayerisation. Pour le visuel assisté, en soirée, c'est également sympa de faire du passe-haut sur la Lune ou les planètes pour rehausser les détails et de "nettoyer" les images du ciel profond via la cosmétique et un passe-bas : effet sur le public garanti. Rien de bien inutile donc, même en acquisition "pure". EQMOD étant le driver ASCOM des EQ, mon application ne le remplace pas mais l'exploite pour piloter le télescope. Bottles74 Je n'ai malheureusement qu'un Canon 20D pour l'instant et celui-ci ne peut pas être piloté par le SDK Canon. En voulant mettre un support pour la QSI, je me suis rendu compte que sans avoir la caméra plusieurs jours pour faire des tests, c'est pas évident (il faut donc acheter le matériel pour tester ou se le faire prêter (ce qui n'est pas évident à la Réunion)). Vu les SDK, il serait possible d'intégrer les derniers Canon (en USB direct) et les derniers Sony, je n'ai pas regardé du côté de Nikon. bfde974 2013, c'était vraiment les premières versions. Depuis l'astrométrie offre un vrai confort aussi bien pour la mise en station que pour le pointage (pas besoin de perdre du temps à faire une modélisation) : je ne m'en passerais plus. Pour la suite, comme je l'ai dit, je ne sais pas. Si c'est pour le déployer et ne faire que du support sans rien y gagner, je ne vois pas vraiment l'intérêt (je ne suis pas dans la situation de qui vous savez...) et quand on sait que les gens sont prêts à dépenser beaucoup pour du matériel mais beaucoup moins pour de l'immatériel, ça ne sera pas évident d'en retirer quelque chose. bbdb Etant lié à Nebulosity, j'avais déjà vu SGP. Mais $99 + $149 pour Pinpoint, ça fait une solution à $248 (Elbrus n'est plus maintenu depuis longtemps, c'est plutôt archaïque comme plate-solver, je n'ai jamais pu en tirer quelque chose personnellement). On est au même niveau de prix qu'un PRiSM francophone mais bien loin de solutions comme TheSkyX ($1200) ou MaximDL ($599).
  10. Bonjour, Avant de commencer, je voudrais préciser que ce logiciel n'est compatible qu'avec Microsoft Windows : les chances qu'il soit porté dans le monde Unix (Linux ou MacOSX) sont quasiment nulles. Le logiciel, ainsi que son code, ne sont pas libres : je n'ai pas encore décidé si je vais le distribuer et sous quel format : pas de lien de téléchargement à la fin donc. Trouver un nom pour un logiciel de capture étant encore plus compliqué que de le créer, il n’a pour l’instant pas de nom définitif. Après cette petite mise au point, si la lecture vous intéresse toujours : Lorsque j'ai commencé l'astrophotographie, j'utilisais le logiciel fourni avec la caméra (ATIK) : Artemis Capture, qui est plutôt simple. Suite à l'achat d'une roue à filtre d'une autre marque, je me suis rendu compte qu’il ne permettait pas le pilotage de la roue à filtre : j'ai donc cherché un autre logiciel et le rapport qualité / prix le plus intéressant que j'avais trouvé à l'époque était Nebulosity du créateur de PHD Guiding : pilotage ATIK, RàF SX, dithering etc. Après deux années d'utilisation, je trouvais tout de même beaucoup de défauts à ce logiciel : pas de pilotage du télescope, pas de MAP automatique, pas de possibilité de faire des séquences simplement (mis à part avec un langage de script) : automatisation difficile. Nouvelle recherche et je tombe directement sur les poids lourds (MaximDL etc.) de la discipline: interface austère, compliquée (trop de clics pour faire une action simple et banale), plein de fenêtres volantes partout, plein de fonctions inutiles, usine à gaz, cher (je ne pirate pas). En plus, malgré toutes ces fonctions, il faut d'autres logiciels encore plus austères pour automatiser les nuits. Parallèlement à ça, j’avais des problèmes avec le Gemini II qui pilote ma G11 : j’ai donc commencé à développer quelques petits outils pour tester des fonctions du télescope : déplacements, guidage etc. De fil en aiguille, j’ai ajouté des fonctions pour piloter une caméra, une roue à filtre : une vraie petite « usine à gaz ». En décembre 2012, je décide donc de reprendre à zéro le projet avec une architecture modulaire, réfléchie, extensible. Le logiciel est développé en C# avec le Framework Microsoft.NET 4.5. L'interface graphique, en français (mais traductible facilement), est gérée par WPF. Il est principalement compilé en 64bits (la version 32bits fonctionne et est suffisante pour le ciel profond) pour tirer parti de la mémoire disponible sur les machines modernes (la mort du 32bits est de toute façon programmée). Tous les calculs internes sont effectués en virgule flottante double précision (sur 64bits) avec une architecture massivement parallèle qui permet l'utilisation de tous les cœurs disponibles sur le processeur (pas de support des GPU actuellement). Il est développé sur mon temps libre, en fonction des besoins et des sorties. Il a été pensé pour être utilisé manuellement comme un logiciel classique ou de façon totalement automatisé. L’interface se compose de deux parties principales : à gauche, on retrouve les contrôles du matériel et à droite la partie visualisation et informations sur l’image. Actuellement, il est capable de piloter les télescopes, caméras, roues à filtres et focuseurs compatibles avec ASCOM (6.1). L’architecture permet d’ajouter simplement du matériel via une API simplifiée (un support alpha est par exemple disponible pour les caméras QSI avec leur roue à filtre interne) qui s’inspire d’ASCOM (simplifiée et épurée). N’ayant pas de rotateur ou de dôme, je n’ai pas ajouté ces composants pour l’instant mais ça reste une possibilité à terme. La barre d’outils du haut permet un accès aux fonctions classiques d’affichage : niveau de zoom, symétries, fonction de transfert, négatif etc. A droite, on retrouve les statistiques de l’image (minimum, maximum, moyenne, intensité, déviation etc.), une loupe qui suit la souris, des statistiques sur la partie visualisée par la loupe, une vue « panoramique », un histogramme (logarithmique ou linéaire). En cliquant sur une étoile, on obtient des données spécifiques (FWHM, position du centre de l’étoile sur le capteur (avec précision au subpixel), intensité, rapport S/B etc.). Il est possible de créer simplement une sélection pour utiliser les fonctions de ROI du matériel. A gauche, le premier contrôle permet de piloter le télescope. Comme vous pouvez le voir, les fonctions sont limitées : pas de contrôle manuel par exemple (que je trouve inutile). Le pilotage du télescope passe principalement sur l’utilisation d’un catalogue d’objets intégré puis sur l'astrométrie. Actuellement, il se compose de 9400 objets du système solaire (Soleil, Lune et planètes) et du ciel profond (300 étoiles les plus brillantes, 400 nébuleuses, 1000 amas, 500 nébuleuses planétaires, 6000 galaxies etc.) des principaux catalogues (Messier, NGC, IC, Caldwell, Sharpless etc.). Les données de positionnement proviennent directement de SIMBAD. 80% des objets disposent d’une image issue du DSS pour déterminer le cadrage. Une fois proche de la cible, l'application intègre une fonction d'astrométrie aveugle qui permet de récupérer rapidement les coordonnées exactes du champ traité. Il est alors possible de synchroniser le télescope et de corriger le pointage ou de corriger uniquement par pointage différentiel. L'astrométrie sur une image de KAF8300 en bin4 nécessite entre 15 et 30s suivant la partie du ciel visée. Après une résolution astrométrique, il est possible de déplacer la cible n'importe où sur l'image et de pointer le télescope automatiquement vers cette destination, sans utiliser de contrôle manuel. Les données astrométriques étant stockées dans les fichiers acquis, il est facile de prendre un même objet sur plusieurs nuits avec le même cadrage. Les contrôles suivants permettent le contrôle de toutes les fonctions de la caméra (temps de pose, température du capteur pour les CCD régulées, ouverture de l’obturateur, nombre de poses, pause entre les poses etc.), de la roue à filtre (changement de filtre) ou du focuseur (déplacement, offset filtre) de façon manuelle. Des raccourcis spécifiques sont disponibles pour les fonctions classiques (cadrage, focus etc.). On trouve ensuite le contrôle de séquence qui permet l'automatisation complète d'une séquence. Il est ainsi possible de demander au télescope de se déplacer vers une cible, de résoudre astrométriquement le cadrage, de lancer la calibration puis l'autoguidage avec PHD Guiding, de lancer des séries de poses avec dithering, changements de filtres etc. La MAP automatique n'est pour l'instant pas prise en charge (je n'ai pas encore de motorisation pour tester) et il n'y a pas d'interface de création des séquences (à venir également) : il manque donc encore quelques fonctions pour être totalement opérationnel de façon automatique (mon observatoire n'est de toute façon pas prêt). Enfin, un dernier contrôle permet d'afficher en temps réel les données et statistiques de suivi de <i>PHD Guiding</i> (nécessite la version 2.2 minimum). Après avoir régler l'amplitude et la fréquence de dithering (toutes les X poses), celui-ci sera automatiquement effectué à la fin des poses. L'application permet bien entendu de gérer plusieurs sites d'acquisitions et plusieurs profils de matériel. L'affichage de certaines fonctionnalités (comme la mise au point, décalage d'une image dans la PoC) peuvent être déportées via un Serveur Web sur un smartphone / tablette (utile pour la MAP manuelle) ou via internet. A terme, toutes les fonctions devraient être pilotable via une interface web (HTTPS) pour du remote. Lorsque la partie « acquisition » a été plus ou moins stabilisée, j'ai développé quelques fonctions annexes : Ci-dessus, une fonction, en cours de développement, permettant de régler le tilt du capteur (sur une zone de ciel étoilée sans objet ni étoile très brillante). Cette fonction vient en complément de la visualisation de la mosaïque des coins du capteur. Ci-dessus, une fonction de détection des étoiles sur une image et calcul de la FWHM pour chaque image. Ci-dessus, une démonstration du module de correction automatique des couleurs sur une acquisition de M8. Ci-dessus, une démonstration d'un filtre passe-haut sur une image lunaire pour améliorer les détails. En cliquant sur le lien Traitements vous serez dirigé vers une page qui propose une démonstration dynamique de plusieurs processus mis en oeuvre pour le traitement d'image : histogramme automatique, correction des colonnes mortes, correction des pixels chauds et froids, filtre passe-bas. Déplacez la souris sur le nom d'une opération pour voir le résultat (affichage optimisé pour un écran Full HD). Pour finir, des images réalisées avec le logiciel : Certains objets comme les dentelles, M31 ou M33 sont très bas sur l'horizon ici (en dessous de 15°) dans la pollution du chef-lieu réunionnais (Saint-Denis). Les traitements n'ont pas été optimisés. Île tropicale et relief trop bas (même à 2200m), le seeing n'est jamais bon. Images à la 383L+ sur TMB130 (correcteur 3" ou réducteur WOT4), TMB92 (réducteur WOT4), AT65Q astigmate. Jusqu'à présent, il n'y avait que 2 membres du forum réellement au courant du développement de cet outil. Merci à Tiflo et yonafunu pour leur soutien. Voilà, j'attends vos avis, commentaires et suggestions. Kaidan
  11. Kaidan

    Mes TIFF pour vous !

    ... probablement parce que tu es arrivé trop tard ? ... Bien entendu, si tu regardes l'époque lointaine où ce message a été posté, tu constateras que mon activité sur le forum était tout autre. De plus, quand on a pas fait de recherche sur l'historique des discussions avec Klape... non, sans commentaires.
  12. Kaidan

    Caméra CMOS PLB-Cx 1.3Mp

    Aucune réponse à mon dernier courriel ... il m'avait pourtant assuré une sortie pour le mois dernier.
  13. Kaidan

    Caméra CMOS PLB-Cx 1.3Mp

    Début juillet, j'ai eu un courriel qui spécifiait production septembre, commercialisation octobre (donc dans quelques jours), capteur IMX139 USB3.
  14. Kaidan

    KAF8300 ou sony ICX694

    Au delà des impressions du post de mourer, il semblerait que christiand aie des chiffres qu'il garde très jalousement.