Comment by Mira Sarkis on 2022-11-04 09:58:03:
Le plot suivant, fourni par Vincent, représente le problème des pixels chauds (ou bruit) identifiés en tant que raie d'émission à flux très élevé et pris pour une raie Halpha surtout pour des vitesses >0.

L'idée (en gros) est de fitter avec des vitesses d'émission nulles et pénaliser les raies dont la vitesse d'emission estimée est à 0.

Spécifications pour l'implémentation, à discuter:

• dans dataset-parameters, ajouter un paramètre `linemodel.emvelocityforceprior` mis à true pour pénaliser les vitesses nulles.
  Note qu'il faut avoir : `linemodel.emvelocityfitmin = 0` pour que `linemodel.emvelocityforceprior` s'applique vraiment.
• coté lib: à spécifier avec Didier

Comment by Didier Vibert on 2022-11-07 08:21:09:
Mira Sarkis wrote in #note-9:
> Le plot suivant, fourni par Vincent, représente le problème des pixels chauds (ou bruit) identifiés en tant que raie d'émission à flux très élevé et pris pour une raie Halpha surtout pour des vitesses >0.

il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ?
>
> L'idée (en gros) est de fitter avec des vitesses d'émission nulles et pénaliser les raies dont la vitesse d'emission estimée est à 0.
>
> Spécifications pour l'implémentation, à discuter:
> * dans dataset-parameters, ajouter un paramètre `linemodel.emvelocityforceprior` mis à true pour pénaliser les vitesses nulles.
> Note qu'il faut avoir : `linemodel.emvelocityfitmin = 0` pour que `linemodel.emvelocityforceprior` s'applique vraiment.
> * coté lib: à spécifier avec Didier

je ne rajouterai pas de param emvelocityforceprior. Mais comme pour le fonctionnement des autres priors (stronglines et Ha, juste un param avec le coeff de pénalité cf #7635-2

on pu

Comment by Vincent Le Brun on 2022-11-08 15:13:21:
Didier Vibert wrote in #note-10:

> il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ?
sur un autre exemple que j''ai regardé, tous les autres candidats utilisent le spike comme raie d'emission principale, et la vitesse est la meme (10 km/s pour ce run là) pour tous les candidats. Ca peut être un critère en effet

Comment by Didier Vibert on 2022-11-08 15:17:32:
Vincent Le Brun wrote in #note-11:
> Didier Vibert wrote in #note-10:
>
> > il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ?
> sur un autre exemple que j''ai regardé, tous les autres candidats utilisent le spike comme raie d'emission principale, et la vitesse est la meme (10 km/s pour ce run là) pour tous les candidats. Ca peut être un critère en effet

je pensais plutôt que si c'est le cas ça va être dur de rattrapper les bons candidats, il va falloir mettre une pénalité forte... on va quand même tenter !

Comment by Didier Vibert on 2022-11-08 15:21:19:
Vincent Le Brun wrote in #note-11:
> Didier Vibert wrote in #note-10:
>
> > il serait intéressant de regarder sur cet exemple, si les vitesses des autres candidats sont nulles ?
> sur un autre exemple que j''ai regardé, tous les autres candidats utilisent le spike comme raie d'emission principale, et la vitesse est la meme (10 km/s pour ce run là) pour tous les candidats. Ca peut être un critère en effet

10 km/s ? donc il faut aussi rajouter un param qui donne le seuil de vitesse en dessous duquel on applique la pénalité.
Donc 2 param

1. le seuil de vitesse
2. la pénalité en proba (ie un terme p : 0 <= p <= 1)

Comment by Vincent Le Brun on 2022-11-08 15:22:33:
non c'est pare que pour ce run j'avais mis 10 en limite basse, l'idée serait de mettre 0 et de tester les solutions avec vitesse 0 (si la limite basse n'est pas 0 on n'active pas le prior)

Comment by Didier Vibert on 2022-11-08 15:53:09:
Vincent Le Brun wrote in #note-14:
> non c'est pare que pour ce run j'avais mis 10 en limite basse, l'idée serait de mettre 0 et de tester les solutions avec vitesse 0 (si la limite basse n'est pas 0 on n'active pas le prior)

ok, on oublie le param seuil pour l'instant donc.

on peut quand même activer le prior avec la vitesse limite basse, même quand elle n'est pas nulle. Ie l'activation du prior est gouvernée uniquement par la valeur de la pénalité (comme pour les autres priors), si -1 le prior n'est pas actif, sinon il est actif et pénalise les z avec une vitesse basse.

Comment by Didier Vibert on 2022-11-08 15:55:03:
je viens de penser à un truc... le fit de la vitesse ne se fait que sur les fenêtres 2nd passe....
=> on ne rattrapera jamais les candidats qui ne sont pas examinés en 2nd passe ie si les 5 sont dus au spike c'est foutu...

Comment by Vincent Le Brun on 2022-11-08 16:43:50:
pas bon ça... on peut peut-être imaginer bosser sur la forme de la PDF 1ere passe ?

Comment by Didier Vibert on 2022-11-10 15:50:43:
petit récap sur les diverses possibilités de mitigation des spikes:

• prior vitesse => implémenter le fit de la vitesse en première passe (ie à chaque z)
• detection des spikes:

• code standalone hors amazed eg deglitcher à ondelette continue et coeff de Holder (deglitcher Hershell SPIRE) ou sparsité (L1 minimisation)
• dans amazed: vitesse nulle pour 1 ou tous les candidats, rechercher la position de la raie dominante, flagger les pixels correspondant et relancer l'estimation de z
• modélisation des spikes: rajouter un spike paramétré dans les modèles fitté, sans doute un peu lourd, car mini 2 param en plus par modèle (position et amplitude du spike), mieux vaut les détecter avant ?
• réjection au niveau de la reliability, la pdf ayant sans doute la signature: apprendre sur des simu incluant des spikes (El-cosmos ?) et rajouter une classe spike
• ... vous avez mieux ?