Siril: taille différente sur les offsets

[Leboot]

Salut!

j'aurais besoin de vos lumières sur une petite étrangeté que je ne comprends pas:

J'ai fait une session test de l'AZgti bien chargée (4,5kg) cette nuit. j'utilise Ekos dans la dernière version que mon vieux mac accepte (3.5.8), et cette version comporte un bug concernant la capture des offset (je viens de trouver l'article et pourrai contourner le problème), et j'ai donc dû les faire a part, directement sur l'apn canon.

j'ai donc tout en Fit, sauf les offsets qui sont en CR2.

Si je regarde la taille des images (Ligths et DOF), ils sont tous de la même taille 5184x3456 (qui est la bonne!), seulement, si je lance le process, il s'interrompt car le master bias se retrouve avec une taille différente de 5202x3464px, et forcement, ça ajourne le process...

une idée du pourquoi du comment? le fait d'avoir du fit et du cr2? (mais d'où viennent ces pixels...?🤔)

merci!🙂

et il y a eu un gros problème sur les darks... oui oui....

[Batbihirulau]

Salut,

Il me semble que ce genre de phénomène a déjà été examiné.

Le fait d'utiliser des images provenant de différents soft ouvre juste la porte à tous ces soucis.

D'ou la régle d'or: 1 seul soft our les DOF et Lights.

 

Sinon, à la question: peut on grignoter les pixels en trop sur les bords?

Non, parce que là, il ne servirait plus a rien d'essayer d'aligner quoique ce soit.

 

S'il ne s'agit que des offsets; tu peux toujours les refaire sans que ça gene le process.

Je veux dire que ce n'est pas aussi sensible que les flats.

Offsets et darks peuvent etre réalisés ou refaits à posteriori.

 

[vinvin]

tout à fait, et si c'est que les bias, autant ne pas en utiliser si ça convient à cette caméra, comme décrit ici : https://siril.org/fr/tutorials/synthetic-biases/

ça peut sauver des sessions, et ça évite de se trimbaler des Go d'offsets par la suite

 

(et oui donc prendre des images en FITS ou en CR2 ne donne pas forcément la même taille, le processus de conversion est complexe)

[keymlinux]

Bonjour,

 

Cela ne vas pas t'aider, mais j'ai déjà été confronté au même problème (6000x4000 en FITS, 6024x4020 en RAW CR2). Une fois qu'on a fais l'erreur une fois on ne la refais plus (même si ici dans ton cas ce n'est pas vraiment une erreur, le bug kstars ne te laisse pas trop le choix).

 

Vu que tu est obligé de prendre des CR2 vu le bug Kstars, pour les fois prochaines tu devrait prendre aussi en CR2 (mais via kstars) les lights et autres (oui on peut le faire c'est parametrable)

Sinon, pour le session déjà effectuée, tu devrais regarder sur la carte SD de ton APN si il n'y a pas les CR2 des lights et dark (lorsque kstars pilote mon APN, il telecharge des fils, mais les cr2 sont bien enregistrés sur la carte, cela fait un peu doublon, mais cela peut aussi rendre service)

Sinon, tu peux aussi abandonner les offsets, et remplacer cela par un offset synthétique, cela marche très bien (je ne fais plus d'offset)

https://siril.org/fr/tutorials/synthetic-biases/

 

edit: argh, grillé par vinvin

 

[Leboot]

Salut!

merci pour vos réponses! 
je voulais avant tout comprendre le pourquoi 👍🏻
pour ekos, le problème peut être contourné en faisant simplement les offsets sous un autre intitulé (dark ou autre), je pensais que c’était les poses très courtes qui amenaient au bug, mais c’est bien l’appellation « bias » (bug référencé…)

mais je vais m’intéresser aux synthétiques, merci pour l’info.

Et je vais en effet soit refaire des offset pour le coup, ou voir si tous les cr2 sont sur la carte (logiquement oui en effet), je ne l’avais pas avec moi, j’avoue avoir lancé le traitement et constaté… au boulot! 😅

 

Il y a 8 heures, keymlinux a dit :

d'offset)

https://siril.org/fr/tutorials/synthetic-biases/

Tres intéressant ! 👍🏻 Et i instructif ! Encore tellement à lire!!😅

Modifié 7 octobre 2022 par Leboot