chonum

Plus de gamma chez ZWO

Recommended Posts

Bonjour !

 

en mettant à jour la DLL ZWO dans Genika et en lisant la - très - succincte release note aux développeurs, une ligne disait que le gamma avait été supprimé.

Cela, dit comme cela, m'a paru tellement bizarre que je crois que l'information n'a pas atteint mon niveau de conscience et a été filtrée avant. bref.

 

Je mets à jour la DLL, et oui, effectivement, le gamma n'est plus disponible. L'attribut dans le SDK a juste disparu.

Après un échange avec eux, ils me rapportent que des clients se sont plaint car leur brutes étaient inexploitables à cause d'un réglage de gamma inadapté. D'ailleurs je vous confisque votre four à microonde car vous risquez de mettre un oeuf dedans.

J'apprends incidemment que le gamma est fait au niveau du driver, et que si je veux l'avoir, je devrai l'implémenter dans Genika.

Effectivement si c'est fait au niveau logiciel, cela coûte cher : au lieu de travailler sur la profondeur de bit interne (par exemple 10 bits chez ZWO pour une sortie 8 bits en mode "rapide"), on travaille juste sur 8 bits. Et le gamma consomme beaucoup de dynamique par définition !

Mais on fait normalement le gamma au niveau du FPGA sur un CMOS, donc avec une profondeur de bit encore décente. Sur un CCD c'est fait au niveau de la conversion sur l'analogique, c'est encore mieux. 

Mais on trouve de petits arrangements en termes de coût ailleurs aussi. Par exemple chez PGR, le FPGA est sous dimensionné et lorsqu'on passe en mode raw (FPGA désactivé), on a le débit max, mais on perd le gamma (entre autres).

Dans l'absolu, il faut que, le FPGA gère bien sûr le gamma à la volée à pleine vitesse.

 

Bref, tout cela pour dire que les utilisateurs de ZWO en solaire et lunaire vont être très pénalisés par cette décision.

Je n'implémenterai pas de gamma dans Genika, le faire au niveau soft n'a pas de sens.

Aussi je suggère aux utilisateurs de ZWO qui utilisent le gamma de leur écrire. Mais cela restera soft et sur 8 bits.

Le workaround en attendant est de remplacer la DLL courante ASICamera2.dll 1.13.1.12 par une version antérieure, mais évidemment à terme cela n'est pas viable du fait des nouvelles caméras qui arrivent régulièrement.

Je ne sais pas comment le gamma est géré chez QHY, cela serait intéressant à savoir car si ils otn un FPGA, alors cela devient vraiment la bonne alternative en lowcost.

Je commence à me demander si ces caméras pas chères ont un FPGA tout court...

 

 

 

 

 

Edited by chonum

Share this post


Link to post
Share on other sites
Publicité
En vous inscrivant sur Astrosurf,
ce type d'annonce ne sera plus affiché.
Astronomie solaire : la bible est arrivée !
400 pages, plus de 800 illustrations !
Les commandes sont ouvertes sur www.astronomiesolaire.com

Ah flûte, c'est une balle dans le pîed ça.

Je le fait en post-traitement, mais là franchement, je n'ai pas envie de faire la mise à jour.

 

Pourquoi : c'est quand même mieux de faire un réglage grossier de plage à l'acquisition.

J'utilisais ça principalement dans Sharpcap en CP pour prévisualiser avant de rétablir et de laisser tourner.

Le changement de gain a d'autres implications et ne donne pas la même facilité sur la dynamique du signal. Changer le gamma/seuil permet d'évaluer un résultat sur un échantillon avant une acquisition prolongée.

Je n'ai pas touché à ça sur Genika pour le moment mais je comprends l'utilité.

 

Est-ce la responsabilité de ZWO cette connerie ou de ceux qui mettent le mauvais gamma dans leur paramétrage du logiciel ?

j'ai un doute sur l'explication, mais ça sent plutôt le gain de quelques sous pour virer un composant.

 

Share this post


Link to post
Share on other sites

Non même pas, ils le font au niveau du driver apparemment.

Je ne comprends pas.

Mais de toute façon, fait en soft, c'est vrai que cela devient moins intéressant.

J'en viens à penser que leurs caméras n'ont pas de FPGA, il faudrait que j'en ouvre une pour voir.

 

Share this post


Link to post
Share on other sites

Merci à toi pour l'info

 

Moi qui commence par régler le gamma pour ne pas avoir de "hachure" dans l'histogramme, je suis pas prêt de faire une MAJ de mes drivers !

 

 

Pierre

Share this post


Link to post
Share on other sites

On va tenter de se mettre à la place d'un astronome amateur qui a l'habitude de photographier sa plus étoile Nathalie, grâce à son téléphone portable en tout automatique.

Il faut bien comprendre qu'en astronomie, lui parler de faire des 'flats', ça lui donne de l'urticaire.

Pour les 'offsets', il en fait des boutons qui démangent.

Et la mise en station lui provoque la boule au ventre.

 

Il rêve d'un instrument astronomique tout automatique : juste à décider de la cible avant d'aller se coucher et l'appareil se débrouille tout seul.

Choisit les filtres les plus adaptés, les temps de pose etc.

Au petit déjeuner, notre astronome pourra insérer un texte avec les images de la nuit et le tout partira sur les forums : un minimum de 3 ou 4 pour bien être reconnu.

Il y a aussi l'option du 'Tout Tout Auto', où le texte de commentaire des images est automatique aussi : option possible, débutant, confirmé ou expert.

Ceci est le doux rêve de bien des astronomes amateurs à qui l'on promettait d'obtenir les mêmes images que sur le carton d'emballage.

< Vous en avez rêvé et Sony l'a fait, ou un autre. >

 

Alors entendre l'ami Fréd au bord des larmes à cause d'un réglage qui disparait, notre amateur ne comprends plus et cache sa joie de honte.

Puis finalement pose la question inévitable, pour quelqu'un qui voudrait ne pas passer à côté de quelque chose :

 

<<   Dis tonton Fréd, ça sert à quoi ce réglage de gamma à la prise de vue ?  >>

<<   Et toi Lucien, ferme ta gueule : je n'avais déjà rien compris à ton histoire de signal tordu... >>

 

Lucien

Share this post


Link to post
Share on other sites

Comme Lucien et Asp06, je laisse le gamma à 1, sauf cas particuliers (protu).

Cela ne sert à rien de triturer la courbe de réponse si cela se fait sur la base d'un signal en 8 bits. Autant le faire au traitement une fois les images empilées.

Au fait Fred,  chez Basler le gamma est bien appliqué sur le signal 12 bits ?

Share this post


Link to post
Share on other sites

oui, c'est l'idée que j'en ai : on change le gamma lors de la visualisation de l'image finale qui a potentiellement une grande dynamique adaptée à cet usage.

Share this post


Link to post
Share on other sites

En fait moi je m'en fiche un peu, la Basler le fait en interne effectivement sur le FPGA.

Néanmoins comme Christian le dit c'est pratique pour la focalisation, et en Ha j'en utilise car étant sur 12 bits, on ne perd pas beaucoup, et cela est très pratique pour deux choses : permettre un bon contraste natif en ha sur la surface (gamma positif), exposer d'entrée correctement la surface et les protubérances sur le limbe (gamma négatif <1), et j'avais des essais et j'en avais conclu à l'époque que le logiciel de traitement accrochait mieux ses ancrages (probablement par correlation de phase) si les images sont à minima contrastées.

Mais effectivement sur une image déjà 8 bits, c'est à la base dommage.

 

 

Share this post


Link to post
Share on other sites

Christian m'a pris de vitesse.

 

Il y a intérêt dans 95% des cas de figure de figure à laisser le Gamma à 1: réponse linéaire.

Pour ne pas perdre d'information si l'on serre trop l'échelle des intensités par exemple.

Et pourtant pour Gaston, c'est tentant de contraster Jupiter (ou une autre) à la prise de vue car ça parait plus croustillant à l'écran !

 

Et si Mimile joue du Gamma avec une caméra couleur, étant donné que les Gains des canaux sont assez indéfinis disons, on va jouer des coudes ensuite pour obtenir des couleurs satisfaisantes.

En mode linéaire on fait se qu'on veut ensuite : en mode TORDU ça sera délicat pour les traitements ultérieurs.

 

Il y a des cas où le réglage de Gamma à la prise de vue peut être intéressant :

- comme le disait Christian, pour faciliter le réglage de la mise au point par exemple en contrastant l'image en temps réel,

- pour contraster à la prise de vue (un peu) afin de faciliter le travail des algorithmes d'alignement des images dans des cas de contrastes très faibles.

Un exemple : Vénus en plein jour qui se détache peu du fond de ciel. Il y a d'autres exemples.

Mais c'est à manier avec des pincettes.

 

Lucien

Share this post


Link to post
Share on other sites
30 minutes ago, asp06 said:

oui, c'est l'idée que j'en ai : on change le gamma lors de la visualisation de l'image finale qui a potentiellement une grande dynamique adaptée à cet usage.

Dans l'absolu oui, et encore pas sûr quand c'est fait sur un CCD avant numérisation.

Mais les logiciels aiment bien le contraste, d'ailleurs pour faire des corrélations de phase dans Genika (focus par exemple, encore que ce soit plus compliqué), avoir une image contrastée à minima est plus efficace.

Et je connais des imageurs solaires qui n'hésitent pas sur le gamma, dont un qui n'est pas vraiment un manche :)

 

Share this post


Link to post
Share on other sites
il y a 11 minutes, christian viladrich a dit :

Cela étant, cela peut être pratique de jouer sur le gamma (à la hausse ou à la baisse) pour faciliter la vision des détails pendant la phase de mise au point.

C'est ce que je fait, c'est pratique, ça va tourner au pifomètre pour la map sans ça. (dsl Fred. je finis avec mes yeux)

Edited by lyl

Share this post


Link to post
Share on other sites

Et il y a aussi les animations, c'est vraiment bien d'avoir une image pas loin de la finale sans passer par des réglages de contraste/lum par exemple dans virtualdub qui ne sont pas aussi efficaces.

 

Share this post


Link to post
Share on other sites

Je me demande si ce n'est pas la charge CPU qui fait qu'ils l'enlèvent. Ca demande des divisions et sur les grands capteurs actuels, ca pompe.

D'ailleurs il suffit de voir dans Genika la différence de CPU entre une Basler et une ZWO.

 

Share this post


Link to post
Share on other sites

Ben moi j'attends que génika gère les altair, elles ont conservé leurs gamma.

J'aime bien mon gamma dans génika pour le solaire.

Donc si je comprend bien, il ne faut pas mettre à jour ces drivers ZWO si on veut conserver le gamma.

 

Share this post


Link to post
Share on other sites

Non il faut remettre une DLL plus ancienne dans Genika.

La version que j'ai mise hier utilise la nouvelle, mais la précédente c'est bon.

 

Share this post


Link to post
Share on other sites

Oui Frédéric,

appliquer une table "LUT' équivalente au réglage du Gamme choisi par l'utilisateur charge fortement le CPU et en 16 bits et n'en parlons pas pour faire du quasi temps réels à l'écran sur des tailles d'images qui ne font que grandir.

En programmation par des "threads parallèles" c'est encore envisageable.

 

Lucien

Share this post


Link to post
Share on other sites

Heureusement il y a encore les Basler!!! :D  pour le Gamma en solaire  H-alpha je ne suis jamais à 1 

Share this post


Link to post
Share on other sites

Aucune importance... j'en ai fait tout un stock !

 

c700x420.jpg

 

 

Non sérieusement, c'est en effet bien dommage car je m'en servais pour la MAP !

 

Cordialement,

Quentin

 

 

  • Haha 2

Share this post


Link to post
Share on other sites

Gama 3 en 1 flats/darks/offsets depuis le XIXe siècle. ^_^

 

En cherchant un peu, il y a plein de bonnes caméras qui résolvent ce problème proprement mais comme la plupart d'entre vous veulent gratter 3 francs six sous en se ruant sur des chinoiseries alors il ne faut pas s'étonner. ^_^

  • Sad 1

Share this post


Link to post
Share on other sites

"Non, sérieux, tu mets du gamma ?", la question est zarbie, y'a des caméras qui affichent l'inverse du gamma ( je ne sais pas pour la Basler ).

Chuis sûr qui y'a des gens qui croient  augmenter le gamma et en fait ils le diminuent, pis des gens qui croient le diminuer et en fait ils l'augmentent.

Ce n'est pas bien grave, mais c'est rigolo. xD

Share this post


Link to post
Share on other sites

Comme tu dis, c'est pas bien grave. Mais quand tu vois la tronche de l'histogramme dès que tu quitte le gamma "1" (ou 100%, ou n'importe quelle autre valeur) tu prend peur.

Des trous partout façon peigne, et un rendu en planétaire qui est déplorable. Maintenant pour faire la mise au point c'est bien pratique (on fait sortir un satellite assez facilement).

Du coup c'est pas une grosse perte à mon avis et il sera préférable au besoin de faire cette manipulation sur une image à forte dynamique (16 ou 32 bits) au post traitement plutôt que sur une image brute en 8 ou 12 bits !

 

En solaire j'imagine le désarroi de Fred car la dynamique est très (trop ?) grande pour permettre un rendu linéaire correct et en CP, c'est évidemment la norme car sans cet artifice adieu les belles volutes de nébuleuse.

 

Marc

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now