patry

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

Par contre l'ASI 432 ... capteur 1,1", pixel size 9µm !!! Full well 97000 ! La remplaçante de l'ASI 174 somme toute mais en mieux. Sauf que le bruit de lecture me semble tout aussi désuet ainsi que le QE ! Dommage ! Marc

QGineys, c'est un peu de l'arnaque cette planche (source ASI pourtant). Le QE est donné à 81% pour l'ASI462, mais cela me fait tiquer car sur la fiche de la 462, elle était donnée pour 90% (à 850nm). Du coup j'ai regardé en détail et effectivement la 662 donne bien 90% ... aux environs de 550nm, et à la même couleur, la 462 est bien à 80% ... donc c'est pas faux (ouf) mais c'est pas trop vrai non plus car je peux aussi dire que la 462 a bien 90% de QE et que la 662 n'est qu'à 50% (en omettant de dire que c'est à 850nm). Commercialement c'est toujours vrai mais les chiffres ne sont plus aussi "flatteurs" ! Maintenant ce qui me surprend c'est le full well à 37ke, versus 12ke ce qui laisse penser qu'on pourrait avoir presque 2 bits de plus à échantillonner ... ce qui n'est pas le cas (ADC=12 bits dans les deux cas). Ok donc on serait moins sensible au bruit ... ce qui n'est pas le cas non plus (ce serait même l'inverse) ! Bizarre ! Par contre la courbe de transmission montre un effort sur l'équilibre RGB de la petite nouvelle. Mais pour autant je ne changerais certainement pas une 462 pour une 662 ! Ca non ! Marc

Un incontournable à avoir sur son PC : Atlas virtuel de la lune, qui non seulement te donne une cartographie avec toutes les indications sur les formations lunaires mais il va aussi te proposer une vue assez fidèle de la lune "au moment" de l'observation. La position de l'ombre est indiquée et tu retrouve assez facilement tes petits dessus. En +, tu aura la libration (ce qui te permet de voir un peu au dela de la face visible), et en zoomant (si tu a installé les -gros- fichiers supplémentaires) tu récupère un planisphère de très très haute résolution (kaguya, LRO, ...). Mais tu a aussi des solution "papier" comme le grund, qui m'a été très pratique à mes débuts (de quand "internet n'existait pas"). Marc

En contraste c'est probable (c'est même certain) mais les détails seront les mêmes ! Marc

Je vois peu de différences entre 290 et 462, seule la 290 me semble plus "contrastée" (la tambouille pour passer la 462 du RGB au mono doit être passée par là). Mais cela reste un très bon exercice et j'avoue que j'avais fait du venus au mak 127 avec un filtre W47+L ou directement au filtre bleu, avec pas mal de détails, mais au C11 c'est le 23A (ou IR742, seul que j'avais à l'époque) sans pousser trop le filtrage. A retenter en poussant les curseurs donc. Marc

Il est quand même très largement préférable d'utiliser une caméra monochrome car malgré tout le soin apporté à l'aplatissement RGB->mono sur la dernière image la majorité des détails viennent d'un reliquat de la matrice de bayer (la trame est trop régulière pour que cela soit vrai). Il suffit de quelques unités de différence pour que les ondelettes exacerbent ces subtiles différences en pentes abruptes. De façon moins "brutale" j'ai tenté la même chose avec l'ASI462 sur la lune que j'ai cherché à rendre "monochrome" (même principe) et à la fin la trame était systématiquement visible. Mais tu peux t'en sortir en appliquant un filtre assez fort pour virer ça mais au prix de voir disparaître également un moutonnement que l'on devine (quelques zones claires dans le bas du globe). Un filtrage gaussien léger AVANT les ondelettes (noise prefiltrer ?) permet de trouver un tapis pour cacher la misère. Autre solution, traiter directement l'image couleur (j'imagine alors que chaque plan est traité séparément) puis aplatir après. Au moins tu évitera la trame gênante. Sous Registax il y avait le moyen de construire une luminance (synthese L=xR+yG+zB de l'image couleur) sur laquelle on appliquait un filtrage puis on recollait le tout en L+RGB. Marc

Merci polo. Disons que la hauteur de la lune n'aide pas trop non plus. Marc