lock042_CyrilRichard

Member
  • Content count

    522
  • Joined

  • Last visited

  • Country

    France

Everything posted by lock042_CyrilRichard

  1. Version couleur de NGC 7822

    Bonjour, suite à ce poste : j'ai enfin eu l'opportunité de rajouter la couleur, avant l'arrivé du mauvais temps. Le traitement a été plus difficile car je me suis rendu compte que le Samyang 135mm a un vignettage terrible en RGB. Or, avant j’utilisais un 200mm de canon ne nécessitant pas de flat. Ici il a donc fallu que je remonte l'objectif et que je fasse des flats. C'est donc pas du tout l'idéal et j'ai du faire avec un sale gradient résiduel qui a été très chiant à traiter. Vos commentaires sont les bienvenus. Les données techniques sont les suivantes : 66x120'' / Ha - 6nm 122x60" / RGB iOptron SkyTracker + Canon100D + Samyang 135mm f/2 ouvert à 2.8 Traitement avec Siril 0.9.12 beta + GIMP + Darktable
  2. Version couleur de NGC 7822

    Ton message étant tellement vraie, j'ai apporté des modifications et produit une nouvelle version. Qu'en pensez-vous ?
  3. l oeuf au plat (M31) fuji iso max

    Sisi. Mais faut bien regarder les infos données en console.
  4. l oeuf au plat (M31) fuji iso max

    Et aussi, il y'a l'astrométrie de Siril qui informe si l'image doit être retournée ou non :).
  5. l oeuf au plat (M31) fuji iso max

    Il y a pu avoir d'autre manip sur d'autres softs. Je connais très bien ce soucis d'images inversées et ca ne se produit pas si on utilise Siril de A à Z. Je le saurais depuis le temps. C'est à cause de la façon différente dont les logiciels enregistrent les FITS.
  6. l oeuf au plat (M31) fuji iso max

    Non. Siril n'inverse pas. D'autant plus sur des images d'APN faite avec siril de A à Z. Il peut y avoir une inversion quand siril travaille avec des FITS fourni par des logiciels tiers qui enregistrent les data dans l'autre sens.
  7. Version couleur de NGC 7822

    Merci pour vos gentils messages. Ces images Ha + RGB me permettent de développer des outils pour Siril 0.9.12. Du coup c'est bien. En plus, j'ai rarement autant utiliser le logiciel donc je peux corriger les bugs :). La casse à cause des mauvais flats ... Très dur à récupérer. Le piqué du 135 me semble meilleur, mais bon, la focal est bien moindre. Le 200mm de canon (qui est de la série L) est au dessus à mon avis car le vignettage est quasiment nul et je ne faisais pas de flat. Ce qui explique que je me sois fait piéger.
  8. NGC 7822

    Les données techniques sont les suivantes : 66x120'' / Ha - 6nm iOptron SkyTracker + Canon100D + Samyang 135mm f/2 ouvert à 2.8 Traitement avec Siril 0.9.12 beta + GIMP + Darktable
  9. Traitements Siril

    Tu peux contacter le développeur de Sirilic, il répondra a tes questions.
  10. Traitements Siril

    Les deux logiciels n'ont rien à voir. Sirilic a besoin de Siril pour marcher. Sirilic créé des scripts. Oui mais pour ça il faut du temps. Or, coder des logiciels prend déjà beaucoup de temps. Moi personnellement, à choisir, je préfère investir le peu de temps que j'ai dans une journée (qui ne fait que 24h, et je compte pas le boulot, les activités dans le jardin, les enfants et tout le reste) dans le développement logiciel. Donc, oui, les docs je laisse ça aux autres. Deux logiciels séparés, voir plus haut. Sirilic est un utilitaire qui permet de faire des scripts, mais aussi de lancer siril en tache de fond si on le souhaite.
  11. Tuto traitement pose rapide sur Siril

    Même en 16bits c'est pas bon.
  12. Traitements Siril

    Pour ca il y a l'utilitaire sirilic.
  13. Tuto traitement pose rapide sur Siril

    Faire un stacking par somme, empile les images par somme sur 32 bits puis normalise sur 16bits. Ca fait que la valeur max est de 65535 (si on a bcp suffisamment de dark pour atteindre la valeur max en 32bits : 2^(32), ce qui m'étonnerait quand même). Cependant, on soustrait donc aux lights un dark avec une valeur biaisé. Alors que nous ce qu'on veut faire, c'est une moyenne. Comme j'ai dit, pour les darks on ne normalise pas en 16bits sur la moyenne. Car quand on va soustraire le dark aux lights, on ferait du 8bits - 16bits et ca donnerait des trucs tout noir. La conversion 16bits se fait lors de l'empilement des lights prétraitées. Bien sûr, si tu shoot direct en 16bits pas ce soucis.
  14. Tuto traitement pose rapide sur Siril

    A éviter totalement !!! SUrtout si on enregistre en 8bits (mais même en 16bits aussi, car ca change totalement la dynamique et le dark aura un trop haut signal lors de la soustraction).. Il faut empiler par moyenne tous les DOFs et décocher la case de normalisation & 16bits si on shoot en 8bits. On la recochera lors du stack de la vidéo light.
  15. NGC 7822 à 135mm de focal (Ha)

    Merci pour vos messages. Je vais essayer de faire la RGB ce soir, en début de soirée. Ensuite en combinant la couche R a la Ha je pense qu'on ne verra plus trop le bruit.
  16. NGC 7822 à 135mm de focal (Ha)

    Bonjour tout le monde. Encore une semaine de beau temps !!! Alors on en profite pour tester un 135mm de chez Samyang que j'ai en prêt. Quelle bonne idée !! C'est un excellent caillou que je conseille à tous : il a un super piqué. J'ai cherché une cible, j'étais un peu à court d'idée. mais on m'a alors suggéré de faire NGC 7822. Honnêtement je ne la connaissais pas et j'ai donc jeté un œil à wikipedia. La phrase m'a encore plus motivé à m'aventurer dans cette région HII. J'espère lui faire la RGB prochainement, bien que ma seule prochaine fenêtre semble être vendredi et que la Lune sera encore là en deuxième partie de nuit. Je vous présente donc le premier jet de cette nébuleuse prise hier, avec les EXIFs, et si vous avez des remarques et commentaires, n'hésitez pas :  L'étoile, si je ne me trompe pas, ce trouve là : Les données techniques sont les suivantes : 66x120'' / Ha - 6nm iOptron SkyTracker + Canon100D + Samyang 135mm f/2 ouvert à 2.8 Canapé + séries américaines à la con pendant les poses Traitement avec Siril 0.9.12 beta + GIMP + Darktable
  17. Tuto traitement pose rapide sur Siril

    On peut le faire sous siril maintenant ça aussi
  18. Tuto traitement pose rapide sur Siril

    Via le site officiel tu as accès à des cours en ligne gratuit. Tu auras tout ce que tu veux la bas.
  19. BD+66 1673

  20. NGC 7822

  21. NGC7380 nebuleuse du Sorcier / IMX224

    Justement. Si un empilement en temps normal (et même sur des petits capteurs) prend plusieurs heures c'est parce que les calculs sont nombreux et complexes. Or, dans un livestack on en fait beaucoup moins pour gagner en vitesse et garder l'esprit live. Donc non, on peut pas faire qqchose d'aussi bien en live, c'est mathématique. Le livestack se rapproche du "sum stacking" de Siril en terme d'algorithme. Si après chaque pose on cherche a réévaluer on va très vite s'éloigner du live. Par exemple, calculer une médiane du stack (souvent nécessaire dans le rejet des pixels) nécessite de connaître toutes les valeurs du stack et de les trier (pour certaines approches algorithmiques). Un rejet de pixel type linear fit clipping nécessite lui de connaître tout le stack pour faire un ajustement des data ainsi qu'une minimisation par méthode des moindres carrés. Notre méthode de normalisation contient des algorithmes qui sont très performant mais intrinsèquement lent, avec minimisation ici aussi. Bref, encore un truc ou on a besoin de tout. Moralité : on n'a rien sans rien. Crois moi, on essaye constamment de réduire le temps d'empilement dans Siril. Ça passe par de grosses optimisations (choix d'algorithmes plus rapides), mais on ne peut pas faire de miracles. Et si les algos sont lents, c'est qu'ils permettent de faire des trucs que ne font pas les plus rapides. En fait, à mon sens, c'est l'inverse. C'est bien dommage que sharpcap (ou autres) ne soient pas libres :). Leur implémentation non, mais une implémentation oui. C'est chose prévue dans Siril.
  22. NGC7380 nebuleuse du Sorcier / IMX224

    Pas seulement non. Et si sharpcap prend du code de siril il faur respecter la GPL et publier le code correspndant. Pas sûr que ca les intéresse . Sinon, non le live ne peut pas obtenir de meilleur résultat qu'un traitement classique. Ce qui fait que le traitement classique est meilleur c'est justement qu'on a tte les photos en amont pour pouvoir faire une normalisation, des rejets de pixels (qui necessitent les stats du stack complet, etc ....), et aussi, choisir une image de référence.
  23. T'as une selection des frames sur plusieurs critères stellaires
  24. A ton avis Et fait des SER !!
  25. IC1396 en SHO au C11

    En fait, j'aime pas trop le nom de "SUpression de bruit vert" mais je ne savais pas comment l'appeler. Photoshop a un plugin Hasta la vista Green, PixInsight Subtractive Chromatic Noise Reduction. Mais pour moi on ne supprime pas vraiment du bruit. Disons que cet algo part du postulat que dans l'espace, hormis les comètes et certaines NP, rien n'est vert. Donc si tu as des pixels de couleurs verte c'est du bruit. En fait c'est un peu plus compliqué car ca peut être a cause de l'espace de couleur dans lequel tu bosses, d'un mauvais étalonnage de couleur, ... Bref, cet outil est souvent utilisé la ou il ne devrait pas. Ici par exemple, c'est une belle utilisation détournée qui consiste a remplacer les pixels verts (dans l'espace de couleur inverse) par une combinaison des pixels rouges et bleus.