acquisition/conversion/traitement des sequences, ccdciel/sirilic/siril

euldulle · 27 octobre 2018

Bonjour,

(résumé rapide : proposition pour embarquer/traiter les informations de séquences d'images dans les fichiers

fits plutôt que dans le nom des fichiers ce qui est une source d'emmerdes sans fin amha).

Les quelques arrachages de cheveux que je me suis fait avec les scripts sous siril

venaient de là, et je crois que les problèmes récents de Colmic sont du même tonneau.

Ce qui pose problème c'est l'ambiguïté entre le nom du fichier et son contenu, et en déportant

l'information du contenu du fichier vers le nom du fichier, on met le doigt dans un truc pas propre (conceptuellement

parlant).

Or, les spécifications du format fits sont telles qu'elles permettent d'embarquer dans un fits tout ce qu'il y

a besoin de savoir sur un fichier donné ; déporter ces informations dans le nom du fichier est un réflexe

naturel mais c'est potentiellement bordellique (comme tout ce qui duplique de l'information sans

préciser où est la source primaire).

J'explique où je veux en venir :

si on a un répertoire avec que des fichiers fits, bien formés, avec juste un header "FREQ" (filtre) et un header "IMAGETYP" bien renseignés,

siril (ou tout autre soft de traitement) devrait pouvoir se démerder tout seul pour construire les séquences dont il a besoin uniquement

sur la base de ces données-là. On peut même aller plus loin et ajouter un header "PROJECT" pour une image à laquelle

on veut ajouter les donnés de plusieurs nuits d'observation.

Donc siril cherche dans son répertoire de travail toutes les images "projet", parmi elles fabrique une séquence avec celles

qui sont de type dark, une autre avec celles de types bias ; ensuite pour les types "flats" et "light", on fabrique les

séquences qui vont bien pour chaque bande, et une fois qu'on a toutes ces séquences, on crée le script et on l'exécute.

La punchline : "tout ça complètement indépendamment du nom du fichier ou du répertoire dans lequel il se trouve"

Ça c'est pour du CCD ; prérequis : le logiciel d'acquisition est en charge de remplir les headers de manière compatible

avec cette approche (c'est déjà quasiment le cas pour ccdciel ; il suffirait de standardiser quelques valeurs pour ces headers.)

Je réfléchis en même temps que j'écris il faut un header IMAGECPS qui vaut STACKED pour une image stackée ou SEQ pour

une image partie d'une séquence, et dans ce dernier cas IMAGESEQ est le numéro de l'image dans la séquence. Ça ne dispense

pas de nommer les fichiers en fonction de ce qu'ils contiennent, mais la source primaire de l'information est toute entière

dans le fichier lui-même, et donc peut être extraite indépendamment du nom de tfichier.

(Les APN demandent une surcouche puisque le renseignement des headers doit se faire au moment de la conversion : donc si siril

est en charge de la conversion, il faut qu'il prenne en charge le renseignement des headers fits. Typiquement, si j'ai un flat_2018.cr2,

je veux en sortie trois fits avec le nom qu'on veut mais surtout les 3 headers IMAGETYP, FREQ, PROJECT remplis ; bref on parlera APN

après, une fois que la structure CCD sera arrêtée).

Donc on a des champs fits qui permettent de gérer toute la structure :

IMAGETYP :

flat, bias, dark, ...

FREQ :

Red Green Blue Light Ha Oiii H Ca...

PROJECT :

(user defined)

IMAGECPS :

SEQUENCE ou STACKED

IMAGESEQ :

1...N

EXPTIME :

exposure time

Une fois qu'on a cette structure-là bien en place, on écrit un petit makefile qui va bien et à la fin on fait un truc genre

make PROJECT

dans le répertoire qui contient toutes les images en vrac et on va se coucher.

Le lendemain on refait des images, dans le même répertoire, et en fin de nuit on fait :

make PROJECT

sans avoir rien à renommer ni à déplacer.

et on reva se coucher.

Le lendemain, on fait des acquisitions Ha, on rajoute "Ha" dans le makefile, on fait

make PROJECT

et on y retourne.

Trop cool.

Qu'en disent les principaux concernés (et au premier chef les devs de siril/sirilic/ccdciel) ?

--

fm

lock042 · 27 octobre 2018

Hello.

Bon j'ai rapidement parcouru et ta solution est loin d'être ideal a mon avis.

Déjà des keywords non standard c'est pas très pérenne comme situation. Ensuite ca nécessiterait que lors du stacking siril ouvre tous les fichiers et fasse le tri. Notre algorithme de stacking nécessite deja d'ouvrir tous les fichiers en même temps. Si en plus de ca on ouvre ce qu'on utilise pas...

Bref pour moi c'est pas très viable comme solution

Modifié 27 octobre 2018 par lock042

euldulle · 27 octobre 2018

Les fichiers tu les ouvres sans les ouvrir, tu as une lib fits qui te permet de lire les entetes et

c'est ça que tu utilises pour construire tes séquences au lieu de les construire à partir des noms

de fichiers ; le temps que ça prend est epsilonesque et la mémoire nulle :

fmeyer@ganymede:~/astrolab$ time fitshdr Flat_20181024_165101.fits >/dev/null                                                                                                                                                                                                  
real    0m0,009s
user    0m0,001s
sys     0m0,009s

Une fois que tes séquences sont construites, tout le process est inchangé.

Ensuite sauf si je me trompe, les keywords dans fits ne sont pas standardisés, c'est le format qui l'est

(il me semble que les keywords ils sont définis instrument par instrument, et leur description fait

partie du "manuel utilisateur" des grands instruments).

Les amateurs ne sont pas un "grand instrument", mais s'ils ont des besoins spécifiques qui ne sont

pas couverts par les KEYWORDS usuels, rien n'interdit de les créer s'il y a un vrai besoin. Et je pense

vraiment qu'il y a un besoin spécifique parce que je crois que tout les amateurs produisent leurs images

à partir de séquences, et que ça n'a jamais vraiment été intégré au niveau FITS.

--

fm

vinvin · 27 octobre 2018

Si on écrit une spécification à destination des logiciels d'acquisition ça pourrait marcher. Pour le SER par exemple, ce sont les logiciels d'acquisition amateurs qui ont défini la façon de les utiliser, et certains mots clés du header FITS aussi. Mais de même qu'avec le nom de fichier, c'est la responsabilité de la personne qui utilise le logiciel d'acquisition de bien remplir ces champs, donc ça ne change pas grand chose au fait de traiter des fichiers bien nommés. Je comprends que ce soit plus facile d'identifier les fichiers automatiquement avec les mots clés.

Entre le moment où tu as les fichiers dans un répertoire et le moment où tu fais ton make project, il faut quand même définir certaines choses : quelles filtres/couleurs prendre et de quelle façon les combiner dans l'image finale, que faire si des images n'ont pas le même temps d'exposition, comment filtrer les images au niveau de leur qualité (pourcentage, valeur minimale d'un paramètre) ? Donc actuellement, ça reviendrait à écrire un script pour siril qui le fait ou utiliser sirilic je suppose pour le faire, donc ça ne change pas grand chose non plus, mais à terme ça pourrait être un peu tout abstrait et rendu plus simple oui.

Ce que je me demande en lisant ta proposition, c'est : comment font les professionnels ? Un astronome qui va au VLT pour obtenir des acquisitions revient avec un tas de FITS. Comment sont-ils organisés ? Avec quels outils les traite-t-il ? Peut-être qu'avant de réinventer la roue il faudrait répondre à ces questions, dont les réponses doivent se trouver sur le site du VLT ou d'autres observatoires.

lock042 · 27 octobre 2018

Alors pour avoir bosser sur des FITS d'observatoire professionnel dans le cadre de mon taf (Observatoire Solaire Themis), tout est dans le titre et c'était pas le header qui définissait quoique ce soit.

gerard33 · 27 octobre 2018

il y a 17 minutes, vinvin a dit :

Ce que je me demande en lisant ta proposition, c'est : comment font les professionnels ? Un astronome qui va au VLT pour obtenir des acquisitions revient avec un tas de FITS. Comment sont-ils organisés ? Avec quels outils les traite-t-il ? Peut-être qu'avant de réinventer la roue il faudrait répondre à ces questions, dont les réponses doivent se trouver sur le site du VLT ou d'autres observatoires.

Je regardais une brute du TBL (Pic du Midi), il y a plus de 150 entrées dans l’entête

et on peut en rajouter, c'est géré comme une base de donnée

rien n'empêche de rajouter des champs mais pour que tous les softs d'acquisition utilisent des champs compatibles il ne faut pas rêver

sinon, c'est assez facile à manipuler avec la dll qui va bien

Iris le fait non? me souviens plus

vinvin · 27 octobre 2018

C'est pas techniquement difficile, et je pense que les développeurs de ces logiciels sont assez compréhensifs et ça ne leur pose pas de problème d'intégrer ce genre de chose, j'en ai déjà fait ajouter sans problème.

lock042 · 27 octobre 2018

Les gars de cfitsio (NASA) sont également très sympa, je leur ai fait changer des choses facilement.

C'est juste que je reste pas convaincu de faire un truc qui fait tout auto à partir de l'entête. Je suis peut-être un vieux con réac' :).

gerard33 · 27 octobre 2018

Sûr que le nom explicite du fichier en cours de traitement comme Siril, Iris, ou Pix pour ne citer qu'eux est beaucoup plus "lisible" pour l'utilisateur qu'un champ dans une entête fit

rien n’empêche le soft d'utiliser le contenu, par ex l'astrométrie , la datation, la taille du champ, etc

lock042 · 27 octobre 2018

Ah mais siril utilise deja beaucoup beaucoup de champs situés dans l'en-tête. Notamment pour le nouvel outil d'astrometrie. Et j'en rajoute de plus en plus

euldulle · 27 octobre 2018

Il y a 1 heure, lock042 a dit :

Alors pour avoir bosser sur des FITS d'observatoire professionnel dans le cadre de mon taf (Observatoire Solaire Themis), tout est dans le titre et c'était pas le header qui définissait quoique ce soit.

Je pense que c'est vraiment spécifique à chaque instrument/observatoire, l'exemple cité par gerard33 est parlant.

Je vais demander d'autres exemples aux collègues mais c'est pas vraiment la question je pense.

Le problème c'est de savoir si on peut raisonnablement imaginer

gérer les séquences via des entêtes fits avec simplement 2 ou 3 KEYWORDS spécifiques, si ça a du sens et surtout si ça

vaut le coup. Personnellement, je suis convaincu que oui : clairement l'objet de base aujourd'hui au moins dans le monde amateur c'est une séquence, pas une image individuelle.

Et ça permettrait aux softs de traitement de s'affranchir complètement de la structure de fichiers de la

machine hôte, que ce soit windows ou linux ou autre chose ; la tâche retomberait sur les logiciels

d'acquisition pour les fits (pas un gros problème, juste les KEYWORDS à insérer) et les logiciels de conversion

pour les raw APNs.

il y a une heure, lock042 a dit :

Les gars de cfitsio (NASA) sont également très sympa, je leur ai fait changer des choses facilement.

C'est juste que je reste pas convaincu de faire un truc qui fait tout auto à partir de l'entête. Je suis peut-être un vieux con réac' :).

Le premier objectif est pas de faire "tout auto", mais au moins de garantir que le tout auto est possible

et relativement simple. Ça ce n'est possible que si tu as un certain systématisme dans la façon de gérer

les séquences et les entêtes fits sont toutes désignées pour faire ça.

C'est la première étape, sine qua non du tout auto.

Les étapes suivantes c'est le pipe line de traitement, dans la ligne de ce qu'a fait m27trognondepomme pour

sirilic.

il y a 29 minutes, gerard33 a dit :

Sûr que le nom explicite du fichier en cours de traitement comme Siril, Iris, ou Pix pour ne citer qu'eux est beaucoup plus "lisible" pour l'utilisateur qu'un champ dans une entête fit

rien n’empêche le soft d'utiliser le contenu, par ex l'astrométrie , la datation, la taille du champ, etc

Même avec une structure inscrite dans les entêtes, il est pas interdit aux softs de nommer les fichiers de manière

explicite (il serait même plutôt interdit de ne pas le faire), le tout étant de ne pas dépendre du nom de fichier donc d'être

toujours certain à tout moment de pouvoir déterminer exactement ce qu'est un fichier simplement grâce à son contenu,

tout en laissant l'utilisateur complètement (ou peu s'en faut) libre de choisir les noms de ses fichiers.

Je sais pas ce que Colmic en pense, mais tous les problèmes qu'il évoque ne se poseraient même pas

avec une structuration comme ça : le champ PROJECT permettrait une étanchéïté complète (même

à la limite dans un répertoire unique) entre les fichiers de différents traitements : pour les acquisitions

il suffirait d'inclure le timestamp dans le nom de fichier pour garantir l'unicité, et pour les stacks de dupliquer

le champ PROJECT dans le nom du fichier ou quelque chose comme ça ; mais bon c'est juste pour dire,

personne ne va s'amuser à mettre tous ses fichiers dans un seul répertoire (mais rien ne l'interdirait

a priori)

PS :

j'ai oublié de préciser que dans la liste de KEYWORDS que je donnais, 4 sont déjà inscrits par CCDCIEL (entre autres sans doute),

les seuls "exotiques" sont les 3 :

PROJECT : (user defined)

IMAGECPS : SEQUENCE ou STACKED

IMAGESEQ : 1...N

Simplement ça, plus la clarification des valeurs possibles de IMAGETYP (à mettre en concordance avec

les résultats intermédiaires apparaissant dans le pipeline), doit suffire à mettre ça en ordre de marche.

De plus, si j'ai une séquence acquise avec un soft qui ne connaît ni PROJECT ni IMAGECPS ni IMAGESEQ,

les scripts de transformation sont triviaux.

--

fm

Modifié 27 octobre 2018 par euldulle

Colmic · 27 octobre 2018

il y a 10 minutes, euldulle a dit :

Je sais pas ce que Colmic en pense, mais tous les problèmes qu'il évoque ne se poseraient même pas

avec une structuration comme ça

Alors j'ai bien essayé de tout relire 2 fois mais j'ai rien compris

Moi ce que je veux n'est pas compliqué : une commande équivalente à convertraw pour les fits, qui reprend mes fits du dossier que je lui donne et les recopie en les renommant avec un numéro incrémenté dans le dossier de travail de SiriL.

Dans ces conditions je peux créer des scripts universels pour tous les fits que je vais enquiller à SiriL, exactement de la même façon que les RAW APN.

A mon sens c'est le truc le plus simple à faire.

gerard33 · 27 octobre 2018

En fait, euldulle, tu inventes l'au tiède

en spectro, par exemple, c'est les champs d'entête qui priment sur la dénomination et ça, les softs de capture (Prism, Démétra, etc) le font bien

euldulle · 27 octobre 2018

il y a 1 minute, Colmic a dit :

Alors j'ai bien essayé de tout relire 2 fois mais j'ai rien compris

Rhhaa, menteur , tu t'es dit "là ils en ont pour 6 mois à se mettre d'accord, moi j'ai un problème urgent".

C'est pas ça qu'il fallait dire. Bon on la refait, dis qu't'es d'accord avec moi pourvu que

ça résolve tes problèmes (et je te garantis que ça les résoud et même au-delà de tes espérances)

il y a 1 minute, Colmic a dit :

Moi ce que je veux n'est pas compliqué : une commande équivalente à convertraw pour les fits, qui reprend mes fits du dossier que je lui donne et les recopie en les renommant avec un numéro incrémenté dans le dossier de travail de SiriL.

Dans ces conditions je peux créer des scripts universels pour tous les fits que je vais enquiller à SiriL, exactement de la même façon que les RAW APN.

A mon sens c'est le truc le plus simple à faire.

Yep, mais c'est un cautère sur une jambe de bois. La vraie universalité elle est dans les entetes fits...

Bref ; sur ton problème précis, un script de base devrait faire l'affaire, non ? t'es sous windows ou linux ? Comment on sait quel numéro donner à quel fichier dans le transfert (ou bien est-ce qu'on s'en fiche) ?

euldulle · 27 octobre 2018

il y a 4 minutes, gerard33 a dit :

En fait, euldulle, tu inventes l'au tiède

Bô, c'est toujours ça de pris

il y a 4 minutes, gerard33 a dit :

en spectro, par exemple, c'est les champs d'entête qui priment sur la dénomination et ça, les softs de capture (Prism, Démétra, etc) le font bien

Bin disons que si l'eau tiède existe déjà (et en fait je pense, mais peut-être que je me trompe, qu'elle n'existe pas pour gérer les séquences),

c'est un peu con de continuer à se doucher à l'eau froide, et c'est exactement ce qu'on est train de faire en diluant de l'information dans des

répertoires, des noms de répertoires et des noms de fichiers.

lock042 · 27 octobre 2018

Moi je pense que le plus simple serait se coder dans siril un truc qui reconnaît les noms de fichier type timestamp + type fait par la plupart des softs.

Colmic · 27 octobre 2018

Je suis sous Windows. Quand je dis "je", je prend la parole pour la majorité silencieuse qui a les mêmes besoins que moi et qui n'est pas forcément férue d'informatique.

Donc pour ceux-là, des scripts universels c'est très bien.

Un script de base ne marche pas car le nom de mes brutes va changer d'une série à l'autre, et je dois donc ré-écrire mon script.

Il me faut un script de traitement LRVB, avec une variante pour le SHO (mais globalement on traite SHO et RVB de la même façon)

Donc voici ma première problématique :

- 4 dossiers où je vais stocker les brutes L, R, V et B

- 1 dossier où je stocke mes darks

- 1 dossier où je stocke mes offsets

- 4 dossiers où je stocke mes flats en L, R, V, B

On pourrait utiliser les entêtes fits pour stocker tout ça dans le même dossier, mais est-ce une bonne idée ?

Je suis adulte et responsable, donc je pars du postulat que je sais parfaitement ce que je place dans chacun de mes dossiers.

Ensuite il faut que SiriL puisse prendre les fits de mon dossier L (j'insiste sur "quelque soit leur nom"), faire le retrait de dark flat et offset (là aussi "quelque soit leur nom")

Ensuite SiriL aligne et empile mes L, et sauve L_stacked dans le dossier de travail de SiriL

Je fais maintenant la même chose avec mes R, mes V et mes B.

Il ne me reste plus qu'à faire la composition LRVB que SiriL ne sait pas encore faire en script.

Mon soucis c'est qu'actuellement SiriL ne sait pas prendre mes fits dans mon dossier L, R, V ou B sans que je les renomme au préalable pour que siriL puisse en prendre la séquence.

Seconde problématique :

- j'ai fait 2 séances de prise de vue avec 2 temps de pose différents

- je dois donc prendre ma série 1, y retirer le dark1, les offsets et flats1

- je dois sauvegarder ma série 1 avec un nouveau nom incrémenté qui démarre de 1 jusqu'à n

- je dois prendre ma série 2, y retirer le dark2, les offsets et les flats2

- je dois sauvegarder ma série 2 avec le même nom que la série 1 mais qui démarre cette fois à n+1

- je dois aligner et empiler toutes mes images série 1 + série 2

euldulle · 27 octobre 2018

il y a 48 minutes, Colmic a dit :

Ok, bon, désolé je vais évidemment pas avoir de solution immédiate

pas de solution immédiate, il ne peut pas y en avoir, sauf si elle est spécifiquement écrite pour résoudre ton problème ce qui est évidemment impossible à faire du point de vue de siril.

Mais c'est un cas d'école qui montre que la diversité des besoins les rend impossibles à résoudre du point de vue de siril sans une approche systématique.

Je vais dérouler ton problème et montrer comment on se sort de ce labyrinthe de fichiers avec les entetes fits/

Je décris ce que je propose de demander au soft d'acquisition de faire, à l'acquisition, pour garantir un traitement

fluide et sans douleur à la fin.

Citation

Je suis sous Windows. Quand je dis "je", je prend la parole pour la majorité silencieuse qui a les mêmes besoins que moi et qui n'est pas forcément férue d'informatique.

Donc pour ceux-là, des scripts universels c'est très bien.

Un script de base ne marche pas car le nom de mes brutes va changer d'une série à l'autre, et je dois donc ré-écrire mon script.

Il me faut un script de traitement LRVB, avec une variante pour le SHO (mais globalement on traite SHO et RVB de la même façon)

Donc voici ma première problématique :

- 4 dossiers où je vais stocker les brutes L, R, V et B

Je donne un nom à mon projet et je l'inscris (le soft d'acquisition l'inscrit) dans les entetes fits :

PROJECT = "MaBelleImage"

TOUTES les images du projet promènent ce header fits

Pour les LRVB, créer à l'acquisition un sac de fichiers distingués en plus du PROJECT par le KEYWORD (standard) FREQ :

FREQ = L

FREQ = R

FREQ =V

FREQ =B

Dans chacune de ces bandes chaque image porte en plus de l'entete FREQ, une entete disant qu'elle fait partie d'une

séquence et son numéro dans la séquence :

IMAGECPS = SEQ

IMAGENUM = n

Et bien sûr le type de l'image, en l'occurrence

IMAGETYP=Light

Tout ça dans le même répertoire avec les noms qu'on veut réglé une fois pour toutes dans le soft d'acquisition,

ajusté (flat, dark, light, hA) au moment du lancement de l'acquisition.

Et au traitement, on peut retrouver dans ce répertoire tout ce qu'on veut sans aucun input de l'utilisateur.

Citation

- 1 dossier où je stocke mes darks

dans le même répertoire que ci-dessus, 1 sac de fichiers par temps de pose, distingués par les KEYWORD (standard) :

IMAGETYP = Dark

EXPTIM = 30s

et bien sur PROJECT, IMAGESEQ, IMAGENUM

Pas de champ FREQ pour les darks of course.

Citation

- 1 dossier où je stocke mes offsets

Idem darks, toujours même répertoire, IMAGETYP = Bias

Citation

- 4 dossiers où je stocke mes flats en L, R, V, B

On continue,

IMAGETYP=FLAT

FREQ = L ou R ou V ou B

IMAGESEQ et IMAGENUM comme d'hab.

Encore une fois tout ça sans autre intervention que de signaler au soft qu'on acquiert des Flat, et que c'est du L ou du R si c'est pas fait automatiquement via

la route a filtres. J'ai toujours un seul répertoire et la structure complète de mon acquisition est inscrite dans les fichiers au moment de l'acquisition.

Citation

On pourrait utiliser les entêtes fits pour stocker tout ça dans le même dossier, mais est-ce une bonne idée ?

Quand disperser dans plusieurs répertoires sera devenu inutile, ce sera même plus une question.

Citation

Je suis adulte et responsable, donc je pars du postulat que je sais parfaitement ce que je place dans chacun de mes dossiers.

Ensuite il faut que SiriL puisse prendre les fits de mon dossier L (j'insiste sur "quelque soit leur nom), faire le retrait de dark flat et offset (là aussi "quelque soit leur nom")

Ensuite SiriL aligne et empile mes L, et sauve L_stacked dans le dossier de travail de SiriL

Je fais maintenant la même chose avec mes R, mes V et mes B.

Donc, je dis que structuré comme décrit ci-dessus, siril n'a besoin que du répertoire de travail comme input pour pouvoir

tout faire ; c'est un traitement LRVB classique, 1 seul temps de pose, aucun problème. Straight. Out of the box.

Citation

Il ne me reste plus qu'à faire la composition LRVB que SiriL ne sait pas encore faire en script.

Mon soucis c'est qu'actuellement SiriL ne sait pas prendre mes fits dans mon dossier L, R, V ou B sans que je les renomme au préalable pour que siriL puisse en prendre la séquence.

Problème inexistant dans la nouvelle structure.

Citation

Seconde problématique :

- j'ai fait 2 séances de prise de vue avec 2 temps de pose différents

- je dois donc prendre ma série 1, y retirer le dark1, les offsets et flats1

- je dois sauvegarder ma série 1 avec un nouveau nom incrémenté qui démarre de 1 jusqu'à n

- je dois prendre ma série 2, y retirer le dark2, les offsets et les flats2

juste pour être sûr de comprendre, tes flats2 c'est pas les mêmes que flats1 ? idem les offsets 1 et 2 ?

Citation

- je dois sauvegarder ma série 2 avec le même nom que la série 1 mais qui démarre cette fois à n+1

- je dois aligner et empiler toutes mes images série 1 + série 2

les darks2 sont distingués des dark1s par le temps de pose, les bias1/bias2 et les flat1/flats2

pour moi c'est les mêmes, mais si c'était pas le cas, là il me manque quelque chose pour les distinguer les

uns des autres (c'est pas un problème il faut juste décider comment on intègre ça dans les fits ; ça pourrait

être un champ SESSION ; un PROJECT aurait potentiellement plusieurs SESSION distinctes avec des flats/darks/offsets

différents).

Ok. Moyennant ça, à la fin de l'acquisition, si je sais quoi faire des différentes sessions, je n'ai toujours besoin de rien d'autre

que le répertoire où se trouvent les sacs de fichiers pour pouvoir faire tout le traitement, recréer les séquences (sous formes

de listes de fichiers, pas de copie des fichiers), et faire ce que j'ai à faire, sans que l'utilisateur n'ait rien d'autre à faire que, au plus haut

niveau spécifier quel flot de traitement il veut appliquer.

Bon il reste 2-3 bricoles à régler, mais dans l'ensemble ça marche bien :))))

Colmic · 27 octobre 2018

il y a 4 minutes, euldulle a dit :

juste pour être sûr de comprendre, tes flats2 c'est pas les mêmes que flats1 ? idem les offsets 1 et 2 ?

Les flats doivent être différents puisque ce sont 2 sessions différentes avec possiblement un démontage de la caméra.

Les offsets sont les mêmes quelque soit la séance.

Effectivement on distingue les darks par leur temps de pose. C'est d'ailleurs comme ça que DSS sait les distinguer à mon avis.

euldulle · 27 octobre 2018

Ok d'accord.

Pour tes renommages de fichiers, un petit script est ce qu'il y a de plus simple :

en bash sous linux ça donne un truc comme ça, juste pour illustrer comment c'est rapide

de résoudre en ligne de commande certaines tâches impossibles à faire simplement sur

une interface graphique si elle n'est pas spécifiquement prévue pour ça.

bash est disponible sous windows et ça rend tellement de petits (ou gros) services de ce genre,

que ça vaut vraiment la peine de jeter un oeil (en attendant les fits structurés :)).

La syntaxe a l'air archaïque, alors qu'en fait euh... elle est vraiment TRÈS archaïque, les origines

de ce machin là doivent remonter à un demi-siècle ; mais si même

Microsoft l'a intégré à windows10 , c'est que ça doit rendre quelques services.

Donc à titre d'exemple (pas testé), les # c'est des commentaires (sauf la premiere ligne,

qu'il faut laisser comme ça) :

#!/bin/bash
#
#
# $1 = premier argument passe au script : le numero auquel on veut que la sequence commence
#
if [[ "$1" == "" ]]; then # si pas d'argument, on commence a 1 
    let seq=1
else
    let seq=$1
fi
destrep="/autre/repertoire/

for fichier in $(ls *.fits); do
    #
    # $fichier dans la boucle est le fichier en cours de traitement 
    #
    #
    # extraction de l'extension :
    #
    basename=$(basename "$fichier" ".fits")
    cp "$fichier" "$destrep/$basename"_$seq.fits
    let seq=$seq+1
done

si on enleve les commentaires et les tests pour faire beau, il reste 5 lignes utiles, qui prennent 2 minutes à

écrire avec un peu d'habitude. Ça pourrait donner :

copie.bash, lancé sans argument, il commence la sequence a 1 :

fmeyer@ganymede:~/astrolab/Bias$ ./copie.bash
cp bias2_Bias_001.fits /autre/repertoire//bias2_Bias_001_1.fits
cp bias2_Bias_002.fits /autre/repertoire//bias2_Bias_002_2.fits
cp bias2_Bias_003.fits /autre/repertoire//bias2_Bias_003_3.fits
cp bias2_Bias_004.fits /autre/repertoire//bias2_Bias_004_4.fits
cp bias2_Bias_005.fits /autre/repertoire//bias2_Bias_005_5.fits
cp bias2_Bias_006.fits /autre/repertoire//bias2_Bias_006_6.fits
cp bias2_Bias_007.fits /autre/repertoire//bias2_Bias_007_7.fits
cp bias2_Bias_008.fits /autre/repertoire//bias2_Bias_008_8.fits
cp bias2_Bias_009.fits /autre/repertoire//bias2_Bias_009_9.fits
cp bias2_Bias_010.fits /autre/repertoire//bias2_Bias_010_10.fits
cp bias2_Bias_011.fits /autre/repertoire//bias2_Bias_011_11.fits
cp bias2_Bias_stacked.fits /autre/repertoire//bias2_Bias_stacked_12.fits
cp bias_Bias_001.fits /autre/repertoire//bias_Bias_001_13.fits
cp bias_Bias_002.fits /autre/repertoire//bias_Bias_002_14.fits
cp bias_Bias_003.fits /autre/repertoire//bias_Bias_003_15.fits
cp bias_Bias_004.fits /autre/repertoire//bias_Bias_004_16.fits
cp bias_Bias_005.fits /autre/repertoire//bias_Bias_005_17.fits
cp bias_Bias_006.fits /autre/repertoire//bias_Bias_006_18.fits
cp bias_Bias_007.fits /autre/repertoire//bias_Bias_007_19.fits
cp bias_Bias_008.fits /autre/repertoire//bias_Bias_008_20.fits
cp bias_Bias_009.fits /autre/repertoire//bias_Bias_009_21.fits
cp bias_Bias_010.fits /autre/repertoire//bias_Bias_010_22.fits
cp bias_Bias_011.fits /autre/repertoire//bias_Bias_011_23.fits
cp Bias_stacked.fits /autre/repertoire//Bias_stacked_24.fits

Avec un argument, 12, on commence la séquence à 42 (forcément)

fmeyer@ganymede:~/astrolab/Bias$ ../copie.bash 12
cp bias2_Bias_001.fits /autre/repertoire//bias2_Bias_001_12.fits
cp bias2_Bias_002.fits /autre/repertoire//bias2_Bias_002_13.fits
cp bias2_Bias_003.fits /autre/repertoire//bias2_Bias_003_14.fits
cp bias2_Bias_004.fits /autre/repertoire//bias2_Bias_004_15.fits
cp bias2_Bias_005.fits /autre/repertoire//bias2_Bias_005_16.fits
cp bias2_Bias_006.fits /autre/repertoire//bias2_Bias_006_17.fits
cp bias2_Bias_007.fits /autre/repertoire//bias2_Bias_007_18.fits
cp bias2_Bias_008.fits /autre/repertoire//bias2_Bias_008_19.fits
cp bias2_Bias_009.fits /autre/repertoire//bias2_Bias_009_20.fits
cp bias2_Bias_010.fits /autre/repertoire//bias2_Bias_010_21.fits
cp bias2_Bias_011.fits /autre/repertoire//bias2_Bias_011_22.fits
cp bias2_Bias_stacked.fits /autre/repertoire//bias2_Bias_stacked_23.fits
cp bias_Bias_001.fits /autre/repertoire//bias_Bias_001_24.fits
cp bias_Bias_002.fits /autre/repertoire//bias_Bias_002_25.fits
cp bias_Bias_003.fits /autre/repertoire//bias_Bias_003_26.fits
cp bias_Bias_004.fits /autre/repertoire//bias_Bias_004_27.fits
cp bias_Bias_005.fits /autre/repertoire//bias_Bias_005_28.fits
cp bias_Bias_006.fits /autre/repertoire//bias_Bias_006_29.fits
cp bias_Bias_007.fits /autre/repertoire//bias_Bias_007_30.fits
cp bias_Bias_008.fits /autre/repertoire//bias_Bias_008_31.fits
cp bias_Bias_009.fits /autre/repertoire//bias_Bias_009_32.fits
cp bias_Bias_010.fits /autre/repertoire//bias_Bias_010_33.fits
cp bias_Bias_011.fits /autre/repertoire//bias_Bias_011_34.fits
cp Bias_stacked.fits /autre/repertoire//Bias_stacked_35.fits

et c'est évidemment tellement customisable que ça peut TOUT faire.

Modifié 27 octobre 2018 par euldulle

pch · 27 octobre 2018

Tout a fait, des scripts comme ça c'est vraiment indispensable.

Voila une variante qui prend tous les fichiers fits du répertoire courant, utilise la commande fitsverify pour extraire un mot clé de l'en-tête FITS (ici DATE-OBS) et l'utilise pour renommer le fichier en remplaçant par la date tout ce qui suit le deuxième "_".

find . -maxdepth 1 -name "*.fits"  -print | sort | while read lfile  
do
  dt=$(fitsverify -l $lfile | grep DATE-OBS| cut -d\' -f2)
  bf=$(echo $lfile | cut -d_ -f1-2)
  nfile="${bf}"_"$dt".fits
  echo mv "${lfile}" "${nfile}"
  mv -u "${lfile}" "${nfile}"
done

euldulle · 27 octobre 2018

il y a 5 minutes, pch a dit :

Tout a fait, des scripts comme ça c'est vraiment indispensable.

...


find . -maxdepth 1 -name "*.fits"  -print | sort | while read lfile  
do
  dt=$(fitsverify -l $lfile | grep DATE-OBS| cut -d\' -f2)
  bf=$(echo $lfile | cut -d_ -f1-2)
  nfile="${bf}"_"$dt".fits
  echo mv "${lfile}" "${nfile}"
  mv -u "${lfile}" "${nfile}"
done

Yep. Velu à souhait, apparemment illisible, finalement assez simple et surtout diaboliquement efficace : le pedigree irréprochable d'un script réussi

L'illisibilité est liée à l'efficacité, et elle n'est vraiment qu'apparente.

pch · 27 octobre 2018

Ben... moi qu'ai fait un effort d'utiliser des variables intermédiaires pour que ça soit plus clair au lieu de tout mettre dans un gros pipe sur une seule ligne ... 😉

Modifié 27 octobre 2018 par pch

lock042 · 27 octobre 2018

Et oui j'oubliais. Avec ccdciel vous prenez des images et generez automatiquement des scripts siril dans la foulée.

C'est quand même pas mal.

Modifié 27 octobre 2018 par lock042

m27trognondepomme · 28 octobre 2018

Intéressant cette discussion.

Des fichiers fits auto-porteurs de ces informations seraient un plus pour les logiciels de post-traitement d'images astro.

L'utilisateur donne le dossier contenant les images. Le logiciel lit et extrait toutes les entêtes des fichiers fits , compile les informations (tri, regroupe, etc...) et crée les scripts (ou en interne ) des traitements à effectuer .

L'idéal serait d'avoir une librairie et des outils comme le fait cfitsio pour les fichiers fits. Les outils permettraient de vérifier la cohérence des images, ajouter les informations manquantes, etc... La librairie permettrait d'interfacer plus facilement les logiciels de traitement.

Sur le papier, ç'a l'air sympa mais dans la réalité, il y a toujours des cas compliqués non prévus ...

La priorité serait:

de bien définir les infos strictement nécessaires : trop d'informations nuiraient à la démarche.
développer une librairie + outils

Pour faciliter le déploiement de cette interface et en attendant que les logiciels d'acquisition adoptent le standard, il faudrait un outils pour ajouter ces infos manquantes.

A mon avis, il y a un peu de taf ? des volontaires ?

euldulle · 29 octobre 2018

Il y a 22 heures, m27trognondepomme a dit :

A mon avis, il y a un peu de taf ? des volontaires ?

Faut pas se précipiter à mon avis et bien poser le problème avant de savoir ce qu'il y a besoin

d'écrire comme code. J'essaie de mettre de l'ordre dans ce que j'ai écrit et je reviens avec une proposition

un peu plus propre.

vinvin · 31 octobre 2018

Je me disais bien que je connaissais ce pseudo !

En effet, il faut écrire les choses proprement pour faire un document de référence à partager à tous les auteurs de logiciels et itérer dessus avec les utilisateurs auparavant pour couvrir tous les usages.

euldulle · 31 octobre 2018

Il y a 1 heure, vinvin a dit :

Je me disais bien que je connaissais ce pseudo !

Yep, prononcé à la franc-comtoise, ça donne ça

J'ai jamais eu l'occasion de le dire, mais vous avez fait de siril un truc génial.

La fonctionnalité script était vraiment un des points de mire initiaux et maintenant c'est

là et c'est encore mieux que bien, versatile, souple, puissant. Et ça ne fait que commencer,

c'est un outil universel, ouvert, sur lequel on peut construire...

Merci et bravo aux devs.

Il y a 1 heure, vinvin a dit :

En effet, il faut écrire les choses proprement pour faire un document de référence à partager à tous les auteurs de logiciels et itérer dessus avec les utilisateurs auparavant pour couvrir tous les usages.

Yep, je vais tâcher de pondre quelque chose avant la fin du sympathique pont qui s'annonce

(pour le moment ça infuse doucement pendant la nuit...)

--

fm

lock042 · 31 octobre 2018

Allez François, fait moi changer d'avis :D.

euldulle · 1 novembre 2018

Il y a 19 heures, lock042 a dit :

Allez François, fait moi changer d'avis :D.

Tenu !

Connexion

acquisition/conversion/traitement des sequences, ccdciel/sirilic/siril

Messages recommandés

Rejoignez la conversation !

En ligne récemment 0 membre est en ligne

Annonces

Aider Webastro

Information importante