Aller au contenu

Messages recommandés

Posté (modifié)

Bonjour

J'ai une séquence SER en format RAW RGGB (IMX 585).

Lorsque je lance le prétraitement avec dématriçage en cochant la case à cocher dans les préférences "informations de bayer...", j'obtiens le rendu de couleurs attendu.

image.thumb.png.f404a752b3d8b71c2cc54a1608ad6908.png

Lorsque je force le motif de dématriçage en RGGB comme sur l'image, celui-ci se fait suivant le motif GBRG, alors que RGGB a été spécifié et l'entête du fichier est bien renseigné en RGGB.

image.png.5b9e534fb7429cce0d663de1ebce20b6.png

 

image.thumb.png.52e7fe19adcfe383e4dedccaa96c6dce.png

 

Cordialement

 

 

Modifié par jDef
Posté

Salut,

et du coup c'est quoi le problème?
Il te suffit de laisser la case "information de bayer" cochée et tu as les bonne couleurs.

 

il y a 12 minutes, jDef a dit :

celui-ci se fait suivant le motif GBRG, alors que RGGB a été spécifié

Je crois que c'est une histoire de sens de lecture de la matrice justement, mais puisque ça fonctionne en "automatique", pourquoi vouloir forcer pour arriver au même résultat?

Posté

Effectivement, mais un bug est un bug qui est à traiter, avec plus ou moins d'urgence, en fonction de sa criticité. Ca participe à la qualité du produit.

Posté (modifié)

Justement, je ne pense pas que ce soit un bug mais une mauvaise utilisation.


tu lui donne à mon avis les mauvaises infos pour dématricer ton fichier. (tu veux si j'ai bien compris lui faire dematricer un RGGB en le lisant à l'envers).
Si tu lui fait lire dans le mauvais sens  il faut aussi lui donner le décalage des pixels pour qu'il puisse retomber sur un RGGB.

D'ailleurs si je ne dis pas de bêtise, les biblio de dématriçage sont indépendantes pour que tous les soft de dématricage fasse la même chose, histoire de conserver une certaine compatibilité entre softs.
Si il y avait un bug dans la biblio de dématriçage, ça ne se corrigerait de toute façon  pas au niveau de siril.

 

faut demander à @lock042


 

Modifié par Tyler
Posté

La situation est constatée avec la version 1.2.0 rc1 (je pensais l'avoir précisé dans mon message, manifestement non ...) et je vois qu'avec la version 1.3.0 alpha-dev elle a disparue. Il n'y a donc plus qu'à attendre. Merci.

Cordialement

Posté (modifié)
Le 18/06/2023 à 22:12, jDef a dit :

La situation est constatée avec la version 1.2.0 rc1 (je pensais l'avoir précisé dans mon message, manifestement non ...) et je vois qu'avec la version 1.3.0 alpha-dev elle a disparue. Il n'y a donc plus qu'à attendre. Merci.

 

@jDef: Nous n'avons rien changé depuis. J'aurai du préciser que c'est pareil avec 1.2.0 rc1

 

image.thumb.png.6402ad077db56f584464efab4f9d253c.png

Modifié par lock042
  • 3 mois plus tard...
Posté

Bonjour

Je reviens sur le sujet car le problème est toujours présent sur la 1.2.0 :

Fichier SER créé par Sharpcap en compatibilité SIRIL (caméra IMX585 entêtes fit  RGGB et bottom-up).

Dématriçage en calibration fichier ser Sharpcap :

- Lire entête fichier : couleurs Ok (image inversée haut bas)

- forçage en RGGB : couleurs NOk

Dématriçage en calibration fichier ser créé par PIPP par réduction du nombre d'images du fichier SER Sharpcap:

- Lire entête fichier : couleurs Ok (image inversée haut bas)

- forçage en RGGB : couleurs NOk

Dématriçage en calibration fichier ser créé par SIRIL par réduction du nombre d'images du fichier SER Sharpcap, l'orientation du ser est inversée haut-bas par rapport à l'orientation initiale du fichier Sharpcap/PIPP:

- Lire entête fichier : couleurs NOk

- forçage en RGGB : couleurs Ok

 

Dématriçage en calibration fichier Fit sauvegarde par SIRIL de l'image depuis fichier ser sharpcap:

- Lire entête fichier : couleurs Ok

- forçage en RGGB : couleurs NOk

Dématriçage en calibration fichier Fitseq créé par l'onglet conversion sans dématriçage :

- Lire entête fichier : couleurs Ok

- forçage en RGGB : couleurs NOk

Fichier ser converti en fitseq avec dématriçage direct depuis l'onglet conversion :

- Lire entête fichier : couleurs Ok (image non inversée)

- forçage en RGGB : couleurs Ok (image non inversée)

 

En forçant un décalage d'un pixel en Y on arrive à retomber sur ses pieds, mais il me semble qu'il y ait un souci sur la gestion du sens de lecture haut-bas des images lorsqu'on force la matrice de bayer. Est-ce que ça peut avoir un impact sur les opérations de calibration?

 

Cdt

M42_2023-08-15-0336_1_G300_O30_4,0s_26,6C___pipp.ser

Posté
Il y a 14 heures, jDef a dit :

Je reviens sur le sujet car le problème est toujours présent sur la 1.2.0 :

 

Disons que tu n'avais pas répondu a mon dernier message où je disais que rien n'avait changer et que le comportement me parait normal.

 

Je viens d'essayer ton SER et je n'ai pas de soucis :

 

image.png.edb052852ffa65c0ed84f1cfe439d77a.png

Posté (modifié)

Je ne sais pas, en fonction du choix pour le dématriçage (forçage ou lecture en tête) ça me donne des résultats différents. Par contre je viens de voir que si je ne coche pas la première case à cocher "Dématricer les fichiers FITS...", le dématriçage se passe correctement et je n'ai pas besoin de mettre un décalage de pixel pour avoir les bonnes couleurs.

Donc c'est cette option qui génère ce comportement, je la décoche. Je ne sais pas comment elle s’applique aux fichiers ser puisqu'elle semble spécifique aux fichiers fit, mais il se passe qq chose dans le traitement, au moins chez moi.

Dans tous les cas ça inverse les images, ce qui ne semble pas être le cas chez toi.

image.thumb.png.a4d7bea9472e5ceb657758eefcb7ca43.png

J'ai un réglage qui marche, pour le reste ça restera un mystère ...

Cdt

Modifié par jDef
  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.