Questionnement capteur, pixels... détails.

[Orion92400]

il y a 9 minutes, Colmic a dit :

si je prends une image issue de la ma caméra couleur, que je la passe en noir et blanc dans Photoshop par exemple, la question qui se pose est : qu'est-ce que j'ai perdu par rapport à la même caméra mono ?

- la sensibilité pour sûr, puisque par rapport à une luminance (avec filtre L) j'ai sur la caméra couleur mes filtres de Bayer qui vont atténuer

- quoi d'autre ?

Très intéressante question, et plus largement c'est un post très intéressant à suivre !

[Fred_76]

il y a 21 minutes, Colmic a dit :

RVB (mono) = RVB (couleur)

ah bon ?

 

Tu raisonnes à temps de pose égal par couche couleur ou bien à temps de pose cumulé égal ?

[Colmic]

il y a 4 minutes, Fred_76 a dit :

Tu raisonnes à temps de pose égal par couche couleur ou bien à temps de pose cumulé égal ?

 

Je raisonne à temps passé égal, ce qui sur le terrain est la seule chose qui compte.

A temps passé égal, admettons une nuit de 5 heures :

- sur la mono j'ai obtenu 4 couches LRVB de 1 heure chacune (en comptant le temps passé à refaire la MAP entre les filtres etc...)

- sur la couleur j'ai obtenu une image RVB de 5 heures de pose

 

On peut donc admettre que la RVB seule issue de la caméra mono est à peu près égale à la RVB issue de la caméra couleur (et qui possède 5x plus de temps de pose).

 

Si maintenant je rajoute la L dans l'équation, alors la mono repasse devant.

[Fred_76]

Admettons que le capteur soit de 4000x4000 photosites et que tu disposes de 5 heures de poses

 

- avec un capteur couleur tu as 5 heures en 1000x1000 pixels pour la couche rouge et la couche bleue et en 2000x2000 pixels pour la couche verte, rien en L.

 

- avec un capteur NB et des filtres LRVB tu auras (déduction faite du temps passé pour refaire la MAP a chaque changement de filtre) soit 1 heure environ en 4000x4000 pixels pour chaque couche rouge, verte, bleue et L, soit 1,5 heure environ en 4000x4000 pour chaque couche rVB, rien en L

 

Au final je ne sais pas comment dire quelle combinaison donnera le meilleur résultat, mais normalement avec ses 4 jeux en pleine résolution, l’image recomposée avec le capteur N&B devrait être meilleure, que ce soit en RVB ou LRVB. Reste à voir la gestion du bruit, mais normalement les capteurs N&B sont meilleurs sur ce point que les capteurs couleur.

[Colmic]

Il y a 4 heures, Fred_76 a dit :

- avec un capteur couleur tu as 5 heures en 1000x1000 pixels pour la couche rouge et la couche bleue et en 2000x2000 pixels pour la couche verte, rien en L.

 

Je suis pas d'accord avec cette affirmation.

Je prends SiriL et j'affiche mon image dématricée. Les 3 couches R, V et B font bien 4000x4000 dans ton exemple, de même que la couche RVB.

Je reprends ce que j'ai écrit plus haut. La matrice de Bayer est comme ceci :

RVBVRVBV

VBVRVBVR

BVRVBVRV

VRVBVRVB

Je prends maintenant la couche R.

Le premier pixel a un filtre R, tout va bien, il a reçu l'information exacte.

Le second pixel a un filtre V, il prend alors la valeur qu'il a reçu mais interpole le résultat avec ses plus proches voisins.

Le 3eme pixel a un filtre B, il prend alors la valeur qu'il a reçu mais interpole le résultat avec ses plus proches voisins.

Le 4ème pixel est de nouveau un V, idem.

Le 5ème pixel est cette fois à nouveau un R, tout va bien il a reçu l'information exacte.

 

Au final, tous les pixels ont reçu de l'information, c'est juste que le logiciel de dématriçage a dû interpoler 3 pixels sur 4 en se basant sur ce que les pixels voisins R ont reçu.

La perte est là, mais elle est minimisée. Et elle sera encore plus minimisée dans le vert puisqu'on a 2 pixels présents sur 4 pour l'interpolation.

 

Dans tous les cas, là où nous sommes d'accord c'est qu'une LRVB provenant de la mono sera dans tous les cas meilleure, même avec 5x fois moins de temps de pose à mon avis.

Pour la RVB, faut faire l'essai et voir si 1 heure de pose pleine trame d'un côté peut concurrencer 5 heures mais interpolé de l'autre.

[lock042]

il y a 22 minutes, Colmic a dit :

Le premier pixel a un filtre R, tout va bien, il a reçu l'information exacte.

Le second pixel a un filtre V, il prend alors la valeur qu'il a reçu mais interpole le résultat avec ses plus proches voisins.

Le 3eme pixel a un filtre B, il prend alors la valeur qu'il a reçu mais interpole le résultat avec ses plus proches voisins.

Le 4ème pixel est de nouveau un V, idem.

Le 5ème pixel est cette fois à nouveau un R, tout va bien il a reçu l'information exacte.

Si tu shoots des zones qui contiennent du Ha c'est plus trop vrai ...

Car tes filtres B et V vont arrêter ce Ha. Et donc ils n'auront pas d'information.

Modifié 9 février 2022 par lock042

[Colmic]

à l’instant, lock042 a dit :

Si tu shoots des zones qui contiennent du Ha c'est plus trop vrai ...

Car ton filtre B et V vont arrêter ce Ha. Et donc ils n'auront pas d'information.

 

Justement j'en parle dans mon article sur les filtres Narrowband.

Maintenant dans ce cas précis comment se passe l'interpolation ?

Sachant que le R a bien reçu tout le flux, mais les V V et B n'ont rien reçu du tout, il interpole uniquement avec les R voisins j'imagine ?

 

[lock042]

il y a 7 minutes, Colmic a dit :

comment se passe l'interpolation ?

mal ^^.

 

C'est d'ailleurs pour ça, que dans le cas extreme d'un filtrage narrowband Ha, il faut extraire le canal CFA avant de dématricer. Sinon l'algo va piocher de l'info dans les plus proches voisins, or cette info sera essentiellement du bruit.

[Colmic]

il y a 2 minutes, lock042 a dit :

C'est d'ailleurs pour ça, que dans le cas extreme d'un filtrage narrowband Ha, il faut extraire le canal CFA avant de dématricer. Sinon l'algo va piocher de l'info dans les plus proches voisins, or cette info sera essentiellement du bruit.

 

D'où l'énorme intérêt de ton algo d'extraction HaOIII pour les dual-band

[Fred_76]

Oui, si seulement 1 photosite sur 4 capte le rouge (ou le bleu), si l'image de la couche R (ou B ) fait la même taille que l'image d'origine, c'est qu'il y a eu un redimensionnement (d'un facteur 4). Idem en V, le facteur est de 2.

[Colmic]

Il y a 7 heures, Fred_76 a dit :

Oui, si seulement 1 photosite sur 4 capte le rouge (ou le bleu), si l'image de la couche R (ou B ) fait la même taille que l'image d'origine, c'est qu'il y a eu un redimensionnement (d'un facteur 4). Idem en V, le facteur est de 2.

 

Mais non ya pas redimensionnement. Ya interpolation avec la valeur des pixels voisins, c'est différent, il n'y a pas redimensionnement dans le sens binning.

Dans le cas présent où l'information des pixels voisins est de 0, alors la perte de résolution est de 50% dans le rouge et le bleu (100% - racine de 1/4), et de 30% dans le vert (100% - racine de 2/4).

Mais l'information n'est pas toujours à 0 non plus.

[Fred_76]

Il y a 8 heures, Colmic a dit :

 

Mais non ya pas redimensionnement. Ya interpolation avec la valeur des pixels voisins, c'est différent, il n'y a pas redimensionnement dans le sens binning.

Dans le cas présent où l'information des pixels voisins est de 0, alors la perte de résolution est de 50% dans le rouge et le bleu (100% - racine de 1/4), et de 30% dans le vert (100% - racine de 2/4).

Mais l'information n'est pas toujours à 0 non plus.

Redimensionnement ne signifie pas nécessairement réduction de l’image ! Ça marche dans les deux sens et quand on agrandit, ça interpole pour avoir les valeurs manquantes, c'est d’ailleurs pour ça que divers algorithmes sont proposés pour le redimensionnement dans Photoshop par exemple.

 

Donc je maintiens : quand on extrait la couche rouge d’une brute de 4000x4000 pixels, on récupère un fichier de résolution native 1000x1000 pixels. Si le logiciel retourne une image de 4000x4000 c’est qu’il l’a redimensionnée à cette taille tout simplement.

[Alhajoth]

Je ne sais pas si les brutes sont définies comme ça.

À mon envie, lors de ton "extraction", des méta-informations indiquent une taille de 4000x4000 pixels, ainsi que la matrice de utilisée (Bayer ou autre), bien que ça ne soit pas obligatoire, ce qui permet de savoir où se situent les trous. ET derrière, effectivement, suivent les 1000x1000 pixels. Mais qu'est-ce qui définit la taille, dans le fichier, finalement ? Sûrement pas uniquement les informations captées par les photosites, qui sont alignées en rang d'oignons, mais bien l'en-tête.

Mais il est possible que je spécule.

Modifié 10 février 2022 par Alhajoth

[Colmic]

il y a 32 minutes, Fred_76 a dit :

Donc je maintiens : quand on extrait la couche rouge d’une brute de 4000x4000 pixels, on récupère un fichier de résolution native 1000x1000 pixels. Si le logiciel retourne une image de 4000x4000 c’est qu’il l’a redimensionnée à cette taille tout simplement.

 

Encore une fois j'en appelle à @lock042

Le logiciel en l'occurrence, c'est SiriL dans mon cas.

[lock042]

Siril retourne une image 4 fois plus petite.

Si dans les scripts on voit rien c'erst qu'on Drizzle cette image dans le process.

[Fred_76]

il y a 20 minutes, lock042 a dit :

Si dans les scripts on voit rien c'est qu'on Drizzle cette image dans le process.

 

Tu veux plutôt dire que tu redimensionnes. Paske le drizzling, c'est pas la même chose en post traitement.

[Colmic]

il y a 49 minutes, lock042 a dit :

Siril retourne une image 4 fois plus petite.

Si dans les scripts on voit rien c'erst qu'on Drizzle cette image dans le process.

 

Oui Cyril je connais très bien l'extraction_Ha et HaOIII, c'est moi qui ai créé le script rappelle-toi

Là je parle pas de l'opération d'extraction d'une couche, mais de l'opération de dématriçage.

Comment ça bosse exactement ?

 

Il y a 1 heure, Fred_76 a dit :

Donc je maintiens : quand on extrait la couche rouge d’une brute de 4000x4000 pixels, on récupère un fichier de résolution native 1000x1000 pixels. Si le logiciel retourne une image de 4000x4000 c’est qu’il l’a redimensionnée à cette taille tout simplement.

 

Si tu extrais une couche R, V ou B, à mon sens c'est encore différent de l'opération de dématriçage.

Là on raisonne couche par couche alors qu'il faut à mon sens raisonner au global pour pouvoir dire quelle est la perte exacte de résolution.

 

Si on raisonne couche par couche, alors je pense que mon calcul précédent est bon : perte de 50% de résolution en R et en B, et de 30% en V.

Facile à calculer je repars de la matrice d'origine :

RVBVRVBV

VBVRVBVR

BVRVBVRV

VRVBVRVB

 

Couche R pure par extraction :

R___R___

___R___R

__R___R_

_R___R__

 

Reste 8 pixels sur 32.

Il reste donc (racine 1/4) de résolution dans le rouge soit 50%, donc perte de 50%

 

Idem pour le bleu en extraction pure de la couche.

 

Et pour le vert, il reste 16 pixels sur 32.

Il reste donc (racine 2/4) de résolution dans le vert, soit 70%, donc une perte de 30%

 

 

[Larbucen]

Merci Michel pour ton passage ici et pour toutes ces informations pertinentes.

 

Merci également à Cyril qui nous apporte des éléments logiciel pertinent.

 

Merci à tous pour vos interventions.

 

Je suis bien heureux que ma question naïve ait généré un post si intéressant.

[Colmic]

Il y a 22 heures, Fred_76 a dit :

Reste à voir la gestion du bruit, mais normalement les capteurs N&B sont meilleurs sur ce point que les capteurs couleur.

 

Ah j'avais pas percuté là-dessus.

Dans mon cas précis, je compare la 6200MC et la 6200MM, j'ai un exemplaire de chaque donc je peux faire plein de tests comparatifs dessus.

C'est strictement les mêmes capteurs, sur le premier on a déposé des filtres de Bayer, sur le second on met un filtre devant.

Si je raisonne en rendement pur, alors oui on peut considérer que les filtres RVB qu'on colle sur une mono auront un rendement un peu meilleur que les filtres de Bayer qu'on dépose sur le capteur.

C'est pour cette raison que je dis que RVB(mono) = RVB(couleur) sensiblement.

Car dans le premier cas tu as 5x moins de temps de pose que dans le second cas, la perte de résolution est compensé par le RSB bien plus important qui permet un bon Drizzle.

 

Si on ajoute la L dans l'équation, alors ya absolument pas photo entre les 2, la LRVB est mieux résolue.