
Philippe
Anciens Avex-
Compteur de contenus
1 634 -
Inscription
-
Dernière visite
Tout ce qui a été posté par Philippe
-
M101 , 10H de pose QSIO640 condition moyenne
Philippe a répondu à un(e) sujet de felopaul dans Photographies - galerie
Très belle résolution et une image agréable ! Pour le traitement, le bruit est complètement lissé (tu vois, Rachid ), tu aurais dû t'arrêter au tiers des curseurs Je boosterais un peu le contraste et un peu la chroma... Les étoiles semblent avoir un début de yeux de merlan Attention ! -
Je raisonne, bien sur, en rapport signal sur bruit mais aussi sur les faibles niveaux de l'image. Et ce qui m'intéresse, ce sont aussi ces petits détails coincés dans le bruit. Toi tu t'en fous royalement. Chacun son truc... 15 bits, c'est bien, comme le 32 bits, l'important c'est d'en être convaincu J'ai essayé de traiter avec Iris. Malheureusement il m'a squizzé mes flats à 32768 adu (alors qu'ils étaient à 42000), le con >:O
-
beh couillon !!! C'est pas cool tout ça.
-
Content que vous ayez eu de belles nuits ! Ca atténue ce retour difficile ! En attente de vos photos
-
une rosette sympa comme tout (à l'APN) Certes, ça manque un peu de pose mais la technique est là Bravo
-
Superbe, rien à dire ! tip top
-
camera autoguidage i-nova PLB Mx 1.3
Philippe a répondu à un(e) sujet de Philippe dans Discussions générales
lol Je te l'accorde à 200% Frédéric, les cam chinoises sont chères pour ce qu'elles sont. Mais quand le capteur va, tout va -
Problème PHD, "the star did not move enough"
Philippe a répondu à un(e) sujet de Obiwan dans Discussions générales
Il peut y avoir plusieurs problemes 1) PHD : le temps de caliration (défaut 750ms je crois) est trop faible pour la focale et il faudrait plutot mettre 2000 2) Ton port ST4 ou cable ou connecteur ont un probleme 3) Tu peux éventuellement tester le guidage par logiciel (donc par des ordres à la monture). Il faut juste que tu sélectionnes monture (et sélectionner Ascom EQ6...) au lieu de guider relays (un truc comme ça) 4) essaye maxim si tu l'as, juste pour actionner manuellement les relais X Y pour savoir si la monture répond bien sur toutes les directions ST4 5) tu peux aussi "écouter" ta monture lorsque tu actionnes X+ X- Y+ Y- car les moteurs changent de régime. -
Salut Alban Tu n'aimes plus Atik ou alors le 8300 ? Bon, je n'ai qu'une modeste et ancienne QSI-540-WSG avec seulement 5 positions pour les filtres 1.25'' vissés. Je l'équipe soit en L,R,G,B,Ha ou soit en L, Ha, , selon les objets ou le ciel. Parfois j'aimerais bien avoir une 8 positions mais bon, ce n'est pas un probleme de dévisser le capot et installer les filtres (y en a pour 5 min). De plus, la 640wsg8 est quand-même plus large que le modèle 5 positions Pour te décourager du 4022, je te joins ici une image de bias et de dark 20min (-20degC) de 3 QSI (a=640, b=640, c=540)
-
Ah merde, t'es encore pire que ce que je croyais !!! moi qui pensait que tu avais une PNG 16 Allez, fait un CROP et fait peter un 16 et un 32 en FIT
-
Ah tu vois quand tu veux Désolé de t'avoir énervé ! Mais l'important est de comprendre par soi-meme ce qui est utile ou inutile, ou ce qui est faisable ou non. Et quand un mec te dira "j'ai une camera 16bits, je traite en 15bits", tu pourras le cataloguer dans les IRIS user > Cà, c'était juste la petite touche CCD1024, juste pour le fun c'est cadeau
-
-
En fait je reviens sur mes explications : 1) si tu as une image 32bits LINEAIRE (juste prétraitement), donc fond noir et les étoiles quasi saturés (ou fortes) et que tu la passes directement en 16bits, tu PERDS toute l'info des bas niveaux. C'est le cas de ton PNG que tu nous as envoyé 2) Tu traites en 32bits et tu appliques un GAMMA (par exemple) pour compresser la dynamique et donc faire sortir l'objet et le fond. Et ensuite tu passes en 16bits, alors tu ne pers pas d'info (puisque tu as compressé la dynamique). puis en 8 bits, tu pers un peu mais tu as une visu parfaite. C'ets le cas des images TRAITEES C'est plus clair ?
-
C'est déjà un grand pas comparé à rester en 16
-
la je ne comprend pas : ce n'est pas le cas de tout les softs d'images ??? J'espère que si
-
Tu sais, souvent, certains process dits scientifiques peuvent se retrouver dans des logiciel dédiés à un public plus large Un peu comme l'algorithme GREYCstoration (qui a été conçu à Caen) se retrouve maintenant dans des softs comme Pix, Gimp, imageJ, et bien sur matlab...
-
Tout dépend de comment va se faire la conversion en 16bits. Si c'est simplement "squizzer" les 16 bits de poids faible, tu pers toute l'info des bas niveaux ! Si tu prends le min et le max de tes valeurs en 32bits (par exemple si tu vas de 3000 à 750000) et que tu reconvertis en 0 à 65500, alors tu auras moins perdu. Pixinsight a une autre approche. 16 bits sont convertis en REELS 32bits entre 0 et 1. 1 est le max quelque soit le nombre de bits. Tu traites ton image entre 0 et 1 en 32bits ou 64bits natif (tu décides) Tu convertis alors ton image 0 à 1 en 8, 16, 32, ou 64 bits. Ce qui est plutot bien foutu pour garder une certaine linéarité des données.
-
C'était un calcul de déconvolution sur un bout d'image "scientifique" pour comparer différentes méthodes de déconvolution à ma boite (on travaille sur le "denoising" en live sur l'empilement d'images confocales). 1h de calcul sous Pix... sur 500 itérations. Le 64 bits apporte un poil de cul mais pas de quoi se relever la nuit
-
Décidément, tu n'as toujours pas compris le raisonnement... On s'en fout que ta CCD soit 14 ou 15 ou 16bits. Derrière tu vas faire une GROSSE série de calculs. Le 16 bits perdra des informations alors que le 32bits sera (largement) généreux. Mais comme tu ne peux pas traiter en 20 ou 24 bits... 32 c'est bien.
-
D'autre part, si tu fais tes prétraitements sous DSS, l'image AUTOSAVE (TIF ou FIT) est en 32bits !
-
tu as 8.3 millions de pixels, certes. Quel rapport avec le nombre de bits du codage de chacun des pixels ? Si je suis ton raisonnement, une webcam 8 bits ne peut avoir que 256 pixels Bon, l'autre w-e, pour tester une fonction très spéciale sous Pixinsight, j'ai forcé le traitement en 64 bits et non plus en 32 bits le ouf !
-
explique moi ma ccd n'a que 22500 niveau soit un 14bit "+" sans compter les bits de "bruit" c'est interpolé en 16bit mais on d'accord qu'on est pas véritablement en 16bit donc quand DSS (qui me me sortir des 32bit) me compile mon image on est en vrai 16 bit des lors qu'on atteint ou dépasse 16 images donc quel est l’intérêt du 32 bit si j'en suis si loin ? Ah l’éternel refrain du "j'acquière en 16bits", je traite en 16bits Tes images brutes sont en 16 bits (et généralement les faibles niveaux sont les plus présents) A tes images brutes, tu vas corriger des bias, des dark des flat (enfin, des "master") Tu vas ensuite réaligner tes images voire faire une petite rotation (ré-échantillonnage) Tu vas ensuite additionner tes N images Dans le pire des cas, 16b + 16b + 16b + 16b +... = 17/18/19/20... bits Eh beh, la dessus, je traite en 32 bits INTEGRALEMENT pour ne rien perdre comme signal. De plus, ce qui m'intéresse, c'est ce qui va se passer dans les faibles niveaux et je n'ai donc pas envie qu'ils soient sous-échantillonnés et donc dégradés par une conversion 32-->16 Quand on convertit de 32bits à 16bits, d'après toi, on vire quoi ? Bah les faibles niveaux... (en général) Après chacun est libre de penser que 16bit + 16bit = 16bits (chez moi ça fait 17 bits), imagine quand tu additionnes 20 ou 30 images.
-
effectivement, la PNG 16 bits sous PI ne permet pas de détailler les faibles niveaux. Ta correction de flat est, comment dire...
-
c'est dommage une brute d'empilement de 16 bits alors qu'on peut avoir plus de dynamique avec un empilement 32 bits
-
oui, elle est considérée comme vendue.