QHY5L-II et ciel profond

easybob08 · 1 octobre 2013

Salut apollo

ben normalement, quand tu sélectionne longue pose avec ezplanetary, tu peux faire des poses plus longues que 3 secondes. Chez moi, ça marche, bien que la camera a un peu de mal à se caler sur la longue pose pendant quelques secondes mais en attendant un peu, ça marche. Il n'y a rien de spécial à faire.

Firecapture me donne plus de soucis sur les longues poses (ça marche pas très bien je trouve).

En règle générale, j'utilise ezplanetary pour les longues poses et firecapture pour les courtes poses.

patry · 1 octobre 2013

Oui moi c'est un peu pareil. Firecapture semble mal fonctionner avec des poses longues (>500ms). J'ai aucun flux en retour de la caméra, alors qu'EZP "marche" avec la même expo !

Marc

adonf · 1 octobre 2013

Oui moi c'est un peu pareil. Firecapture semble mal fonctionner avec des poses longues (>500ms). J'ai aucun flux en retour de la caméra, alors qu'EZP "marche" avec la même expo !

Marc

Et sharpcap ?

Perso c'est celui que j'utilise en vidéo. Pas testé en pose longue.

easybob08 · 1 octobre 2013

Sharpcap, j'ai essayé mais j'ai pas bien compris pourquoi les versions beta ne marchent que sur une période donnée. Ca m'a un peu saoulé et je l'ai viré.

Sinon, perso, je trouve que ezplanetary est pas si pourri que ça. Il est simple et fait assez correctement son boulot. Son grand plus par rapport à Firecapture, c'est la gestion des longues poses avec la soustraction des darks à la volée. C'est très utile pour les timeplapses (mais bon, c'est un peu exotique comme utilisation). Il gère bien aussi le mode 14bits ce qui est pas mal quand même.

ce qui m'embête le plus avec ezplanetary, c'est qu'il est moins bon que firecapture pour le nb d'images par secondes en acquisition poses courtes. La gestion du BIN2*2 est un peu space aussi.

Par contre, Firecapture ne sais pas gérer le mode 14bits avec la camera version couleur et le choix de la ROI est un peu prise de tête (plus les poses longues qui marchent pas).

adonf · 1 octobre 2013

Sharpcap, j'ai essayé mais j'ai pas bien compris pourquoi les versions beta ne marchent que sur une période donnée. Ca m'a un peu saoulé et je l'ai viré.

La vrai 2.0 non beta vient de sortir.

Elle a l'avantage d'utiliser le driver de base de QHYCCD, donc avec toutes ses fonctionnalités, plutôt que le driver WDM comme précédemment.

Le seul problème c'est que chez moi ça plante :?:

apollo04 · 1 octobre 2013

Merci

Je vais essayer avec EZ planetary et sharpcap.

Si je rencontre des difficultés je reviens vers vous.

easybob08 · 3 octobre 2013

Bon, j'ai essayé Sharpcap 2 sur mon petit netbook NC10 et ça marche MAIS le nombre d'images par secondes est catastrophique.

Pourtant, j'ai des trucs corrects avec Ezplanetary et Firecapture.

Sinon, ça marche (mal).

apollo04 · 3 octobre 2013

Oui j'ai trouvé dans EZ planetary comment faire des acquisitions longues

Pour les tests sur le ciel on verra plus tard !!

OrionRider · 3 octobre 2013

Je viens de tester la QHY5L-IIc pour l'autoguidage. Malgré le capteur couleur il y a bien plus d'étoiles qu'avec ma vieille SPC900. Les poses de 1sec sont très propres.

En revanche, PHD plante régulièrement. On sent qu'il a du mal à tourner avec cette caméra. Le logiciel ne répond aux clics de souris qu'après un délai. Encore plus ennuyeux, il se fige si on y touche pendant l'autoguidage, par exemple quand on appuie sur 'stop' pour manipuler l'APN. Chaque fois, faut forcer la fermeture et recommencer tout. Après, j'ai un vieux PC aussi... :cry:

benjamindenantes · 22 octobre 2014

Déterrage de post!

J'ai des questions concernant cette cam alors pourquoi pas ici. (version couleur)

Mes questions portent sur le paramétrage de la caméra pour le ciel profond.

Dans quel format de fichiers enregistrer les brutes et les dofs? .fit ou .tif?

J'ai tenté le .fit pour être gérables directement par iris.

Ensuite sur quel mode doit on mettre la caméra?

En 8bit raw (mono) en 14 bit couleur ou en 14bit raw (mono)???

Merci à ceux qui ont des résultats corrects en ciel profond de m'aider. Je patauge encore avec cette cam...

olivdeso · 22 octobre 2014

Pour DSS et autres, je dirais 14bits raw mono en .fit

(je ne sais pas si iris sait débayériser les .fit des CCD couleurs comme les .cr2 des APN)

OrionRider · 22 octobre 2014

Le format n'a pas beaucoup d'importance mais tu ne dois pas oublier d'activer le 'long exposure mode' dans les options sinon elle ne dépassera pas 3sec...

benjamindenantes · 22 octobre 2014

Pour DSS et autres, je dirais 14bits raw mono en .fit
(je ne sais pas si iris sait débayériser les .fit des CCD couleurs comme les .cr2 des APN)

C'est pas ce qu'il fait à l'étape de la conversion CFA? Il redonne de la couleur aux fichiers .fit à ce moment là. (qui ont été prétraités en noir et blanc).

Je suis en ce moment en train de tenter M27 avec 50% de gain, 50s de pose en mode raw mono 14bit. (avec ezplanetary)

@orion rider: Merci d'être passé par là. J'ai bien coché cette case.

Mon soucis c'est aussi que sur sur l'écran lors de l'acquisition l'exposition semble bonne (visuellement et sur l'histogramme) et que lorsque j'ouvre le tout sous iris ou dss c'est limite tout cramé. :?:

benjamindenantes · 22 octobre 2014

Je me retrouve avec ça sous iris... :?:

Alors qu'a la prise de vue le fond est gris mais sans plus et M27 est bien dessinée...

easybob08 · 22 octobre 2014

Salut,

en général, je fais les captures au format bmp. C'est pas ce qui est le mieux mais bon.

Donc, mode longue pose et en avant pour la map et les acquisitions.

Il est possible de faire des darks et de les soustraire à la volée mais ça n'est pas vraiment nécessaire.

easybob08 · 22 octobre 2014

Salut,

en général, je fais les captures au format bmp. C'est pas ce qui est le mieux mais bon.

Donc, mode longue pose et en avant pour la map et les acquisitions.

Il est possible de faire des darks et de les soustraire à la volée mais ça n'est pas vraiment nécessaire.

benjamindenantes · 22 octobre 2014

Salut,

en général, je fais les captures au format bmp. C'est pas ce qui est le mieux mais bon.

Donc, mode longue pose et en avant pour la map et les acquisitions.

Il est possible de faire des darks et de les soustraire à la volée mais ça n'est pas vraiment nécessaire.

En .bmp ??

C'est du 8 bit ça pour le coup tu perds en dynamique il me semble.

Tu n'as jamais remarqué un décalage entre la luminisité à l'acquisition et au traitement?

olivdeso · 22 octobre 2014

Je me retrouve avec ça sous iris...
Alors qu'a la prise de vue le fond est gris mais sans plus et M27 est bien dessinée...

ah c'est peut être une histoire de fichier en 16bits au lieu de 14...

Iris travaille en 15bits + bit de signe (valeurs entre -32768 et +32767)

Mais les fits 16bits de QHY de camera ciel profond (je ne sais pas pour la QHY5L-II) travaillent sur 16bits non signés (des valeurs entre 0 et 65535). Dès qu'on dépasse 32768, ça pose problème.

Mais pour la QHY5L-II qui est codée sur 14bits, je ne sais pas comment la conversion est faite pour le fichier fit 16bits. Vu les résultats que tu as, probable que les 14bits soient décalés de 2 bits vers la gauche (revient à multiplier par 4) et tu te retrouve avec des valeurs d'ADU élevées dans Iris.

En divisant les valeurs par 4, possible que tu retrouve une image semblable à celle que tu as en capture.

Il faudrait prendre une image saturée pour voir c que ça donne en ADU dans iris. essayer aussi en TIFF au cas où...

benjamindenantes · 22 octobre 2014

ah c'est peut être une histoire de fichier en 16bits au lieu de 14...

Iris travaille en 15bits + bit de signe (valeurs entre -32768 et +32767)

Mais les fits 16bits de QHY de camera ciel profond (je ne sais pas pour la QHY5L-II) travaillent sur 16bits non signés (des valeurs entre 0 et 65535). Dès qu'on dépasse 32768, ça pose problème.

Mais pour la QHY5L-II qui est codée sur 14bits, je ne sais pas comment la conversion est faite pour le fichier fit 16bits. Vu les résultats que tu as, probable que les 14bits soient décalés de 2 bits vers la gauche (revient à multiplier par 4) et tu te retrouve avec des valeurs d'ADU élevées dans Iris.

En divisant les valeurs par 4, possible que tu retrouve une image semblable à celle que tu as en capture.

Il faudrait prendre une image saturée pour voir c que ça donne en ADU dans iris. essayer aussi en TIFF au cas où...

Ok , je pense que le soucis c'est ça...

Donc sous iris en divisant par 4, je devrais retomber sur des niveaux équivalents a ceux de l'acquisition. Ca se tient bien en effet. Merci pour cette piste. Je teste ça avec la commande "mult 0.25" donc.

En parallèle j'ai relancer des acquisition en 8 bit en tiff.

Merci.

easybob08 · 22 octobre 2014

En .bmp ??

C'est du 8 bit ça pour le coup tu perds en dynamique il me semble.

Tu n'as jamais remarqué un décalage entre la luminisité à l'acquisition et au traitement?

oui, mais ça n'était pas très grave car c'était des tests rapides.

olivdeso · 22 octobre 2014

Ok , je pense que le soucis c'est ça...
Donc sous iris en divisant par 4, je devrais retomber sur des niveaux équivalents a ceux de l'acquisition. Ca se tient bien en effet. Merci pour cette piste. Je teste ça avec la commande "mult 0.25" donc.

oui en espérant que les données n'ont pas étés écrêtées... idéalement il faudrait faire la conversion avant iris.

benjamindenantes · 22 octobre 2014

oui en espérant que les données n'ont pas étés écrêtées... idéalement il faudrait faire la conversion avant iris.

Bon j'ai fais un mult 0.25 mais j'ai l'impression que j'ai une grosse perte.

le fond de ciel reste très chargé par rapport aux étoiles...

Conséquence d'un écrêtage peut-être?

Je suis quand même pas le premier à tenter le coup ave iris! Ca fait pareil avec dss en plus.

yannp29 · 23 octobre 2014

Salut,

Comme le dis Olivdeso, l'encodage des données pose problème.

Voir avec les commandes loadsx et convsx.

Dans le tuto il en est question au sujet du codage des données.

http://www.astrosurf.com/buil/iris/tutorial1/doc1_fr.htm

Amicalement.

Yann

Modifié 23 octobre 2014 par yannp29

benjamindenantes · 23 octobre 2014

Salut,

Comme le dis Olivdeso, l'encodage des données pose problème.

Voir avec les commandes loadsx et convsx.

Dans le tuto il en est question au sujet du codage des données.

http://www.astrosurf.com/buil/iris/tutorial1/doc1_fr.htm

Amicalement.

Yann

Merci,

Il faut donc passer par ces commandes avant d'ouvrir le fichier.

Si on ouvre le fichier sans l'avoir converti, j'ai l'impression qu'il est automatiquement écrêté et du coup la commande mult ne fait que réduire l'intensité des pixels. (écrêtés auparavant)

On avance, merci à vous.

francois-du-57 · 23 octobre 2014

bjr a tous je suis votre poste avec intérêt car je viens moi aussi d'acheter un qhy couleur et pour l'instant je n'est pas eu encore le plaisir de la tester a cause du temps...

j'ai télécharger pas mal de log pour cette ccd ,dont EZP,firecapture et APT.

pour peut que j'ai déjà vue ou lu ,je vois que certain galère.....

Tromat · 23 octobre 2014

Je n'ai jamais eu de souci pour le CP avec cette caméra. J'utilise Firecapture pour l'acquisition et Pixinsight pour le traitement. Fichiers enregistrés en 16bit me semble t il mais j'ai un doute sur ce point.

Le seul soucis que j'ai pu rencontré ce sont le offsets qui sont souvent problématiques, pour le reste ça roule.

Exemple :

OrionRider · 23 octobre 2014

J'ai juste fait M57 avec cette cam (version couleur) et le résultat était sympa mais on voit bien qu'elle n'est pas faite pour ça. Le champ est minuscule et la dynamique n'a rien à voir avec celle d'un APN, 16 bits ou pas.

Aussi le signal thermique est très présent et les étoiles empâtées, l'empilement automatique peut être vraiment difficile. Finalement, j'ai empilé en manuel avec Registax (150 frames!).

L'échantillonnage avec les tout petits pixels est aussi un souci, peu de montures sont capables de suivre avec une précision suffisante.

Modifié 23 octobre 2014 par OrionRider

Tromat · 23 octobre 2014

L'échantillonnage avec les tout petits pixels est aussi un souci, peu de montures sont capables de suivre avec une précision suffisante.

Oui c'est sur ce point que l'argument "CP à pas cher" s'effondre. La caméra est effectivement plutôt efficace en CP mais pour en profiter il faut un suivi solide donc une monture onéreuse.

benjamindenantes · 23 octobre 2014

Je n'ai jamais eu de souci pour le CP avec cette caméra. J'utilise Firecapture pour l'acquisition et Pixinsight pour le traitement. Fichiers enregistrés en 16bit me semble t il mais j'ai un doute sur ce point.
Le seul soucis que j'ai pu rencontré ce sont le offsets qui sont souvent problématiques, pour le reste ça roule.

Il me semble que tu as la version mono. Peut-être que du coup les fichiers sont capturés en 16 bit d'origine.

Avec la version couleur dans ezplanetary il y a une fonction d'enregistrement en 14 bit qui ouvre la possibilité d'enregistrer du .FIT. (le format que j'espérais utiliser)

Pour les offsets ont dirait que la cam les fait à la volée...

Il semble ne pas y avoir de soucis en revanche avec le .tiff mais j'ignore s'il sort en 8 ou 16 bit. ???

@orion rider: toi tu enregistres en .tiff? traitement dss?

Modifié 23 octobre 2014 par benjamindenantes

OrionRider · 23 octobre 2014

@orion rider: toi tu enregistres en .tiff? traitement dss?

Oui, mais j'ai dû empiler avec Registax en alignement manuel car les brutes étaient trop moches, DSS n'arrivait pas à aligner en automatique.

Pourtant j'étais limité à 30sec par la monture (f/10 à 0,5"/pixel) mais le bruit était quand même énorme.

Autant elle marche bien pour l'autoguidage et le planétaire, autant pour le CP c'est pas forcément un bon plan... :confused:

Connexion

QHY5L-II et ciel profond

Messages recommandés

Les pipelettes du sujet

Les pipelettes du sujet

Rejoignez la conversation !

En ligne récemment 0 membre est en ligne

Annonces

Aider Webastro

Information importante