180Vision

Oui oui, c'est juste que je n'avais pas la fonction et que globalement maintenant je vais faire le RGB avec la RAF et la mono pour avoir une résolution unique car sinon pénible à gérer...

Alors sur la PSF, j'avais creusé la question et regardé de quoi il en retournait déjà oui, en outre pour la deconvolution ensuite. Là pour le coup il apparait qu'il est préférable de le faire sur du "non-stretched", sinon je trouve qu'on ne voit pas l'effet... Idem pour le denoise Siril, je n'ai pas trouvé cela flagrant mais de toute façon ça ne fonctionne pour moi que sur les linéaires aussi. J'utilise l'algo VST à moitié environ, comme vu ci et là...et toi ?

Oui oui, j'ai joué déjà avec les formules en effet mais ajouter du Ha a 100% de rouge sur une objet déjà peut être jaune orange accentue nécessairement cette tendance non ? Sur M81 par exemple. Après, c'est pas vilain mais est ce "réaliste"...? J'ai vu qqn extraire la rouge du Ha partiellement (ce qui revient au meme) mais intégrer aussi une proportion a la couche bleue pour simuler le Hb ... Bref, il y a de quoi jouer... De mon côté, mes principales erreurs sont de ne m'être pas mis à PIX encore...et aussi d'avoir mené mes essais sur des images stretched ...ce qui semble ne pas être le mieux

J'ai cette même config et idem, je n'ai pas détecté de souci, me demandais donc s'il s'agissait juste de chance... merci pour la confirmation de tout ça, pas toujours évident d'être certain d'être sur la bonne voie En tant que musicien, la camera est fixée au gaffer même

En fait @sebseacteam la formule pour la composite RHa ajoute neccesaireem du rouge à la couche R (R+(ha-med(ha) *5) non ? Donc pas illogique de voir rouge. Ai je loupe Qqc qq part....?

OK, j'avais quand même plutôt bien compris la chose... En fait pour tout dire, comme ce sont des rgb issues d'une osc sans dithering mais que j'aimerais mettre à profit qd même, et que la résolution est plus petite... Mettre à la même dimension que les monochromes me permet du coup d'utiliser ça pour la partie couleur même si la netteté baissait du fait du reechantillonage... Donc à priori, ça confirme bien que la qualité des détails sur cette session rgb pourrait faire le job... Pour le drizzle, je suis moi aussi en 1.43" avec ma 72ed et donc je vais suivre ton expérience vu que la j'ai du dithering effectif sur ces sessions de la monochrome... Merci à tous les deux pour vos éclairages et confirmations !

Oui un linearmatch dans siril de chaque image avec la L...

@sebseacteam je rebondis sur ce fil car mes essais hargb avec ta formule me donnent des résultats avec des tons rouges oranges bien présents, pas illogique si o n considere ha comme du rouge...mais...j'avais l'impression dans tes images ou d'autres que des bleus ressortaient, je me trompe ?

Bonsoir! Lors d'un assemblage d'une couche luminance et d'une image rgb, selon moi, la résolution de l'image couleur peut être augmentée par suréchantillonnage sans dégrader la qualité des détails de l'image, non ? Peut on d'ailleurs faire un drizzle même si aucun dithering n'a eu lieu a la prise de vue ?

Ok oui, en effet, je croyais que tu avais un phénomène autre Je connais oui phd log viewer, mais merci ! Bon, de mon coté, je démonte ma lunette+caméra telle quels que je range en boite mousse et remets lors des sessions. Fixation sur arronde double-vis ajustée. A priori, pas eu de souci de "par en sucette" Et sur le retournement au méridien, si en EQMOD, normalement pas de souci outre mesure non ? Ceux qui rencontrent le pb sont ceux qui guident en ST4 pour lequel pas d'info DEC, c'est ça ?

Quand tu dis que tu ne touches pas à la lunette guide, tu veux dire à la caméra sur la lunette guide ou bien tu ne démontes même pas la lunette guide du tube principal ? Comment estimes-tu le "ça part en sucette" ?

Bonjour, Avez-vous une référence/conseil pour une boite de rangement (type pelicase ou autre) permettant de ranger/sortir en un bloc la partie "imaging" de la chaine optique, à savoir correcteur---roue à filtre---caméra ? La roue à filtre étant de type Zwo EFWx5, se pose un problème d'encombrement "vertical" et donc de hauteur, d'où ma question. Ayant pris l'habitude de démonter en monobloc toute cette partie avec jusqu'ici le tiroir à filtre afin de ne pas générer de rotation et conserver ainsi un temps les flats, j'aurais aimé conserver cette pratique.... MErci à vous !

Bonjour chers/chères astrams ! Je viens avec une nouvelle question LE sujet du jour : la re-calibration de PHD2 (via NINA ou non). J'ai pu écouter et lire un peu de tout sur le sujet ... De mon coté, j'ai cru comprendre, sous condition d'être en EQMOD (et non ST4), que si l'ensemble lunette guide-caméra reste solidaire sans bouger (rotation), pour un même lieu/positionnement, la calibration faite dans PHD2 pouvait être conservée pendant un certain temps (à l'instar des librairies de darks qq part ) Autrement dit, dans NINA, que ce soit en tant qu'instruction initiale qu'en retournement de méridien (ou certains recalibrent alors systématiquement), forcez-vous la calibration ? En ayant activé l'option "restaurer la calibration" de PHD2 et en ayant validé une première bonne calibration évidemment, peut-on conserver celle ci plusieurs mois pour un même setup ? Sous quelles conditions exactement ? MErci de votre retour d'expérience !

Oui, dans le cadre standard de fonctionnement, c'est sûr que c'est pas inintérressant !

Cyril, oui, c'est ça et il m'a fallu de l'expérimentation car j'ai lu à peu près tout et n'importe quoi comme affirmations sur le sujet lol... En fait, ce n'est pas tout à fait exact mais il faut avoir un mix entre chance et persévérance. Admettons une caméra RGB 8Mp qui donne un fichier stacked_rgb.fit et une caméra mono de 20Mp un fichier stacked_mono.fit Si l'on renomme en stacked_00.fit et stacked_01.fit respectivement et que l'on fabrique une séquence des deux fichiers + conversion, alors le fichier RGB sera pris en référence et affiché avec les 4 onglets dans la preview. Il est possible alors de lancer un alignement et donc d'obtenir sur le canal 1 (vert) et obtenir deux images r_xxx réduites donc à 8Mp bien sûr (avec cadrage quasi identique à l'origine évidemment sinon résolution encore moindre) D'autres configurations/ordre de fichier font systématiquement planter Siril, y compris dans la liste d'image en essayant de changer d'image, pour info. Après, perso, nous ne devons pas être nombreux à faire cela, je pense qu'il faut pas se prendre la tête la dessus à vouloir couper les cheveux en 4...

@lock042@m27trognondepomme Si capteurs différents mais de même type (tout mono par exemple), oui. Sinon, de mes essais (divers capteurs), pas si easy à faire fonctionner (en outre crashes au chargement de séquence), alors en automatique/script, je pense que ça va être ardu.

Bonsoir ! Une M101, première "vraie" capture un peu plus aboutie multi-sessions. 30x60s RGB sur Uranus-C (LPRO) 120x60s Luminance sur QHY183M (LPRO) 50x90s Ha sur QHY183M Siril + PS Cadrage perso "pano"

Alors Je dirais oui et non selon ce qu'on attend, malgré certaines réponses vues qui infirment ou confirment selon les expériences... Bon, déjà, une séquence faite avec une FIT RGB et une FIT MONO, selon quelle image on prend en référence, Siril crash direct en cliquant sur "image de référence" ou en ré-ouvrant la séquence (avant la 1.2 aussi)....qu'il faut nettoyer à minima. Ensuite, faire l'assemblage en séparant les canaux, composition RGB ensuite avec la mono en luminance...idem, selon la config, ç'est soit refusé, soit cela génère des pixels colorés non alignés (malgré alignement dans la fenêtre...)... Je n'ai pas essayé par contre la fusion de deux caméras de même type (MONO toutes ou RGB toutes)...uniquement une RGB (ou APN, même résultat) de résolution plus faible qu'une seconde, monochrome. Ce qui fonctionne par contre : - Pré-traitement mono et rgb séparés jusqu'à empilement. - Ajout d'une séquence avec les images résultantes, référence sur la plus petite en résolution (ou alors il faut ré-échantilloner avant...) - Alignement (bien choisir le canal 1 pour RGB ou 0 pour L, sinon crash) - Récupération des images r_xxx issues de l'alignement dans le répertoire - split RGB de l'image couleur - linearmatch avec la mono de chaque couche R,G,B - Assemblage à convenance avec différentes couches, par composition ou PS ou PixelMath (y compris couche Ha si besoin) (Avec la dernière modif SIRILIC faite (édition script), on peut faire un ou deux Ctrl+H et compléter en fin avec ces actions modèles...ça le fait...) En résumé : ça va pour un équipement mixte et pas de roue à filtre (momentanément mon cas), mais pas hyper friendly car je pense que ça dépasse le cadre d'application... A mon avis, cas limite compliqué à prendre en charge et il est préférable je pense de profiter de nouveautés en traitement que de régler ces cas de figures..."tordus"

Re @m27trognondepomme, Pour l'option d'édition/exécution du script, tu me valides la procédure ? : - Actions/Etape1 -> pour générer /linker/nettoyer - Dans le répertoire Work/Objet/scripts -> Edition du script avec NOTEPAD par exemple - Actions/Alternative : Editer le script et l'exécuter C'est ça ou je suis à coté ? Si c'est bien le cas, j'ai fait 2 fois l'essai pour être certain, le script modifié est remplacé... EDIT : Désolé, j'ai fouillé et vu l'option pour l'éditeur dans les préférences. C'est bon, ça fonctionne !!

Non mais faut pas non plus se prendre la tête. En fait, pour ce qui est de l'assemblage final, quoiqu'il en soit, cela exige d'autres manipulations. MAis le "registering" des couches qui est néanmoins lancé serait un plus, uniquement. Encore une fois, j'imagine qu'il y a bien d'autres priorités que cette évolution, pas de souci ! Merci de la réponse !

Génial @m27trognondepomme, je vais aller tester ça de ce pas, merci ! En outre, pour info, dans le contexte suivant (RGB fait avec un caméra OSC, autres sessions via une mono) : Sirilic copie chaque sortie (RGB / L / Ha) vers ../Temp sous le nom Cxx.FIT Or, dans cette configuration, le .fit RGB est copié vers "C-1.FIT", L vers "C00.fit" et Ha vers "C004.fit" Lors de la phase "register C -2pass....", cela échoue imanquablement (fichier r_C-1.fit introuvable) ! En changeant le nommage en C00.fit pour le RGB, C01.fit pour L et C04.fit pour Ha, le registering final fonctionne alors... Voila, si ça peut aider, au cas où d'autres soient dans mon cas.

Pour reprendre les propos de Sam, en effet, le tilt (disponible aussi dans Siril dans le menu haburger/PSF), semble important...bizarre sur un objetif "baillonné" au boitier... Peut être vérifier que rien ne gêne "l'enclenchement"/blocage en position verouillé entre la base de l'objectif et la baillonnette afin d'écarter déjà ça (et que rien ne force en torsion). La rotation de champ est potentiellement en effet un effet donnant une déformation fuite mais ce qui est curieux c'est que c'est relativement uniforme sur ta photo au centre comme extérieur... Je me permets une remarque au sujet de la 72ED, au cas où tu envisages de la monter sur la monture LX4...ça risque de faire court niveau poids (mais peut être n'as tu juste pas mentionné d'opter pour une monture autre).

Je plussoie... J'intègre par exemple du RGB issu d'une autre caméra couleur de résolution différente, avec des sessions monochrome d'un QHY...l'édition du script pour faire la séparation des canaux + opérations diverses...ça serait top

En effet, belle procédure, je vais m'y tenter... Tu fais avec une appli pour relever les hauteurs en degré ?

Bonjour à toutes/tous, Une première pose de Luminance (avec Lune pleine quasi) seule pour cette galaxie de l'Aiguille (NGC 4565 / C38) dans la chevelure ! Deux sessions : 60x120s 60x90s (+DOFs) QHY183M (G10/O8) sur la 72ED + HEQ5Pro Filtre L-PRO sous la Lune Guidage PHD2 via GPCAM / Guide 30 f/4 A compléter encore en Luminance et surtout session couleur !