Impossible de Debayer certaines captures RAW de SC. APPEL aux utilisateurs de PixInsight :-)

[Djibi]

Bonjour à vous tous,
le titre dit tout, il faut juste que j'en dise un peu plus pour vous expliquer ce qui me fait appeler à l'aide.

Dans mon processus d'apprentissage, je me suis mis en tête de faire "a la mano" un processus de pré-traitement complet avec PixInsight.

J'ai donc sur une de mes dernières sorties fait un "save all" des captures unitaires.
ASI 533 / acquisition en RAW 16 les fichiers sauvegardés sont des .png par défaut.

Je vous partage un répertoire avec 3 fichiers RAW différents :
https://www.dropbox.com/sh/0n9mz16rn1zj ... np-Ma?dl=0

- un RAW appelé "Chromatisme ....PNG" avec le settings.txt associé : une capture unitaire que j'avais fait sur Mirach pour des tests sur mon phénomène de chromatisme
- un RAW fait sur les dentelles avec les settings associés: une capture unitaire assez ancienne faite avec un objectif de 75mm et ma 533
- un RAW sauvegardé lors d'un livestack de M74

La qualité astro de tous ces fichiers est excécrable mais ils vont illustrer mon propos.
Voici la situation :
- pour tous ces RAW, je peux lancer SharpCap et avec le Folder Monitor Camera, mode "DEBAYER preview" et force RGGB, ouvrir ces fichiers et les manipuler, voir sauvegarder un .fit en RGB avec LiveStack sur un seul fichier, tout marche bien et l'image est bonne. Comme c'est une capture unitaire, on voit mieux avec un autostretch mais tout est là
- le RAW "chromatisme" ouvert dans PIxInsight est comme tout fichier RAW avec sa matrice BAYER, et je peux lancer un process "DEBAYER", il faut forcer le mode RGGB (le mode auto ne marche pas) et l'image RGB est bonne , les autres modes donnent des couleurs bizarre mais l'image original reste là
- sur les autres RAW (et en fait tous les autres RAW produits par SharpCap), je n'arrive pas à obtenir une image proprement "debayerisé": non seulement le mode RGGB ne donne rien mais c'est pareil sur tous les autres mode que j'ai testé un par un, sur le RAW non debayerisé, on voit bien que ce n'est pas la même image, comme si l'image n'était pas linéaire, tout noir avec juste quelques pixels correspondant aux étoiles les plus brillantes


Bref, je m'arrache les cheveux : pourquoi ca marche bien avec un RAW et pas les autres avec PixInsight ? Pourquoi SharpCap ouvre tous ces fichiers normalement ? je n'arrive surtout pas à comprendre pourquoi ces fichiers sont bien lu avec SC et que je n'arrive à rien avec PI.
J'ai cherché partout et je n'ai trouvé rien qui parle de ça, la plupart du temps, on trouve des posts sur "quel matrice pour les camera ZWO" ou autre.

Je vous donne simplement le lien parce que déjà si vous arrivez à faire le debayer d'un des deux RAW qui ne fonctionnent pas chez moi, en m'expliquant ce que vous avez fait, je pourrai rectifier de mon côté.

Je rajoute ci dessous, les copies d'écran de ces captures unitaires sous SHarpCap avec un auto stretch.
Celle qui fonctionne bien sous SC et Pi/

Celle sur les Dentelles (OK avec SC) :

Et celle de M74

et pour finir, une copie PI des RAW sans debayer sur lesquels j'ai lancé un autostrech avec STF, juste pour montrer la nature différentes de ces RAW :

Voilà, si vous avez des idées, si vous déjà rencontré et réglé un truc comme ça, je suis preneur car je ne comprends pas ce qui cloche ...

Merciche à vous !!!

[Djibi]

Je me permets de faire un « up » de ce message, en particulier pour solliciter @pejive et @bemo47.
J’ai commencé à entendre parler des matrices de Bayer grâce au premier tuto de Pejive et je sais que bemo47 a passé du temps sur les formats générés avec la 533.

Je ne sais pas si ce que je constate provient d’un manque de compétence, d’un point logiciel sur ce que génère SharpCap, de la 533 ou un mix des deux
Si vous avez des idées, ce sera ma tournée au bar

[bemo47]

Ah désolé mais là je peux pas regarder ça tant que je suis pas rentré chez moi

[clouzot]

Je n'ai pas eu de souci particulier à ouvrir, par exemple, la brute de M74 avec FITSwork et à forcer le debayering RGGB, pour obtenir un truc assez classique (canal vert plus fort que les deux autres, le bleu étant le plus faible des trois, donc comme attendu). La seule chose que je vois ce sont des histogrammes qui ne sont pas du même niveau selon les cas (cf tes copies d'écran, signal de cheval sur Mirach, signal à la cave pour les dentelles...).

[Djibi]

Bizarre ça @clouzot
Je n’ai pas essayé avec Fitswork, seulement PixInsight

Tu peux m’envoyer le fichier Debayerisé de M74 que tu as obtenu que je le regarde de près ?

Merci !

[clouzot]

Le voici (PNG 8 bits par contre, mais je peux te faire un FITS si tu veux), j'ai juste debayerisé RGGB, et tiré un peu l'histo pour y voir quelque chose, sans toucher à la balance des blancs par contre

[bemo47]

Moi je pourrais tester sous pix

[Djibi]

Merci
Quand je rentrerai du boulot, je partagerai avec vous le brut debayerise avec PI et je testerai avec Fitswork pour vérifier que j’obtiens bien comme toi et que ce n’est pas moi qui subit des crampes mentales à répétition

[Djibi]

Bon,
Le problème commence à très cerné; même s’il me laisse perplexe

Alors @clouzot et @bemo47 j’obtiens comme M’sieur Clouzot :
- j’ouvre le RAW de M74 avec fits work
- je debayerise en RGGB
- je sauve le .fits obtenu
- j’ouvre ce fichier sous PixInsight
- j’ai un joli fichier RGB qui correspond à l’image capturée , auto stretch ou montée d’histogramme le confirme

Mais mon problème initial se confirme :
- le même RAW ouvert sous PI
- debayerisation forcée en RGGB
- résultat inexploitable !!!

J’ai testé toutes les possibilités, y compris les possibilités de ‘hint inputs’ du processus, sans aucun résultat
Le pire est que ce processus Debayer me donne exactement le résultat attendu sur un des RAW (avec les options par défaut du processus EDIT ces options par défaut sont: "raw cfa")

En tout cas, une première étape est passée : le problème vient exclusivement de PixInsight, il reste à comprendre pourquoi il donne le bon résultat dans quelques cas et le mauvais sur la plupart de mes captures RAW.
Il faudrait que des utilisateurs de PI essayent de leur côté. Je change le titre pour les attirer

[clouzot]

Puis-je te conseiller de sauver tes brutes en FITS et pas en PNG ? Au moins, le header du fichier contient les infos de matrice de Bayer (ça n'empêche pas les soucis, malheureusement).

Là, ça sent l'éternel problème de SC qui sauve ses fichiers en partant d'on ne sait où (de la dernière ligne ?), avec des infos style "open using XYZ with some software" bien planquées, et avec un PI qui ne sait plus qui il doit croire.

D'ailleurs, tu pourrais forcer PI à dématricer en GB/RG (RG/GB en inversant l'ordre des deux lignes), sait-on jamais, sur un malentendu...

Sinon, le test des bidons de @bemo47, à faire, car c'est la base.

[Djibi]

En fait, j’ai tout testé : RGGB GRGB etc ....
Du moins toutes les possibilités offertes par PI ...
Ça sent effectivement la manière de les lire et de les écrire (Robin commence en bas à gauche de mémoire de ses posts sur le sujet)
Mais tout ceci ne devrait impacter que le ‘bon’ motif pour le dematricage, je devrais avoir une image normale mais en fausse couleur, pas ce truc difforme que j’obtiens ...

J’avais testé fits vs png et comme les fichiers faisaient la même taille, j’étais resté sur les png
Je vais effectivement prendre des fits désormais : PI a des options d’ouverture spécifiques aux fits vs RAW
Ça me permettra de voir (même si les fits de SC ne sont jamais interprété par PI pour la matrice : il faut toujours forcer le motif)

C’est quand même bizarre que ça marche avec certains et pas avec d’autres, enfin bon, on a vu des trucs plus tordus que ça ...


Heu by the way, c’est quoi le test des bidons ?

[Ubuntu]

Puis-je te conseiller de sauver tes brutes en FITS et pas en PNG ? Au moins, le header du fichier contient les infos de matrice de Bayer (ça n'empêche pas les soucis, malheureusement).

Là, ça sent l'éternel problème de SC qui sauve ses fichiers en partant d'on ne sait où (de la dernière ligne ?), avec des infos style "open using XYZ with some software" bien planquées, et avec un PI qui ne sait plus qui il doit croire.

D'ailleurs, tu pourrais forcer PI à dématricer en GB/RG (RG/GB en inversant l'ordre des deux lignes), sait-on jamais, sur un malentendu...

Sinon, le test des bidons de @bemo47, à faire, car c'est la base.

Ca n'est pas SC qui debayrise mais bien le driver ASCOM... SC lui reçoit une matrice avec les 3 couleurs

[clouzot]

Ah non @Ubuntu dans le cas de la 533 j'imagine (j'espère, même) que notre ami @Djibi utilise le driver direct (pas le ASCOM) avec le mode RAW, auquel cas c'est le signal brut sans débayérisation que reçoit SC (et qu'il sauve, en PNG ou FITS, c'est pareil). Le seul truc où il débayérise avant de sauver avec une caméra en RAW, c'est le save as seen.

Le test des bidons, c'est la spéciale @bemo47 : un bidon rouge, un vert, un bleu, tous de forme et taille différentes, 250m de recul, un télescope, et on capture. J'ai fait la même avec des Lego, ça marche aussi. Puis tu vérifies que tous tes softs ouvrent les fichiers ainsi capturés avec les bonnes couleurs.

Sinon, le test de Steph, qui consiste à mettre la caméra sans rien, devant un écran diffusant un fond uniforme rouge (clic capture), puis vert (clic capture) puis bleu (dernière capture), et tu testes ta chaîne SC-PI comme ça jusqu'à trouver le bon réglage qui permet d'ouvrir chaque capture avec la bonne couleur R, V ou B.

Dans tous les cas, il n'y a qu'un seul bon réglage de matrice, donc c'est vite vu.

[Djibi]

Merci de ces infos
En fait @clouzot je n’ai pas fait ces tests mais j’avais bien testé que j’arrivais à debayeriser sous PI en retrouvant les bonnes couleurs , et avec le bon motif qui n’est pas celui qu’indique le header des .fits produit par SharpCap d’ailleurs

Mais c’était une fois pour voir et ça marchait avec les .png générés
Il se trouve que la , je réalise que parfois ça ne marche pas alors que les paramètres principaux sont les mêmes; je dis ça car la différence doit bien venir de qqs part, d’une option de binning ou que sais-je ...

Et oui bien sûr, j’utilise les drivers fournis par ZWO, j’ai installé ASCOM pour la partie SynScan de ma monture

[clouzot]

Tu te souviens du binning de chaque brute, justement ?

[Djibi]

@clouzot et @bemo47
Alors oui, je me souviens du binning de chaque ... ou plutôt j'ai mes settings.txt qui me le rappellent , ainsi que la taille de la capture (3000 = bin1 / 1500=bin2 et 1000=bin3)

mais j'ai déjà grace à nos échanges, je pense avoir fait le diagnostique principal; l'information était sous mes yeux mais j'ai fait des mauvaises hypothèses de diagnostique initial.
- Il n'y a aucun problème de débayerisation du fichier RAW avec PixInsight
- il y a un probléme d'ouverture du fichier RAW avec PixInsight

Voici le dernier test réalisé :
- ouverture du .PNG de SharpCap avec fitswork
- aucun traitement, save as seen en .FIT avec fitswork
- ouverture du .FIT sous PIxInsight
- et là ... tout marche, j'obtiens mon image normale après debayer en RGGB

Ca se voit sans rien faire (ce que j'avais constaté et qui aurait du me donner la réponse à ce moment là): il suffit de faire un autostretch du RAW, on doit voir l'image initial.
Elle sera moche parce que l'image est moche, en noir et blanc avec la matrice qui apparait, mais l'image doit etre visible.

Je vous montre un copie d'écran sous PIxInsight du .PNG et du .FIT non debayerisés sur lequel je fais un auto stretch:

Maintenant, est-ce un bug de Pix qui ouvre mal, un bug de SharCap dans sa construction du .PNG, je ne sais pas.
Je vais déjà chercher à voir ce que ça donnera en forçant les sauvegardes des RAW en .FITS, j'espère que ça réglera le problème; sinon le header du .FITS pourra peut être aider à mieux faire le diagnostique.

A suivre mais déjà un grand pas est fait,

Encore merci à toi @clouzot , on réfléchit bien mieux à plusieurs et savoir comment s'est passé la même opération ailleurs aide beaucoup à cerner le problème.

[clouzot]

A part lancer 3 idées en l'air, j'ai rien fait de bien utile, mais je suis content que tu aies trouvé une façon de faire

Concernant les bugs des divers logiciels, je n'utilise pas PI (il me fait vaguement peur ce soft), par contre j'ai déjà eu des stacks sauvés en FITS par SC (32 bits, ou 16 bits selon les cas) qui se sont avérés impossibles à ouvrir où que ce soit (ASTAP, Startools, FITSWork). Je n'ai pas spécialement cherché à comprendre ce qu'il se passait, car les fichiers ne valaient pas forcément l'effort de la Photomoche, mais j'ai quand même l'impression qu'il lui arrive de faire n'importe quoi. J'ai aussi eu ce souci de darks faits pour la 294, sauvés en PNG par SC, et qui mettaient les couleurs du stack complètement dans les choux, darks que j'avais fini par reprendre entièrement (de 4 à 60s, c'est loooong) en FITS et qui ne m'embêtent plus depuis. Bref, un peu instable le machin, parfois.

[Djibi]

Je te confirme que mes dark, sauvés en .png ont le même comportement.

Je m'en sers à 99% pour SC, donc pas de problème et je peux le "récupérer" via fitswork pour mes premiers tests de pré-traitement.
Mais je vais partir sur du FITS systématique pour ne plus avoir à gérer ça. Mes darks, c'est de 4 à 15 secondes, déjà que je trouve ça loooonnng, alors avec le passage à 30 et 60 sec, je n'imagine pas !

Sinon perso, j'étais un peu perdu sur PI au début mais ce qui m'a fait basculer, c'est quand j'ai compris la montée d'histogramme : tu peux reprendre un stacks brut de SC et refaire en 5 secondes les réglages des histo pendant le live stack : sur la luminace puis couleur par couleur pour une première balance sur le fond du ciel; ce que je ne pouvais pas faire avec StarTools par exemple.
Après, tous ces soft ont une courbe d'apprentissage et quand tu en as fait une, tu n'as pas forcémment envie de recommencer ailleurs.
D'autant que moi, je partais de zéro sur tous les concepts de l'astrophoto, au début, c'est perturbant !

[clouzot]

Pour cet usage rapide (montée d'histo en quelques secondes, balance manuelle ou automatique), j'ai fini par comprendre que FITSWork ou ASTAP faisaient le job très simplement. Je préfère presque ASTAP d'ailleurs si je n'ai aucun autre traitement à faire et que l'image toute moche me convient, car je sors l'astrométrie en même temps.

[bemo47]

Ah mais j'ai toujours travaillé avec du fits sous pix, ou du xisf format pix, jamais en raw.
D'ailleurs je ne sais pas ce que tu appelles raw pour des images issues de SC et de la 533 ?

[Djibi]

Hello @bemo47 , avec la 533, quand tu selectionnes la sortie "RAW16" SharpCap produit un fichier non debayerisé, suivant les options de format de fichier, ce sera un .FITS ou un .PNG
C'est par exemple le format des darks que tu as fait ou d'un snapshot.
D'ailleurs, avec le "Folder MOnitor Camera", quand tu ouvres un de ces fichiers, il faut activer "FORCE RGGB" dans l'option "Debayer preview", sinon, tu obtiens ça quand tu ouvres ton fichier :

Avec LiveStack, c'est différent : la sauvegarde d'un .FITS "brut" qui contient l'ensemble du stack est un .FITS qui est en RGB, sans besoin d'un dematriçage.
Si tu actives la sauvegarde des captures unitaires, elles ont également besoin d'être debayerisées

[clouzot]

C'est ça, +1 avec Djibi. On peut le vérifier en ouvrant le FITS et en regardant ce qu'il y a en entête (FITSWork le permet, ASTAP aussi).
Le FITS de la capture simple est non dématricé, contient une seule "couche" de pixels. Celui sauvé par LiveStack est déjà dématricé et affiche "3" comme nombre de couches de pixels (une par canal de couleur).