patry

S'il y a de la buée c'est que: Il y a de de l'humidité dans l'air ET la surface est ou a été plus froide que l'extérieur (une fois déposée, tu peux avoir 0° de différence il faudra beaucoup de calories pour l'évacuer). Et sur la lame, c'est toujours signe d'une résistance chauffante de puissance insuffisante. Ajoute à cela un air humide renouvelé par la ventilation, le résultat n'est pas étonnant. On en a déjà parlé mais j'ai vu une règle un peu empirique qui veut que la puissance (pour 9, 11 et 14 pouces) vaut en Watt, 1,5 ~2,0 x le diamètre en pouce. Donc pour un C11, compte sur 16~20W. Pour mon C11, le cordon est marqué 20W, mais à l'usage la mesure me donne plutôt 17W ce qui n'est pas toujours suffisant si l'air est très humide (à Toulouse, j'image que l'air humide des côtes est plus chargé encore). Pour le C8, j'ai fait ma propre résistance chauffante sur le barillet mais à l'intérieur du tube, et j'ai mis 15W. Je n'ai plus jamais eu de buée et l'image ne semble pas non plus perturbée. Je pense que de mettre le truc à l'intérieur permet de mieux exploiter les calories qui, et c'est ce que l'on leur demande, chauffent la lame avec une meilleur efficacité. Le tube pointant le nez en l'air, l'air intérieur légèrement chauffé va maintenir plus globalement la lame éloignée du point de rosée. Idéalement il faudrait assécher l'air. J'ai vécu cela il y a des années quand j'observais en forêt, le C11 ne tardait pas à s'embuer, mais un petit tour dans la voiture, clim à fond suffisait à virer la buée dedans comme dehors ! Et cela marche aussi avec de l'air frais => pas trop d'attente de remise en température. Par contre sur le primaire je n'ai jamais eu de buée ... mais je n'ai pas de ventilateur de brassage non plus qui me semble utile pour équilibrer "rapidement" les températures mais ensuite la radiation du tube suffit à maintenir l'équilibre. Sauf bien sur si le tube est en carbone (hérésie planétaire) ou que le delta T fait plusieurs degrés à l'heure. Peut être que du silicagel devant les ventilateurs peut suffire ? Marc

Super stable sur Toulouse. Les nuages faisaient du sur place ! J'ai l'impression qu'ils n'ont d'ailleurs pas bougé depuis la pluie de la veille. Marc

Merci à tous. Pour la teinte bleue, c'est normal vu l'heure de capture (4h TU cela fait du 6h TL) et le jour n'est pas loin. Disons qu'on peut lire facilement sous ce ciel là. Coté traitement en effet je n'ai pas de dérotation, ce sont des captures "uniques" de 90 à 120" maximum dont j'extrait 900 à 1200 images. Tout le traitement est fait avec Astrosurface, mais j'ai peut être encore des reflexes "monochrome" sur la gestion du bruit (généralement sous ou autour du pixel). Avec le capteur couleur sans doute qu'il faut être autour de 2 pixels ou plus. Je suis en tout cas surpris du résultat car la turbulence n'était pas "nulle", et même si certains détails se voyaient à la capture, cela restait assez bouillonnant quand même. Bon rien à voir avec ce matin qui, je pense, finira à la poubelle. Je vais traiter tout à l'heure mais je doute de trouver une bonne séquence. Je suis même resté pour le passage au méridien (c'est rigolo d'observer Jupiter alors que le soleil chauffe déjà bien) mais rien à faire la turbulence était très marquée. Marc

Toulouse ... mais à part 1 jour de beau temps en début de semaine et un autre la semaine dernière, le reste c'est nuage et pluie (mousson habituelle). Et encore, j'ai tenté de faire des images de Jupiter il y a 15 jours ... ca a été rapide à tout jeter avec une turbulence de près de 10% de la taille de la planète. Marc

Pourtant un peu de bleu ce serait bien pour compenser cet océan de gris que l'on a ici depuis des jours ! Marc

Avec des photosites de 12µm ??? Tu va avoir un échantillonnage de mer** non ? Par contre la détectivité sera au top. Pour certaines applications (mentionnées plus haut, pulsar, phénomènes transitoires type occultations, ...) ce serait pas mal. Pour le reste, utiliser une barlow x10 ou plus sur un newton à F/4~F/5 pour approcher l'échantillonnage résolvant je n'en voit pas trop l'utilité. Dit autrement, c'est clairement pas un capteur pour faire de la HR ! Maintenant en CP, c'est clair que tu ne sera pas gêné par la turbulence, ce sera même le seul capteur où le mistral (ou la tramontane, remplacer par votre zéphyr local) et les défauts d'EP de la monture ne seront pas un problème. Marc

Je n'ai pas dit cela, mais que la taille de la cache doit s'exprimer par rapport à la taille de ton fichier et du temps qu'il faut pour le générer. Marc

Oui, s'il y a un frein, forcément, cela va coincer à un moment ou à un autre. Sur mon portable, sans SSD, j'ai augmenté la ram pour bufferiser plusieurs Go. Bon c'est surtout en lunaire que c'est utile (en planétaire, je n'ai jamais eu de problème même en HDD). Au final, sur des captures pas trop longues, ca tient mais à la fin il faut compter plusieurs secondes (voire dizaines de secondes) pour finir de stocker le fichier. C'est pas trop gênant en planétaire car dans l'intervalle on change le filtre, on refait/vérifie la map, bon tout cela qui se fait dans ton dos. Avec le SSD, je n'ai plus jamais eu de problème, à peine quelques images passent par le buffer sous Firecapture quelques fraction de secondes puis tout rentre dans l'ordre (ASI178, je n'ai pas encore beaucoup d'expérience avec la 462). Pourtant je n'ai pas non plus une bête de course (ACER E17, un i5 6200, 12Go de RAM -augmenté-, un SSD de 256Go + un HDD de 500Go devenu un second SSD de 500Go puis de 1To). Du flan ... non, mais est-ce utile ? Faut voir. Car si tu a des problèmes de débits, c'est pas 256Mo qui vont y changer grand chose. Regarde quelle taille fait ta capture à la fin. Tu les remplis en combien de temps les 256Mo ? Et après ? A la limite, avec un horodatage (GPS ou autre) dans la caméra, les petites fluctuations de débit (insensible à l'usage) peuvent être lissées. Ainsi une occultation qui peut durer quelques fraction de secondes, ces caméras peuvent avoir une précision à la milliseconde et si tu inscrit la date à la capture c'est encore mieux plutôt que d'être tributaire de l'interface pour dire ensuite à quelle heure l'image a été prise. Bien sur il reste nécessaire que le débit d'image soit inférieur au débit de l'interface, sinon retour à la case départ. Marc

Je ne comprends pas cette phrase. "Stabiliser" les informations j'avoue ne pas trop comprendre à quoi et en quoi cela peut être utile. J'ai le sentiment que le constructeur à ajouté de la mémoire (et en fait un argument commercial) PARCE QU'il a ajouté une fonction DPS de pré-processing (dans la caméra plutôt qu'à postériori dans le PC, pourquoi pas ...) et que cette fonction a besoin de mémoire pour travailler. J'ai bon ? Marc

"Cumulonimbus" et "foudre", j'en ai eu que deux ! Ha si, avec "pluie" et "averse", cela fait quatre ! Si j'ajoute "orage", "grêle" et "crachin" j'ai bon, j'ai les sept Marc

Comment on a pu arriver à rayer l'intérieur du tube ... et sur le secondaire (pas de bol) qui plus est ? Cela laisse entendre qu'un "truc" est tombé dans le tube et que "peut être" il n'y a pas que la partie aluminée qui est atteinte. Mais ce sera peut être plus difficile à voir ! Cela m'est arrivé sur le C8 où mon fils (pas vieux à l'époque) à trouvé rigolo de laisser tomber une pince à linge par le PO du C8 orange qui était posé dans le bureau. Bon c'était du plastique et le secondaire n'a pas été atteint ... j'ai du démonter la lame pour récupérer l'intruse. Marc

J'ai l'impression que l'éraflure est sur la face extérieure non ? Vu du PO, tu voit le ciel au travers ou pas (abstraction du reflet du primaire) ? Ou si tu n'y arrive pas, pointe "dos au soleil" et regarde depuis le ménisque. Marc

Oui et heureusement. En empilant des centaines d'images (de 8 bits) ta dynamique passe assez rapidement à plus de 16 bits même ! Avec une dynamique augmentée, les outils de réhaussement de contraste (typ ondelettes) fonctionnent mieux et l'augmentation des pentes permet de faire ressortir les "détails". Voila en exemple une image compositée (accumulation de 900 images brutes) La coupe permet de voir le niveau (de gris) de l'image le long du cratère. Ensuite, après le passage des ondelettes, la coupe est sensiblement la même mais le réhaussement de contraste permet d'accentuer les pentes (i.e. les variations sont plus prononcées) ce qui se traduit "visuellement" par une lecture plus facile. Le traitement "n'invente" rien (sauf à parler d'artefacts mais c'est un autre débat). Les informations étaient présentes mais non "visibles". C'est le cas des petits cratères, des variations sur le flanc éclairé du cratère en coupe, etc etc. Le but est donc d'obtenir une image avec une dynamique maximale pour que les ondelettes (ou autre) travaillent au mieux. Cela peur sembler utile de travailler en 12 bits, mais en réalité, les "bits en plus" sont souvent très bruités et la dynamique peu utile. Là encore il est plus simple de lire en 8 bits, mais d'en lire beaucoup pour compenser. Attention, un ciel turbulent te forcera à accumuler de "mauvaises" images ... c'est un compromis à trouver ! Marc

Personnellement la case HS est toujours cochée chez moi (je n'ai pas vu de grande différences sans de toute façon) sauf les rares fois où je capture en 16 bits. Pour revenir sur le format SER et pour être exhaustif, il faut comprendre que le format prévoit beaucoup de mode d'enregistrement (comme le fit d'ailleurs, j'y reviendrais plus tard). Le format SER est un format qui permet d'enregistrer une vidéo, donc une suite composée d'images. Chaque image est définie en monochrome (0), Bayer RGGB (8), Bayer GRBG (9), Bayer GBRG (10), Bayer BGGR (11) mais aussi Bayer CYYM (16), Abyer YCMY (17), ou encore RGB (100) ou BGR (101). L'organisation des données permet de savoir comment sont codées les informations (big endian ou little endian, c'est "informatique" pour savoir où se trouve les données de poids fort -les dizaines par rapport aux unités pour faire simple-) La taille de l'image en nombre de pixels (largeur et hauteur). Le nombre de pixel par plan 1..16 permet de savoir comment sont codés les pixels. A partir de cette valeur on va trouver comment sont stockées les informations par pixel (c'est lié au au nombre de plan, issu du type de format (mono, Bayer, ... ou RGB/BGR) et vaut 1 ou 3, fois le nombre de pixels par plan (division entière par 8 + 1). On va ainsi avoir 1 octet (mono/Bayer <= 8bits), 2 octets (mono/Bayer > 8 bits), 3 octets (RGB <= 8bits) ou 6 octets (RGB > 8 bits). Enfin le nombre de trames donne le nombre de fois que chaque image est répétée. Des informatios "personnelles" libres pour identifier la capture et l'auteur, puis la "date" (8 octets) de la capture en temps local puis en UTC. Eventuellement, à la fin des données, N x 8 octets pour horodater chaque image ! J'avais écrit (il y a longtemps) un programme pour corriger le défaut d'enregistrement invalidant l'entête du SER. En effet, le nombre d'image doit être mis en place à la fin de la capture mais au début du fichier. En cas de soucis, y compris sur la dernière image, cet entête n'est pas mis à jour et les données sont illisibles. Sauf à analyser le fichier, sa taille, les données qu'on y trouve, et estimer à postériori la meilleure valeur possible pour coller au fichier. Quitte à saisir une valeur manuellement et regarder ce que cela donne. Cela m'a sauvé de nombreuses captures au début des drivers des caméras. Le format FIT est sensiblement plus "complet" car il peut enregistrer en 8 bits, 16 bits, 32 bits, 64 bits (par plan) en entier signé ou non signé, ou en flottant, voire un nombre complexe, avec un nombre quelconque de plans (1 pour une image "ligne", 2 pour une image 2D, 3 pour une image 3D ou ... pour une vidéo 2D !!!) ou plus encore (999 dimensions) avec la dimension de chaque plan. Dans nos outils astro, le format fit est réduit à une représentation 2D (image), et je ne connais pas de soft amateur gérant la 3D ou la 2D+vidéo ! D'un autre coté, la capture avec des données > 16 bits me semble là aussi peu usité dans le domaine amateur (déjà qu'avoir un bon ADC 16 bits c'est pas facile). Marc

Erreur

Notice de FireCapture ... J'ai refait des tests vite fait et effectivement il n'y a que dans le mode "Forcé" que le fichier est 3x plus gros " --- SER HEADER fileId = LUCAM-RECORDER SerLuID = 0 SerColorID = 101 littleEndian = 0 width = 640 height = 480 pixelDepth = 8(8) frameCount = 1000 --- SER HEADER END Channels : 3 8 bits/channel Size in pixels : 640 x 480 pixels 0.3072 Mpixels Size for file as opened : 878.91 MBytes Size for one image : 900 KBytes ( Calculated non compacted ) Donc on est en RGB, 3 plans BGR => 900Ko Second fichier --- SER HEADER fileId = LUCAM-RECORDER SerLuID = 0 SerColorID = 0 littleEndian = 0 width = 640 height = 480 pixelDepth = 8(8) frameCount = 1000 --- SER HEADER END Channels : 1 8 bits/channel Raw file ? Size in pixels : 640 x 480 pixels 0.3072 Mpixels Size for file as opened : 292.97 MBytes Size for one image : 300 KBytes ( Calculated non compacted ) On est en monochrome, donc un seul plan, pas de débayerisation. 3e fichier --- SER HEADER fileId = LUCAM-RECORDER SerLuID = 0 SerColorID = 8 littleEndian = 0 width = 640 height = 480 pixelDepth = 8(8) frameCount = 1000 --- SER HEADER END Channels : 3 8 bits/channel Size in pixels : 640 x 480 pixels 0.3072 Mpixels Size for file as opened : 292.97 MBytes Size for one image : 900 KBytes ( Calculated non compacted ) On a bien une image couleur, mais "à débayeriser". Marc

Parce que la débayerisation ne consomme pas beaucoup de ressource CPU pour l'affichage. Peut être même que c'est réalisé par la carte graphique à la volée. Par contre j'ai vérifié dans le fichier SER, et cocher/décocher la première case n'a pas changé pas l'entête du SER qui n'indique par ColorID=0. Je referais des essais plus tard pour vérifier mais c'est clairement un bug pour moi ! Marc

Ce qui me fait penser qu'avec l'ASI 462 en IR >800~850nm, donc avec la caméra qui se comporte "comme" une caméra monochrome, on a tout intérêt à décocher la case pour enregistrer en RAW/Monochrome (ColorID 0 dans le fichier SER) plutôt que RAW/BayerXXXX (ColorD 8~11). Le traitement se fera en monochrome et non en couleur, ce sera mieux ! Marc

C'est exactement ce que j'ai dit. Par défaut, FC enregistre en RAW (en tout cas sur ma version 2.7.10 avec une case qui est nommée "Forcer l'enregistrement en couleur (Non recommandé)" décochée). Du coup quelque soit la débayerisation A L'ECRAN, le fichier est le même (ce que tu observe). Quelque soit l'état de la première case, l'enregistrement est toujours EN RAW (tu peux vérifier avec Autostakkert) et le flux est monochrome. Ensuite les outils de traitement font le dématriçage tout seuls, et tu traite en couleur comme d'habitude. Mais dans mon essai réalisé à l'instant (dummy cam) 1000 images en 640x480x8 bits couleur cela fait 300Ko ... c'est correct. Par contre la première case doit indiquer dans le fichier que le flux est couleur, et quel type de matrice de bayer est utilisé. A vérifier sur AS!3. Je n'ai pas pu essayer la seconde case qui plante (dummy cam probablement). CQFD ! Marc

Je ne comprends pas, debayeriser la vidéo ne change évidemment rien au mode d'enregistrement. Pour cela il faut cocher la case "Forcer l'enregistrement en couleur (Non recommandé)" il me semble. Marc Doublé par wilexpel, mais bon on ne peut pas regarder le rugby et répondre aux post !

Pour le C14 de William, j'ai utilisé mon établi qui est bien justement réglable en hauteur. Je place l'établi à coté de la monture, pose le tube tête en bas sur l'établi, fait glisser le tube sur la tête de la monture et il n'y a plus qu'à serrer. Ensuite, tu installe les CtP et on peut tourner la monture en toute sécurité. Penser à retirer l'établi, mais bon cela me paraît évident quand même ! Parce que venir installer la platine losmandy (et les 22kg de C14 qu'il y a autour sinon c'est un peu facile) précisément ... c'est un peu scabreux je trouve (surtout pour du matériel qui n'est pas à soi). Marc

La différence est plus marquée avec la 178 et la 678 15000 sur 14 bits (ASI178) contre 11200e- sur 12 bits (ASI 678), cela fait 15000e- / 16384 = < 0,91e- par ADU pour la 178, contre 2,73e-/ADU pour la 678. On voit bien qu'on est pas du tout sur la même techno ; que cela soit sur la capacité comme sur l'ADC ! Marc

Mon interprétation : Tu a 38000e- (ton full well depth) à échantillonner, et ton échantillonneur fait 12 bits. Il permet donc 4096 valeurs ADU possibles. Donc idéalement tu a 38000e- échantillonnés en 12 bits cela fait 38000/4096 => 9,27e-/ADU (hypothèse : le convertisseur est parfaitement linéaire) Toute variation de moins de 9e- soit ne sera pas vue (tu reste sur le même ADU), soit sera considérée comme du bruit de 1 ADU. Maintenant si ton "bruit" fait ~20e-, tu aura un bruit de 2 ADU etc etc. D'où ma reflexion sur l'ASI 432 qui peut accumuler 97000e- (c'est pas mal), mais toujours avec 12 bits (4096 valeurs), il faut atteindre pas moins de 97000/4096 => ~24e- /ADU. Donc si le bruit dépasse 24e-, alors cela se verra comme 1 ADU (ou plus) ! En dessous, le signal restera constant. Maintenant le bruit (en e-) va dépendre de l'amplification réalisée, du coup cela varie avec le gain. Marc

J'ai tenté de retrouver une page web d'un gars qui a "remis" la lame de son C11 à sa place (2x plus loin), donc rajouté une araignée pour supporter le secondaire, et les résultats en bordure de champ étaient bluffants. Mais bon c'est une "grosse" opération quand même ! Marc

Evoqué sur un autre sujet Par rapport à la 174, évidemment il y a du mieux. Même si je modère un peu mes propos concernant le bruit. Car avec 97000e- (capacité maximale) échantillonnés sur 12 bits (4096 valeurs) cela fait un ADU tous les 23,6 e-. Donc 20e- de bruit cela fait moins d'un ADU ! A bien y regarder, le diagramme d'ASI montre bien plutôt 24e- de bruit à gain minimal (là où on a la capacité maximale), ce qui représente un ADU, c'est bien. Avec une telle capacité de potentiel, c'est dommage de ne pas avoir mis un ADC de 14 bits quand même (voire un 14/10 bits pour faire de tout) ! Marc