ms

Retinex : balance des blancs automatique

Messages recommandés

1  2

3  4

 

1 : image en sortie du recalage

2 : image précédente renforcée

3 : balance des blancs automatique (Grey World + Retinex)

4 : image dé-bruitée (facultatif)

 

jup_8618.png.b8b04f0346e5c296ef3924fd1e084846.png

 

Pour le détail des algorithmes voir : Combining Gray World and Retinex Theory for Automatic White Balance in Digital Photography.

Personnellement, je trouve que le dé-bruitage n'est pas nécessaire et je m'arrête dans EVA à l'image 3 quand j'ai suffisamment d'images brutes  :

 

 jup_8400_2.png.8da3299d0f120f3ab563a82f92395c33.png

 

L'algorithme Retinex permet de faire ressortir des détails très ténus.

Les étapes 1 et 3 sont optimisées par contre l'étape 2 doit encore être optimisée.

 

Modifié par ms
  • J'aime 3

Partager ce message


Lien à poster
Partager sur d’autres sites

Première vidéo complète avec traitement à 200img/s (9000 images brutes traitées par GPU GeForce en 45s) :

 

jup_9000.gif.6313d6a90f594f49124874130393b7d1.gif

 

Ici, 6000 images brutes sur 9000 suffisent pour obtenir une image correcte, si les conditions se dégradent il faudra pousser jusqu'à 18000 images brutes (90s à 200img/s).

Si les conditions se dégradent encore, il faudra augmenter la vitesse d'acquisition (mon objectif est de franchir, en 2019, le cap des 500img/s avec une nouvelle technologie de cartes graphiques).

90s à 500img/s ça représente la bagatelle de 45000 images brutes pour obtenir une image correcte sous conditions bien dégradées. :)

 

Pour un niveau de turbulence donné, il faut pouvoir adapter le nombre d'images et la vitesse d'acquisition, le calcul par le GPU permet de suivre la cadence imposée par la turbulence (ce que ne permettent pas les logiciels actuels aussi bien en acquisition qu'en traitement).

 

Modifié par ms
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est pas la caméra le problème mais la carte graphique qui doit être capable de digérer un débit de 500 images (640x480) par seconde.

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 15 heures, ms a dit :

franchir, en 2019, le cap des 500img/s avec une nouvelle technologie de cartes graphiques

Hello MS,

ça faisait longtemps qu'on ne te voyais plus, depuis tes exploits de traitement de mes vidéos, tu t'es mis au vert un peu ? 

Excuse moi de te demander pardon, mais je ne comprends pas de quoi tu parles; 500 fps sur quelle cible, avec quelle caméra? Pour quoi faire ?

Il est sorti ton système finalement  que tu nous as annoncé de nombreuses fois pour des tests en juillet avec de possibles résultat mirobolants. Ca donne quoi ?

Je n'ai pas compris non plus quelle est l’innovation côté balance des blancs. Ca n'a rien de sorcier, sans lire de littérature scientifique j'ai trouvé une méthode pour avoir une WB quasi absolu dans photoshop. C'est très facile en fait sur une cible comme Jupiter. Ca marche moins sur Mars. Il n'y a pas d'algo absolu, il faut une référence. 
Soit dit en passant, elle n'est pas très bonne ta balance des blancs. 

Modifié par jldauvergne
  • Haha 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Citation

Je n'ai pas compris non plus quelle est l’innovation côté balance des blancs.

Qui parle d'innovation ... sinon toi. :)

 

Citation

j'ai trouvé une méthode pour avoir une WB quasi absolu dans photoshop.

Mon but c'est de remplacer la chaîne : FireCapture -> AS3 -> WinJupos -> Registax6 -> Photoshop par un seul logiciel ... au cas où tu ne l'aurais pas compris. :)

 

Citation

Ca donne quoi ?

- j'ai commencé cet été avec un C11 sur EQ6-R et une caméra ASI224MC

- en acquisition, le calcul par GPU permet d'aller en gros 2 fois plus vite que FireCapture 
- en traitement, le calcul par GPU permet de traiter de 100 à 200 images par seconde selon la carte graphique utilisée

- reste encore à mettre au point la balance des blancs, pour cela je teste différents algorithmes Grey World + Retinex mais aussi le suivant qui se rapproche de la balance auto de Registax

 

jup_awb.thumb.png.f009bb6ca737c2d280c5363fa5d1491b.png

 

Reste à choisir parmi différentes solutions en fonction d'un critère de qualité qui reste à définir (visuellement je préfère l'avant-dernière mais les goûts et les couleurs) :

 

jup_25.6.png.bcb7257e7940cdd0ce361d0c7cc6986f.png

 

La même vidéo traitée avec AS3 donne un résultat analogue :

 

jup_as3.png.deb41cc5c984baf6c5ff8a6ac00856bd.png

 

En fait en sortie d'AS3 et d'EVA (étape 1), les images sont pratiquement identiques jusqu'à 80dB (courbe jaune et courbe blanche confondues) :

 

Graph_EVA_AS3.png.7e8f3a3e54e130ffb142dc2dbedb1484.png

 

 

Modifié par ms

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a une heure, ms a dit :

Mon but c'est de remplacer la chaîne : FireCapture -> AS3 -> WinJupos -> Registax6 -> Photoshop par un seul logiciel ... au cas où tu ne l'aurais pas compris.

ça on n'a compris mais tu n'as pas démontré que ça fonctionnait mieux lorsque tu passes les vidéos des autres.


Comme à ton habitude tu partages des choses et ensuite tu ne réponds pas aux questions que l'on te pose. 500 fps avec quel caméra, sur quelle cible et pourquoi faire ? 

Partager ce message


Lien à poster
Partager sur d’autres sites
Citation

tu n'as pas démontré que ça fonctionnait mieux lorsque tu passes les vidéos des autres

C'est possible et c'est pour cela que j'ai commencé en juillet 2018 à faire 2 types d'acquisition/traitement :

1) avec FireCapture 2.6 sous linux à 100img/s puis traitement du fichier SER avec AS3/R6

2) avec EVA sous linux à 100 et 200img/s

En 1) j'ai le même résultat qu'en 2) à 100img/s cela confirmerait le graphe affiché plus haut (fichier SER réalisé par polo).

 

Citation

500 fps avec quel caméra, sur quelle cible et pourquoi faire ? 

Pour tester une carte graphique plus puissante que je devrais avoir l'an prochain.

Modifié par ms

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 2 heures, ms a dit :

En 1) j'ai le même résultat qu'en 2) à 100img/s cela confirmerait le graphe affiché plus haut (fichier SER réalisé par polo).

OK, si ça fonctionne aussi bien, il faut le donner à une tierce personne indépendante pour tester. Ton but était de commercialiser si j'ai bien suivi, tu ne peux pas être juge et partie du coup. 

 

Il y a 2 heures, ms a dit :

Pour tester une carte graphique plus puissante que je devrais avoir l'an prochain.

Ca ne répond toujours pas à ma question. Ca sert à quoi de monter à 500 fps ? Dans la pratique tu y vas avec quelle caméra, et sur quelle cible ?

Tu développes un outil pour l'astro  si j'ai bien suivi, pas un banc de test pour carte graphique.

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai repris la vidéo (600, 1200, ... , 8400 images) avec un autre algorithme pour la balance automatique des blancs (on voit le passage de 600 à 8400 images en 42 secondes et l'amélioration de l'image) :

 

jup_8400.gif.7856c0b5c2061ee854d5d2b7d40aae3e.gif

 

 

 

Citation

Ton but était de commercialiser si j'ai bien suivi, tu ne peux pas être juge et partie du coup. 

Mon but, maintenant que je suis à la retraite, c'est surtout de me faire plaisir. :)

La commercialisation dépendra de l'accueil que recevra EVA sur le terrain l'an prochain.

Cette année, il me reste à peaufiner les étapes 2 et 3 mais l'essentiel est fait.

Cet été j'ai fait une démo (Jupiter, Saturne et Mars) à mes voisins, EVA à l'autonomie escomptée avec une batterie de 80Ah déchargée à 50%. 

 

Citation

Tu développes un outil pour l'astro  si j'ai bien suivi, pas un banc de test pour carte graphique.

EVA ce n'est pas fait uniquement pour l'astro, j'ai un autre développement en // qui pourrait permettre de faire de l'astro à 500 img/s et même plus si la carte graphique suit.

Est-ce que cela aurait un intérêt pour l'astro ? Pour l'instant, je n'en sais rien.

Modifié par ms

Partager ce message


Lien à poster
Partager sur d’autres sites

On peut en savoir plus sur les paramètres de prise de vue ? La date ? Le montage optique (quel ADc, quelle barlow) ? 

 

il y a 5 minutes, ms a dit :

EVA ce n'est pas fait uniquement pour l'astro, j'ai un autre développement en // qui pourrait permettre de faire de l'astro à 500 img/s.

Mais encore ?? En planétaire ?

Partager ce message


Lien à poster
Partager sur d’autres sites
Citation

On peut en savoir plus sur les paramètres de prise de vue ? La date ? Le montage optique (quel ADc, quelle barlow) ? 

Ce fichier SER de Jupiter (polo) me sert de test depuis quelques semaines. Pour les éléments de prise de vue voir polo.

Mes propres acquisitions n'ont pas besoin de fichiers SER et je ne garde en sortie que les images résultant de la composition de 600, 1200, ... , 8400 images brutes pour reprendre l'exemple ci-dessus.

J'utilise soit l'ADC matériel de ZWO, soit l'ADC logiciel d'EVA.

 

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 1 minute, ms a dit :

Ce fichier SER de Jupiter (polo) me sert de test depuis quelques semaines. Pour les éléments de prise de vue voir polo.

ah ce ne sont donc pas tes propres images. Et on n'a pas la date du coup ?
J'avais cru comprendre, qu'il s'agissait de ton test vu eu tu annonçais un test complet sur le ciel en juillet, désolé. Mais du coup, toujours pas de résultat à montrer de ton système sortant en temps réel des images qui font fi de la turbulence (c'est ça que tu annonces depuis un moment) ?

 

 

Le 13/09/2018 à 07:44, ms a dit :

Si les conditions se dégradent encore, il faudra augmenter la vitesse d'acquisition (mon objectif est de franchir, en 2019, le cap des 500img/s avec une nouvelle technologie de cartes graphiques).

Pardon d'insister sur ce point, tu laisses entendre qu'il faudrait monter à 500 fps sur Jupiter, car c'est bien d'elle que tu parles plus haut. Je n'ai vraiment pas compris comment tu comptes t'y prendre. 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Citation

Pardon d'insister sur ce point, tu laisses entendre qu'il faudrait monter à 500 fps sur Jupiter, car c'est bien d'elle que tu parles plus haut. Je n'ai vraiment pas compris comment tu comptes t'y prendre. 

Nos voisins allemands ont déjà fait cela sur Jupiter avec une ASI290MM (500fps en luminance et 440fps dans le rouge).
La difficulté c'est de le faire en temps réel en faisant travailler une carte graphique suffisamment puissante.

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 59 minutes, ms a dit :

Nos voisins allemands ont déjà fait cela sur Jupiter avec une ASI290MM (500fps en luminance et 440fps dans le rouge).

ok, super, ... à f/5 ? :)

Tu as un lien pour rire ?

AS3 si le signal est trop dégradé il ne fait pas de miracle. 

Plus sérieusement, avec un gain fort c'est sûr que tu peux passer 400 ou 500 fps, mais pas à plus de f/10, ou alors tu as une image soit ultra granuleuse soit ultra sous-exposée. . 

Modifié par jldauvergne

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour MS,

J'ai pu descendre à 1 ms de temps de pose sur Mars cet été à F15 mais sur Jupiter, pas en dessous de 10 ms... Même en poussant le gain

Donc impossible d'avoir 500 fps dans ces conditions...

Ce qui manque c'est un étage d'ampli comme dans les caméras de André Lallemand

Et puis j'aimerais bien un afficheur qui me donnerait la durée et la fréquence des fenêtres de faible turbu et même un signal dérivé...

 

 

Modifié par Pascal C03

Partager ce message


Lien à poster
Partager sur d’autres sites
Citation

Tu as un lien pour rire ?

http://www.astrotreff.de/topic.asp?TOPIC_ID=209042

D=300mm et F=3500mm -> f/12 :)

Traduction : J'ai utilisé l'ASI290MM USB3.0. Il y a jusqu'à 500 fps dans la luminance et 440fps dans le canal rouge.

Modifié par ms

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 24 minutes, ms a dit :

http://www.astrotreff.de/topic.asp?TOPIC_ID=209042

D=300mm et F=3500mm -> f/12 :)

Traduction : J'ai utilisé l'ASI290MM USB3.0. Il y a jusqu'à 500 fps dans la luminance et 440fps dans le canal rouge.

ok. J'utilise la même caméra à f/24 ce qui fait une différence de lumière par pixel d'un facteur 4. Là où je peux effectivement monter à 100 fps, il va à 400 fps, mais en étant bigrement sous échantillonné. 
Ses images finales sont bonnes pour 3500 mm de focale, mais clairement limitées par la focale. 
Et en passant, par rapport aux temps de cohérence de la turbulence je doute de la pertinence d'aller nettement au dessus de 200 fps. Déjà à 100 fps, lorsque c'est peu stable, ce qui limite c'est plus souvent la taille de l'angle d'isoplanétisme que le temps de cohérence des images. Et plus l'angle d'isoplanétisme est petit et moins on a intérêt à avoir de bruit pour récupérer ça au traitement, tout est question de compromis, et 400 fps on est loin de faire dans le compromis.  

Partager ce message


Lien à poster
Partager sur d’autres sites

et soit dit en passant il doit être sous ex même à f/12 car il parle de gain à 50% à 400 fps, ... 
Bref, pas un modèle à suivre. 

Partager ce message


Lien à poster
Partager sur d’autres sites

Il y a 2 possibilités :
1) obtenir plus d'images brutes par des poses courtes (gain plus élevé) ce qui améliore le rapport signal sur bruit (racine carrée du nombre de trames)

2) obtenir un meilleur rapport signal sur bruit de base par des poses plus longues (gain moins élevé)

 

Pour le planétaire, j'ai remarqué qu'à 200img/s j'augmentais le nombre de "lucky regions" par rapport à 100img/s (donc plus de détails).

Pour Jupiter et Saturne, mon temps maximum est de 90s soit 18000 images brutes à 200fps au delà les détails commencent à se déplacer.

 

Dire que l'angle d'isoplanétisme est l'élément limitant est parfaitement exact, c'est lui qui limite la vitesse d'acquisition. Il faut trouver la vitesse qui permet d'obtenir le plus de "lucky regions".

 

Citation

Ce qui manque c'est un étage d'ampli comme dans les caméras de André Lallemand

EMCCD et sCMOS ne font pas cela ?

Modifié par ms

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 1 minute, ms a dit :

Il y a 2 possibilités :
1) obtenir plus d'images brutes par des poses courtes (gain plus élevé) ce qui améliore le rapport signal sur bruit (racine carrée du nombre de trames)

2) obtenir un meilleur rapport signal sur bruit de base par des poses plus longues (gain moins élevé)

Non, à temps d'intégration égaux ces deux possibilités ne se valent pas. Fractionner plus n'augmente pas le rapport signal sur bruit. 

 

 

il y a 2 minutes, ms a dit :

Pour le planétaire, j'ai remarqué qu'à 200img/s j'augmentais le nombre de "lucky regions" par rapport à 100img/s (donc plus de détails).

Pour Jupiter et Saturne, mon temps maximum est de 90s soit 18000 images brutes à 200fps au delà les détails commencent à se déplacer.

tu as des images qui montrent ça ? 
200 fps ton gain doit être à fond sauf si toi aussi tu travailles en sous échantillonage, ... Mais on n'a pas vu tes images pour en juger. Si ton système fonctionne bien, elles doivent être montrables je suppose ?
 

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 9 minutes, jldauvergne a dit :

Non, à temps d'intégration égaux ces deux possibilités ne se valent pas. Fractionner plus n'augmente pas le rapport signal sur bruit. 

Tout a fait d'accord avec ceci, je l'ai experimenté, et c'est logique! (si je peux me permettre d'intervenir dans votre dialogue...)

D'ou l'absurdité de chercher d'augmenter a tout prix la frequence et pousser le gain: tout ce qu'on gagne c'est d'avoir des fichiers bien plus lourds, car chargé de l'information encombrante de bien plus de bruit: la camera, en pose plus longue, accumule les photons en faisant une sorte de stacking, mais en evitant le bruit: registax se debrouille ensuite pour eclaircir tout ça, mais ça revient exactement au meme, avec beaucoup de place memoire economisée...

  • J'aime 2

Partager ce message


Lien à poster
Partager sur d’autres sites

Il y a aussi une histoire de saturation du bus de données:  en USB3, 500 fps, c'est chaud..... Ou alors avec une toute petite taille d'image.

Modifié par dfremond

Partager ce message


Lien à poster
Partager sur d’autres sites
Citation

Fractionner plus n'augmente pas le rapport signal sur bruit. 

Évidemment, je veux dire qu'il faut faire un choix car dans le premier cas le S/B est plus faible au départ.

 

Citation

Si ton système fonctionne bien, elles doivent être montrables je suppose ?

Je fais des essais sous différentes conditions de turbu en faisant justement varier la vitesse d'acquisition.
Quand j'aurais suffisamment de données, je montrerais cela.

 

Citation

D'ou l'absurdité de chercher d'augmenter a tout prix la frequence et pousser le gain: tout ce qu'on gagne c'est d'avoir des fichiers bien plus lourds, car chargé de l'information encombrante de bien plus de bruit:

Je n'ai pas ce problème avec EVA qui compte les "lucky regions" et agit un peu comme un tamis. Toutes les images brutes sont prises en compte et certaines contiennent peu voir pas d'information. C'est justement en faisant varier la vitesse  d'acquisition que je peux trouver l'optimum.

Modifié par ms

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 22 minutes, ms a dit :

Toutes les images brutes sont prises en compte et certaines contiennent peu voir pas d'information.

Oui comme AS3, ça on a bien compris. Il n'y a pas d'invention ici. C'est pour ça que ton système ne fait pas mieux contrairement à ce que tu as longtemps laissé entendre. Il fait même plutôt moins bien comme tu nous l'as montré dans ce fil où tu as trouvé utile de truquer les images : 

 

il y a 23 minutes, ms a dit :

C'est justement en faisant varier la vitesse  d'acquisition que je peux trouver l'optimum.

Je serais bien curieux de savoir par quel critère tu détermines cet optimum

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