Richman

Utilisation Iris

Messages recommandés

J'ai beau suivre le didacticiel du programme pas à pas, à chaque fois que je registre les images de Jupiter, j'obtiens un gros disque blanc en final!
Et ce, dès les premières superpositions.
Où est le binz?

Alain

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut, en fait lorsque tu fais l'addition, ben tu additionnes, oui bon OK. Donc effectivement, dès que les premières images commencent à s'additionner, tu vois le disque qui sature très vite, et même souvent sur la couche bleue, c'est le blanc intégral !!!
Pour voir l'image, il te faut jouer sur les seuils de visualisation, et en manoeuvrant le curseur du haut, tu vas découvrir ta belle image registrée !

Voilà voilà, bon courage, epsi

Partager ce message


Lien à poster
Partager sur d’autres sites
A mon avis c'est effectivement un problème de seuil de visualisation.
Iris travaillant sur 15 bits, et la carte graphique sur 8, il y a simplement une information 128 fois trop grande.
les curseurs permettent de régler les seuils min et max (de 0 à 2^15-1 soit 32767).

Partager ce message


Lien à poster
Partager sur d’autres sites
Tes images de base avec une webcam sont codes sur 8bits, soit des valeurs entre 0 et 255. Lorsque tu empiles plusieurs images, Iris augmente la dynamique en prenant une plage de 15Bits (0 a 32767). Donc a la fin de la visualisation, comme le dit Espi, tu bouges les variables dans la fenetre de reglage a gauche. Ou alors "aladure" tu tapes visu seuilhaut, seuilbas comme commande, soit par exemple visu 32767 -10 et tu verras ta jupi.

Une petit chose supplementaire. Si tu gardes beaucoup d'images, en les empilant tu risques de depasser le seuil maximal d'Iris (32767). Tu perdras donc un peu d'information. Ce que je fais c'est que je prends 3-4 images au pif dans la serie, je tape stat (ou stats) et je note la valeur maximale. J'en fait la moyenne, je multiplie par le nombre d'images. Ca te donne la valeur max que prendra ton "empilement". Si ca depasse les 32767, tu prends l'inverse de cette valeur, tu utilises mult2 avec ce coefficient sur toutes tes images, et ensuite tu empiles. Tes valeurs ne depasseront plus et tu garderas une dynamique a peu pres correcte (les basse valeurs seront encore plus reduite quand meme mais y'a pas de formule miracle). Si j'ai pas ete claire, tu peux me contacter par email pour que je te fasse quelques captures d'ecran et un texte plus detaille

Partager ce message


Lien à poster
Partager sur d’autres sites
encore plus simple Tony, tu utilise add_norm qui va calculer puis appliquer automatiquement le coefficient que tu a déterminé à l'ensemble de tes images.
Du coup, l'addition étant normalisée sur 32767, pas de risque de débordement.
Si le nombre d'images n'est pas suffisant, le coefficient appliqué reste sur 1 bien sur mais le total sera inférieur à 32767 !

dernière chose, le coefficient est donné en fin d'addition par la commande, histoire de se rendre compte de combien on "dépasse" la dynamique. Il m'est arrivé d'obtenir un coef inférieur à 0,25 sur des images très brillantes, qui exploitent alors la dynamique de 8bits de la webcam. Dans ces conditions, au dela de 128 images, on dépasse le seuil, ce qui arrive vite en compositant.

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut,

Effectivement, çà marche un peu mieux avec vos explications, mais j'arrive quand même à saturation avec plusieurs centaines de photos de Jupiter.

Alain

Partager ce message


Lien à poster
Partager sur d’autres sites
Bonjour,
Javais mis en ligne sur mon site deux scripts reprenant toutes les commandes à suivre pour traiter un avi complet.
Effectivement, lorsque tu additionne un grand nombre d'images, il apparait un gros dique blanc et c'est normal, mais comme l'a dit Patry, la commande >add norm recalcule la valeur à 32700. Va voir sur mon site http://www.astropegase.be à la page "traitement des images planétaires" et essaie le script 1. Ca doit marcher.
Bonne journée.

Partager ce message


Lien à poster
Partager sur d’autres sites
Hallo JL,

Je me suis amusé à multiplier toutes les images de la séquence par un chiffre inférieur à 1.
Et çà me permet de ne pas atteindre la saturation avec autant d'images que je veux.
Mais de là à dire que c'est la bonne démarche...
Je préfère me rendre sur ton site!

Alain

Partager ce message


Lien à poster
Partager sur d’autres sites

  • la bonne commande est add_norm2 (nom generique du fichier) ([nb d'images)
    iris additionne le total des images puis opere une division de façon à ce que la valeur la plus elevée de l'image finale soit inferieur a 32000

  • autre chose : iris ne code pas sur 15bit mais sur 16bit.
    une image peut avoir des valeurs négatives (-32000 +32000) soit 64000 niveu au total (arondis)
    c'est notament le cas des images issues de ReGISTAX qd elle sont importée.
    par contre si iris sait visualiser les images 16bit il ne travaillera que sur 15bit (cad les valeurs pausitive) donc pour normaliser une image registax au format 15bit iris faite dans IRIS:
    diviser votre image par 2 puis additionné une valeur a votre images (16000) vous retrouverez alors une dynamique de travail su 15bit

Partager ce message


Lien à poster
Partager sur d’autres sites
tu a parfaitement raison, pour le bit qui manque, cela permet de "centrer" les informations sur 0 et pas sur 8192.

J'ai écrit un petit tutoriel sur Iris avec une vidéo (bien modeste) en plus. A voir sur http://perso.magic.fr/marc.patry/marc/astro.html

J'ai du fortement (?) compresser la vidéo pour pouvoir l'héberger mais le principe reste valable pour la séquence de traitement.

A ce sujet, si cela vous tente, j'ai écrit un petit programme supplémentaire pour accélérer assez fortement les traitements sous Iris.
Normalement, on commence d'abord par registrer (aligner) les images, puis ensuite par les sélectionner. Ces deux opérations, réalisées sur la couche verte vont imposer un traitement important sur un nombre d'image qui ne l'est pas moins. J'ai écrit une petite routine permettant de trier le fichier shift.lst par rapport au fichier select.lst.
Du coup, si sur le plan vert, les deux opérations restent dans cet ordre, après application du soft, les autres plans peuvent s'appliquer sur une fraction réduite des images (une selection des N premières lignes du fichier select), et ensuite être registrées correctement. On passe d'un traitement de quelques centaines d'images (pas loin de 1000 parfois) qui sera restreint en fin de traitement, à celui des N "meilleures" images et ce dès le début du processus.

Gain de temps appréciable !

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut Fredogoto,

Tu es sûr pour ADD_NORM2[NOM] [NOMBRE]? Je ne vois pas cette commande dans la liste des commandes d'Iris, il n'y a que: ADD_NORM [NOM] [NOMBRE] que j'utilise toujours et qui ne pose pas de problèmes.

François

Partager ce message


Lien à poster
Partager sur d’autres sites
salut debricon
an fait add_norm2 existe bel et bien mais contrairement a add_norm "simple" il se fait sur une partie de l'image selectionée (cliquez glisser) : le add-norm simple se sert de l'image entière
désolé pour la confusion

Partager ce message


Lien à poster
Partager sur d’autres sites
Patry : ton programe est tres interressant, mais quel est son interrest ? rien n'empeche dans iris de faire en premier lieu le tri des images puis de les registré et traiter ensuite !!! j'ai manqué quelques chose ?

Partager ce message


Lien à poster
Partager sur d’autres sites
L'avantage devient décisif quand on a un grand volume d'images, dont une petite fraction va "servir" essentiellement.

Exemple, je dispose de 1000 images et j'en composite 128.

Je suis obligé de faire dans l'ordre (pour la couche verte), un pregister (ou cregister), un bestof puis un select.
Pour les autres couches (R et B) ce sera pareil ; une registration sur les 1000 images pour finalement les selectionner et n'en garder que 128. Question, pourquoi avoir passé du temps à registrer 900 images inutilement ?

L'idée consiste donc (après la première opération, donc uniquement pour les couches R & B) à selectionner d'abord, et à registrer ensuite. Sauf que bien sur les dx/dy du fichier shift ne sont plus applicables, vu qu'on a ré-ordonné les images.

Donc on trie le fichier shift.lst, on sélectionner les images, et on les registre ensuite.
Dans l'odre ; iris_sort, puis select, et enfin file_trans.

Idée pour la version 3, fournir le nombre N de vues à compositer et ne conserver que les N lignes du fichier select et on gagne là encore mais sur l'opération de selection cette fois çi.


Je complète ma réponse ; Le tri sera difficile si le suivi n'est pas bon. Les fonctions d'auto-corrélation demandent généralement à s'appliquer aux mêmes "vues". Ce qui n'est pas le cas si la cible se déplace entre les vues. Le programme risque de ne pas différencier un déplacement d'une mauvaise corrélation => image rejetée, ou plus exactement "mal classée".

[Ce message a été modifié par patry (Édité le 27-04-2005).]

Partager ce message


Lien à poster
Partager sur d’autres sites
mouif ben pas convaincu
dans l'ordre perso: je trie , j'alligne (en 2 passe si necessaire) puis je traite. et le gains de temps peut etre sympatoche surtout quand on n'a des images de tres grande dimention

Partager ce message


Lien à poster
Partager sur d’autres sites
Bheuuu ???

Iris arrive à trier correctement des images qui ne sont pas préalablement alignées ... pour ma part cela n'a pas toujours donné de bons résultats.

Mais effectivement c'est une possibilité comme tu l'indique.

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant