Bernard_Bayle

Question dé-matricage bayer Firecapture ( ASI462MC)

Messages recommandés

Bonjour tout le monde .

 

Nouvel adepte Firecapture  ( 2.7.10 actuellement ) , pour son autoguidage en Planétaire ,

je me pose des questions sur le paramètre   vidéo en matrice de bayer ou vidéo dé-matricage de bayer ( donc couleur )

 

je viens de faire des tests :

=>  paramètre  vidéo =  dé-matricage , donc vidéo couleur

   Crop 800x600 , Gain 221   Expo : 1

   Taille Fichier  6470 méga ,  vidéo 13811 images , vitesse moyenne 115 images/s

 

=>  paramètre  vidéo = en matrice de bayer  , donc vidéo N/B

   Crop 800x600 , Gain 221   Expo : 1

   Taille Fichier  6474 méga  , vidéo 13810 images , vitesse moyenne 115 images/s

?????

 

Donc strictement la même vitesse et strictement le même nombre d'images

 

Je ne comprend pas ...........

dans ce cas , je ne capte pas bien l’intérêt de rester en "matrice de bayer "  à se péter les yeux

 

Merci de vos réponses

 

Bernard_Bayle

Modifié par Bernard_Bayle

Partager ce message


Lien à poster
Partager sur d’autres sites

Salut Bernard,

C'est conseillé de rester en matrice de bayer donc en noir et blanc pendant que tu filmes, je suis pas un spécialiste de la question mais il me semble que cela restitue mieux les informations puisque les données sont brutes. Ensuite les informations couleurs sont restituées avec nos logiciels de traitement préférés.

Par contre tu as une option dans Firecapture qui te permet d'avoir ton image débayerisée pendant que tu fais tes réglages, ta MAP etc et au moment de filmer, la séquence passe en matrice de bayer. C'est de mémoire dans les options de matrice de bayer...

Un lien qu'Alain avait posté dans un précédent post :

 

image.png

  • J'aime 3

Partager ce message


Lien à poster
Partager sur d’autres sites

Je ne comprends pas, debayeriser la vidéo ne change évidemment rien au mode d'enregistrement.

Pour cela il faut cocher la case "Forcer l'enregistrement en couleur (Non recommandé)" il me semble.

 

Marc

 

Doublé par wilexpel, mais bon on ne peut pas regarder le rugby et répondre aux post !

Modifié par patry

Partager ce message


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

C'est conseillé de rester en matrice de bayer donc en noir et blanc pendant que tu filmes

 

Oui Will c'est ce que j'ai toujours lu  et ce que tout le monde pratique ,

passer les parametres  "avec" "sans " matrice de bayer , j'ai pas de soucis avec ça

la question c'était ça ne change rien  en taille fichier , en images/s et donc en nombre d'images

alors que la légende urbaine c'est  + d'images, - de taille fichiers

 

il y a 42 minutes, patry a dit :

Je ne comprends pas, debayeriser la vidéo ne change évidemment rien au mode d'enregistrement.

 

entre autre les excellents tuto de   @Christophe Pellier  

 

aa.JPG.50f1786fdfd13fdd3e198b76de742607.JPG

 

Lire ci dessus   ↑ ↑

 

Bernard_Bayle

Modifié par Bernard_Bayle
  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 1 heure, patry a dit :

mais bon on ne peut pas regarder le rugby et répondre aux post !

 

cccccccccccccc.JPG.04b53119de8cd6bf5aca034bf784d3c2.JPG

 

Toulouse  2ème budget de Top 14 ,  Castres 10 ème Budget de Top14 ...........

le fric ne fait pas tout  , c'est ça la morale

  • J'aime 2
  • Triste 1

Partager ce message


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

la question c'était ça ne change rien  en taille fichier , en images/s et donc en nombre d'images

alors que la légende urbaine c'est  + d'images, - de taille fichiers

Hum, je crois comprendre où tu veux en venir. Les vitesses d'acquisition et la taille du fichier ne changent pas et pour moi c'est normal, les enregistrements sont similaires. Par contre enregistrer en SER au lieu de l'AVI te donne tes vidéos moins lourdes, c'est peut être avec cela qui tu fais l’amalgame ?

Partager ce message


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

SER au lieu de l'AVI te donne tes vidéos moins lourdes,

 

Oui, j'ai toujours utilisé les acquisitions en Ser  et toujours en  "dé-bayerisé "  pour le confort des yeux :-)

 

Par contre si même vitesse et taille fichier que l'on "dé-bayerise "  ou  que l'on  ne  "dé-bayerise" pas 

je ne vois pas l’intérêt  de se péter les yeux à l'acquisition  (suivre la map est infaisable )  quand on est en "matrice de bayer "  ??

 

Je crois que Christophe.P @Christophe Pellieravait fait des Tests là dessus  

 

Bernard_Bayle

Modifié par Bernard_Bayle

Partager ce message


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

Lire ci dessus   ↑ ↑

 

C'est exactement ce que j'ai dit. Par défaut, FC enregistre en RAW (en tout cas sur ma version 2.7.10 avec une case qui est nommée "Forcer l'enregistrement en couleur (Non recommandé)" décochée).

Du coup quelque soit la débayerisation A L'ECRAN, le fichier est le même (ce que tu observe).

 

62ad9d1b70b56_Clipboard1.jpg.13ce37a6128e13f42dc95f3cd43fab50.jpg

 

Quelque soit l'état de la première case, l'enregistrement est toujours EN RAW (tu peux vérifier avec Autostakkert) et le flux est monochrome. Ensuite les outils de traitement font le dématriçage tout seuls, et tu traite en couleur comme d'habitude.

Mais dans mon essai réalisé à l'instant (dummy cam) 1000 images en 640x480x8 bits couleur cela fait 300Ko ... c'est correct.

Par contre la première case doit indiquer dans le fichier que le flux est couleur, et quel type de matrice de bayer est utilisé. A vérifier sur AS!3. Je n'ai pas pu essayer la seconde case qui plante (dummy cam probablement).

 

CQFD !

 

Marc

 

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Ce qui me fait penser qu'avec l'ASI 462 en IR >800~850nm, donc avec la caméra qui se comporte "comme" une caméra monochrome, on a tout intérêt à décocher la case pour enregistrer en RAW/Monochrome (ColorID 0 dans le fichier SER) plutôt que RAW/BayerXXXX (ColorD 8~11). Le traitement se fera en monochrome et non en couleur, ce sera mieux !

 

Marc

 

  • J'aime 1

Partager ce message


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

CQFD !

 

Je n'ai aucun souci avec tout ce que tu décris  , ça me parait très simple à comprendre d'ailleurs

 

par contre mes interrogations étaient ...pour résumer ......

 

"" Étonnement que  même vitesse et taille fichier que l'on "dé-bayerise "  ou  que l'on  ne  "dé-bayerise" pas , c'est tout .  ""

 

Bernard_Bayle

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Parce que la débayerisation ne consomme pas beaucoup de ressource CPU pour l'affichage. Peut être même que c'est réalisé par la carte graphique à la volée.

Par contre j'ai vérifié dans le fichier SER, et cocher/décocher la première case n'a pas changé pas l'entête du SER qui n'indique par ColorID=0. Je referais des essais plus tard pour vérifier mais c'est clairement un bug pour moi !

 

Marc

 

Partager ce message


Lien à poster
Partager sur d’autres sites

 

Notice de FireCapture ...

 

Citation

 

Until quite recently the preview would be in mono during capture reverting to debayered colour when the recording stopped. From FC version 2.7.03, however, when debayer is ticked the preview is in colour regardless of whether or not you are recording. You can force Firecapture revert to the older action of the preview being in mono during capture by ticking the option ‘Disable debayering of preview whilst recording’. Ticking this setting gives you an extra visual clue that you are recording, but removes the a key benefit that colour preview brings during capture, which is an improved ability to refocus during your recordings.

 

Although not recommended, for the speed and data storage limitations described above, you can force Firecapture to record in colour if you wish by ticking the ‘Force record in colour’ option under the debayer selection list (see figure above). This might be useful for test purposes or for single frame generation where you might want to view the debayered result right away. NB In 16-bit mode you cannot force Firecapture record in colour, you can only record in raw undebayered mode.

 

Do note that unless ‘Force record in colour’ is ticked, the data recorded via Firecapture is always in the preferred undebayered state (not in colour) regardless of whether the debayer toolbar button is ticked or not ticked. Really the debayer button now applies just to the preview screen and whether that is displayed in colour or not in colour.

 

 

J'ai refait des tests vite fait et effectivement il n'y a que dans le mode "Forcé" que le fichier est 3x plus gros "

 

--- SER HEADER
fileId = LUCAM-RECORDER SerLuID = 0 SerColorID = 101 littleEndian = 0
width = 640 height = 480 pixelDepth = 8(8) frameCount = 1000
--- SER HEADER END
Channels : 3 8 bits/channel
Size in pixels : 640 x 480 pixels 0.3072 Mpixels
Size for file as opened : 878.91 MBytes
Size for one image : 900 KBytes ( Calculated non compacted )

 

Donc on est en RGB, 3 plans BGR => 900Ko

Second fichier

 

--- SER HEADER
fileId = LUCAM-RECORDER SerLuID = 0 SerColorID = 0 littleEndian = 0
width = 640 height = 480 pixelDepth = 8(8) frameCount = 1000
--- SER HEADER END
Channels : 1 8 bits/channel Raw file ?
Size in pixels : 640 x 480 pixels 0.3072 Mpixels
Size for file as opened : 292.97 MBytes
Size for one image : 300 KBytes ( Calculated non compacted )

 

On est en monochrome, donc un seul plan, pas de débayerisation.

3e fichier

 

--- SER HEADER

fileId = LUCAM-RECORDER SerLuID = 0 SerColorID = 8 littleEndian = 0

width = 640 height = 480 pixelDepth = 8(8) frameCount = 1000

--- SER HEADER END

Channels : 3 8 bits/channel

Size in pixels : 640 x 480 pixels 0.3072 Mpixels

Size for file as opened : 292.97 MBytes

Size for one image : 900 KBytes ( Calculated non compacted )

 

On a bien une image couleur, mais "à débayeriser".

 

Marc

 

Modifié par patry
  • J'aime 1

Partager ce message


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

Notice de FireCapture ...

 

Très intéressant   , j'ai bien fait d'ouvrir un post .................

 

Pour moi c'est mieux traduit :

<<<<<<<< Jusqu'à tout récemment, l'aperçu était en mono lors de la capture et revenait à la couleur décalée lorsque l'enregistrement s'arrêtait. À partir de la version FC 2.7.03, cependant, lorsque Debayer est coché, l'aperçu est en couleur, que vous enregistriez ou non. Vous pouvez forcer Firecapture à revenir à l'ancienne action de l'aperçu en mono pendant la capture en cochant l'option "Désactiver le débayer de l'aperçu pendant l'enregistrement". Cocher ce paramètre vous donne un indice visuel supplémentaire que vous enregistrez, mais supprime l'avantage clé que l'aperçu des couleurs apporte pendant la capture, qui est une capacité améliorée de recentrage pendant vos enregistrements. Bien que non recommandé, pour les limitations de vitesse et de stockage de données décrites ci-dessus, vous pouvez forcer Firecapture à enregistrer en couleur si vous le souhaitez en cochant l'option "Forcer l'enregistrement en couleur" sous la liste de sélection du débayer (voir figure ci-dessus). Cela peut être utile à des fins de test ou pour la génération d'une seule image où vous souhaiterez peut-être afficher immédiatement le résultat débayerisé. NB En mode 16 bits, vous ne pouvez pas forcer l'enregistrement Firecapture en couleur, vous ne pouvez enregistrer qu'en mode brut non débayer. Notez qu'à moins que "Forcer l'enregistrement en couleur" ne soit coché, les données enregistrées via Firecapture sont toujours dans l'état non débayer préféré (pas en couleur), que le bouton de la barre d'outils de débayer soit coché ou non. Vraiment, le bouton debayer s'applique désormais uniquement à l'écran de prévisualisation et à ce qu'il soit affiché en couleur ou non.  >>>>

 

il y a 42 minutes, patry a dit :

J'ai refait des tests vite fait et effectivement il n'y a que dans le mode "Forcé" que le fichier est 3x plus gros "

 

Bernard_Bayle

  • J'aime 1

Partager ce message


Lien à poster
Partager sur d’autres sites

@Christophe Pellier  Désolé sur la méprise de l’auteur de ces tests

@wilexpel@patry

 

En fouinant sur le net au sujet des versions 2.7 de Firecapture j'ai trouvé un point que je n'avais pas vu !  :

 

Auteur  Copyright ©  SkyInspector

PARAMETRE HAUTE VITESSE HS  :

 

Une autre façon d'augmenter le fps, si vous êtes limité en débit de données,
est de cocher la case HS ou haute vitesse, si cette option est disponible
pour votre appareil photo. Pour les caméras ZWO, cocher le mode HS augmente
la bande passante en réduisant la profondeur de bits à laquelle le convertisseur
analogique-numérique (ADC) du capteur fonctionne - en le faisant passer
du fonctionnement habituel de 12 bits à 10 bits.
Étant donné que la sortie
numérique de la caméra sera ultérieurement réduite aux 8 bits les plus significatifs,
vous ne pouvez pas déterminer rétrospectivement à partir des données
si le capteur ADC fonctionnait à 12 bits ou 10 bits, sauf en sachant
si HS était coché ou non. .

 

Bien que le fait de cocher le mode HS puisse souvent doubler la fréquence
d'images lors de l'imagerie de grandes zones avec des expositions courtes,
vous devez être conscient qu'il y aura une légère augmentation du bruit de
lecture dans les images vidéo résultantes.
En règle générale, cependant,
la principale cause de bruit dans l'image empilée est le bruit de tir (quantique)
plutôt que le bruit de lecture, de sorte que l'augmentation est plutôt
académique et les images supplémentaires dans la pile qui sont générées
devraient plus que compenser la légère augmentation de la lecture. bruit.
Même ainsi, si vous n'êtes pas limité en débit de données mais plutôt
en temps d'exposition, il est judicieux de décocher le mode HS .

 

Auteur  Copyright ©  SkyInspector

 

En pensez vous quelque chose ?

 

Bernard_Bayle

 

 

Modifié par Bernard_Bayle

Partager ce message


Lien à poster
Partager sur d’autres sites

Erreur

 

Modifié par patry

Partager ce message


Lien à poster
Partager sur d’autres sites

Personnellement la case HS est toujours cochée chez moi (je n'ai pas vu de grande différences sans de toute façon) sauf les rares fois où je capture en 16 bits.

 

Pour revenir sur le format SER et pour être exhaustif, il faut comprendre que le format prévoit beaucoup de mode d'enregistrement (comme le fit d'ailleurs, j'y reviendrais plus tard).

Le format SER est un format qui permet d'enregistrer une vidéo, donc une suite composée d'images.

Chaque image est définie en monochrome (0), Bayer RGGB (8), Bayer GRBG (9), Bayer GBRG (10), Bayer BGGR (11) mais aussi Bayer CYYM (16), Abyer YCMY (17), ou encore RGB (100) ou BGR (101).

L'organisation des données permet de savoir comment sont codées les informations (big endian ou little endian, c'est "informatique" pour savoir où se trouve les données de poids fort -les dizaines par rapport aux unités pour faire simple-)

La taille de l'image en nombre de pixels (largeur et hauteur).

Le nombre de pixel par plan 1..16 permet de savoir comment sont codés les pixels. A partir de cette valeur on va trouver comment sont stockées les informations par pixel (c'est lié au au nombre de plan, issu du type de format (mono, Bayer, ... ou RGB/BGR) et vaut 1 ou 3, fois le nombre de pixels par plan (division entière par 8 + 1). On va ainsi avoir 1 octet (mono/Bayer <= 8bits), 2 octets (mono/Bayer > 8 bits), 3 octets (RGB <= 8bits) ou 6 octets (RGB > 8 bits).

Enfin le nombre de trames donne le nombre de fois que chaque image est répétée.

Des informatios "personnelles" libres pour identifier la capture et l'auteur, puis la "date" (8 octets) de la capture en temps local puis en UTC. Eventuellement, à la fin des données, N x 8 octets pour horodater chaque image !

 

J'avais écrit (il y a longtemps) un programme pour corriger le défaut d'enregistrement invalidant l'entête du SER. En effet, le nombre d'image doit être mis en place à la fin de la capture mais au début du fichier. En cas de soucis, y compris sur la dernière image, cet entête n'est pas mis à jour et les données sont illisibles. Sauf à analyser le fichier, sa taille, les données qu'on y trouve, et estimer à postériori la meilleure valeur possible pour coller au fichier. Quitte à saisir une valeur manuellement et regarder ce que cela donne. Cela m'a sauvé de nombreuses captures au début des drivers des caméras.

 

Le format FIT est sensiblement plus "complet" car il peut enregistrer en 8 bits, 16 bits, 32 bits, 64 bits (par plan) en entier signé ou non signé, ou en flottant, voire un nombre complexe, avec un nombre quelconque de plans (1 pour une image "ligne", 2 pour une image 2D, 3 pour une image 3D ou ... pour une vidéo 2D !!!) ou plus encore (999 dimensions) avec la dimension de chaque plan. Dans nos outils astro, le format fit est réduit à une représentation 2D (image), et je ne connais pas de soft amateur gérant la 3D ou la 2D+vidéo !

D'un autre coté, la capture avec des données > 16 bits me semble là aussi peu usité dans le domaine amateur (déjà qu'avoir un bon ADC 16 bits c'est pas facile).

 

Marc

 

  • Merci 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Très intéressantes  ces explications , merci .

Coté traitement ADC de la cam , c'est vrai que l'on ai quasiment tout le temps en 8 bit

même Christian Viladrich en solaire est en 8 bits saud cas exceptionnel  .

 

Malgré tout , je testerai sur cible l’histoire   du Hight Speed  ou pas  au niveau résolution,

si Emil.K en parle ,  on peut toujours tester .

 

Bernard_Bayle

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



  • Contenu similaire

    • Par spacetimepictures
      Salut,
       
      Pour le contexte, j'héberge un projet à but non lucratif appelé Continuum. Il s'agit d'une série d'exploration spatiale en cours et en temps réel. Dans chaque épisode interconnecté, nous découvrons et nous nous émerveillons d'une nouvelle région de notre galaxie, et au-delà. La devise de Continuum est "être curieux et contemplatif".
       
      Diffusé tous les quelques jours sur YouTube, chaque épisode présente une image, capturée à distance à Obstech, au Chili, que je partage ici après l'avoir explorée librement. Au cours du processus, j'explique les objets que nous rencontrons, d'une manière que j'espère attrayante et documentaire.
       
      Ce faisant, je rencontre beaucoup d'objets moins connus (et parfois, inconnus), et à 34 épisodes aujourd'hui, il était nécessaire de commencer un projet satellite d'indexation de ces objets. C'est ainsi qu'est né, à l'épisode 32, le LL Catalog of Unknown and Occult Deep-Sky Objects (Catalogue LL des objets inconnus et occultes du ciel profond).
       
      Ce recueil informel a pour but de mettre en évidence certaines des merveilles cosmiques qui sont passées entre les mailles du filet des astronomes, ou qui n'ont pas encore été photographiées par la communauté des astrophotographes. L'objectif de ce projet satellite est d'encourager les explorateurs à sortir des sentiers battus et à s'approprier quelques-unes des nombreuses pépites cosmiques qui parsèment notre voyage sur le Continuum.
       
      Il sera mis à jour au fur et à mesure, et rétrospectivement, alors n'hésitez pas à l'ajouter à vos favoris, car il est probable qu'il prenne de l'ampleur au fur et à mesure que la série se poursuit.
       
      En espérant que cela intéressera certains d'entre vous.
       
      A bientôt !
       
      Laurent
       
    • Par Csteph
      Bonjour,
       
      Quelques liens, d'une nouvelle distribution Linux, pour ceux qui voudraient tenter l'aventure du fabuleux Kstars / Ekos avec leurs pi4/5 ou mini pc. Elle tourne sous ArchLinux et la dernière version de Kstars 3.6.9.
       
      https://indilib.org/forum/astro-arch/14367-astroarch-1-8-released.html
      https://github.com/devDucks/astroarch
       
      Bon ciel à tous.
    • Par jean dijon
      Bonjour,
       
      j'ai un problème avec mon MCMTII qui est apparu lors de l’écriture de nouvelles valeurs des paramètres de vitesse. Depuis je n'arrive plus à modifier ces valeurs de vitesses car une erreur se produit systématiquement au moment de la tentative d 'ouverture  du programme de configuration du MCMT. 
      J'ai de vieux PIC d'une ancienne version qui ne produisent pas d'erreur mais l'entrainement horaire ne marche pas. C'est donc bien les PIC qui ont un problème. Que puis je faire pour remettre le système en état?
      Merci d'avance pour votre aide
       
      jean  
    • Par Bernard_Bayle
       
      WinJUPOS 12.3.2 Un message de Damian Peach sur un autre forum
       
      Damian Peach
      WinJUPOS 12.3.2 - A major update to de-rotation
      With the latest release of WinJUPOS a major improvement had been added thanks to work behind the scenes of Felix Langassner.
      The manual de-rotation method developed by Felix has now been automated and integrated into WinJUPOS.
      You can see below an example produced by Rico Enzmann using 168min of data and the resulting combination at right.
      A big thank you to Felix for his work in producing this, and managing to encourage Grischa Hahn (creator of WinJUPOS) t
      o integrate this into WinJUPOS. It is a major step forward in enabling us to produce better quality imagery
      _____________________________________________________________________________
      WinJUPOS 12.3.2 - Une mise à jour majeure de la dérotation
      Avec la dernière sortie de WinJUPOS, une amélioration majeure avait été ajoutée grâce au travail dans les coulisses de Felix Langassner.
      La méthode de dérotation manuelle développée par Felix a maintenant été automatisée et intégrée dans WinJUPOS.
      Vous pouvez voir ci-dessous un exemple produit par Rico Enzmann en utilisant 168min de données et la combinaison résultante à droite.
      Un grand merci à Felix pour son travail dans la production de ceci, et d'avoir réussi à encourager Grischa Hahn (créateur de WinJUPOS)
      à intégrer cela dans WinJUPOS. Il s'agit d'un grand pas en avant pour nous permettre de produire des images de meilleure qualité.
       
       

       
      Bernard_Bayle
    • Par Alexandre Cucculelli
      Bonjour a tous 
       
      Je reviens vers vous pour " essayer" de comprendre les différents problèmes de mon montage pour l'observation des planètes .
      Grace a vous je sais qu'il est très important d'être en  usb3 et non pas en usb2 quand la CCD le permet évidement .
      Que la différences entre le   8 bits ou 16 bits est intéressant sur du RGB mais egalement sur du mono ( exp Jupiter , Mars , lune ...) .
       
      Bref mon souci c'est plutôt le montage  plus ou moins douteux que j'ai réalisé  entre  la camera , barlow .....
      La Barlow est dans l'extender sur mon image !
      Je signal aussi que je n'ai toujours pas d'ADC  ( Commande a relancer auprès de mon revendeur ) peut être que cela aura une incidence sur le montage ?
      Pas certain  de mon BF  et que dire de l'échantillonnage !!
      https://zupimages.net/viewer.php?id=24/06/7fp2.jpg
      E = 206x 2 /1000 x2.7 = 6.55
      Faut il travailler en Bin2 ?
       
      Matériels 
      Newton 254 mm  f  1000  F/D 4
      Camera ASI 678 MC  avec des pixels de 2 microns .
      Barlow x 2.7 APM Comacorr .
       
      merci d'avance .
      alex.
       
  • Évènements à venir