M81-M82 NGC3077

[frédogoto]

salut

edit.. nouvelle version


petit shoot cette nuit entre deux nuages....


17 poses de 400s
-35c°
dark flat offset
(je crois que mes flats ne sont pas conforme au shoot, y'a des truc qui ressortent)

[Obiwan]

hé bé mon cochon,
t'as pas honte !

Y'a pas que les flat qui sont pas bons !

[Axel]

Et la full ? Ou qu'elle est la full ???

[frédogoto]

je la mettrai qd je serai au taf
en attendant voici la brute de registration :
http://dl.free.fr/m1iZPD5N3
(sans aucun changement) N&B 16bit, vous pouvez "jouer" avec

[Philippe]

c'est dommage une brute d'empilement de 16 bits alors qu'on peut avoir plus de dynamique avec un empilement 32 bits

[Philippe]

effectivement, la PNG 16 bits sous PI ne permet pas de détailler les faibles niveaux.
Ta correction de flat est, comment dire...

[frédogoto]

hé bé mon cochon,
t'as pas honte !

Y'a pas que les flat qui sont pas bons !

faut que tu soie plus précis alban....

[frédogoto]

c'est dommage une brute d'empilement de 16 bits alors qu'on peut avoir plus de dynamique avec un empilement 32 bits

explique moi
ma ccd n'a que 22500 niveau soit un 14bit "+" sans compter les bits de "bruit"
c'est interpolé en 16bit mais on d'accord qu'on est pas véritablement en 16bit
donc quand DSS (qui me me sortir des 32bit) me compile mon image on est en vrai 16 bit des lors qu'on atteint ou dépasse 16 images
donc quel est l’intérêt du 32 bit si j'en suis si loin ?

[frédogoto]

effectivement, la PNG 16 bits sous PI ne permet pas de détailler les faibles niveaux.
Ta correction de flat est, comment dire...

j'ai remarqué
a cela s'ajoute un soucis avec l'obturateur quand il faut tres froid qui ne s'ouvre pas toujours a 100% (en haut a gauche, tu l'aura remarqué) un pose sur 3 est impactées..
mais je ne comprend pas pourquoi j'ai raté mes flats : je ne les aient jamais loupé

[Obiwan]

faut que tu soie plus précis alban....

Les étoiles étaient allongées à l'origine non ? surtout en bas à gauche.
as-tu changé de logiciel pour faire tes flats ?

[frédogoto]

non c'est du tilt (colier rotatif je pense)
je n'ai pas changé quoi que ce soit pour le flat sauf que la je suis, contrairement a d'habitude, sans filtre

[Philippe]

c'est dommage une brute d'empilement de 16 bits alors qu'on peut avoir plus de dynamique avec un empilement 32 bits

explique moi
ma ccd n'a que 22500 niveau soit un 14bit "+" sans compter les bits de "bruit"
c'est interpolé en 16bit mais on d'accord qu'on est pas véritablement en 16bit
donc quand DSS (qui me me sortir des 32bit) me compile mon image on est en vrai 16 bit des lors qu'on atteint ou dépasse 16 images
donc quel est l’intérêt du 32 bit si j'en suis si loin ?

Ah l’éternel refrain du "j'acquière en 16bits", je traite en 16bits

Tes images brutes sont en 16 bits (et généralement les faibles niveaux sont les plus présents)
A tes images brutes, tu vas corriger des bias, des dark des flat (enfin, des "master")
Tu vas ensuite réaligner tes images voire faire une petite rotation (ré-échantillonnage)
Tu vas ensuite additionner tes N images
Dans le pire des cas, 16b + 16b + 16b + 16b +... = 17/18/19/20... bits

Eh beh, la dessus, je traite en 32 bits INTEGRALEMENT pour ne rien perdre comme signal. De plus, ce qui m'intéresse, c'est ce qui va se passer dans les faibles niveaux et je n'ai donc pas envie qu'ils soient sous-échantillonnés et donc dégradés par une conversion 32-->16
Quand on convertit de 32bits à 16bits, d'après toi, on vire quoi ? Bah les faibles niveaux... (en général)

Après chacun est libre de penser que 16bit + 16bit = 16bits (chez moi ça fait 17 bits), imagine quand tu additionnes 20 ou 30 images.

[frédogoto]

oui mais ce que je te disait, c'est qu'en realité vrai on est pas en 16bit au depart....
juste du 16 bit interpolé du 14bit.. en tout cas avec le 8300
ceci dit ce soir je te fait un registration 32bit
pis j’essayerai de voir quel sont les poses dont l'obturateur a merdé

[Axel]

Je dirais même plus :
16 bits + 16 bits = 17 bits
16 bits + 16 bits + 16 bits + 16 bits = 18 bits
16 bits + 16 bits + 16 bits + 16 bits + 16 bits + 16 bits + 16 bits + 16 bits = 19 bits

Donc, si on a quelques dizaines d'images additionnées, ça fera du 20-22 bits...

[frédogoto]

certes certes
mais le 8300 n'est pas 16bit...
et combien même je serai extrément surpris que même sur 16bit la totalité de la dynamique soie occupée
mais ce qui est vrai ça mange pas bcp de pain de pousser à 32bit....
je vais essayer des ce soir et vois si je note une amélioration

[frédogoto]

marrant :
32bit = 4 milliard de teintes, ce qui est bien plus que le nombre de pixel de l'image

je suis d accord qu'il faut évidement surechantillioner la résolution chromatique pour traiter, mais en faisant du 16 bit c'est bien ce que je fait il me semble

[Philippe]

marrant :
32bit = 4 milliard de teintes, ce qui est bien plus que le nombre de pixel de l'image

tu as 8.3 millions de pixels, certes. Quel rapport avec le nombre de bits du codage de chacun des pixels ?
Si je suis ton raisonnement, une webcam 8 bits ne peut avoir que 256 pixels

Bon, l'autre w-e, pour tester une fonction très spéciale sous Pixinsight, j'ai forcé le traitement en 64 bits et non plus en 32 bits le ouf !

[Philippe]

D'autre part, si tu fais tes prétraitements sous DSS, l'image AUTOSAVE (TIF ou FIT) est en 32bits !

[Axel]

Et Rocco n'en a qu'une...

Désolé...

Mais fallait bien que je la fasse, sinon vous auriez été déçus...

Mais si, mais si...

[frédogoto]

heeee !!!!!!!!!!!
j'ai rien dit d'autre que Marrant, j'ai rien déduit de quoi que ce soit, ça c'est ton appréciation pas la mienne

64bit ??? est tu absolument certain d'un gain ????
la permet moi d'avoir un doute, enfin ça dépand de la capacité de ta ccd, genre si tu as un ccd hypertope moumoute avec un codage naturel sur plus de 16b, mais franchement la j'attend des preuves

[Axel]

Il a dit que c'était pour tester la fonction, pas que ça changeait radicalement le résultat...

[Philippe]

Décidément, tu n'as toujours pas compris le raisonnement... On s'en fout que ta CCD soit 14 ou 15 ou 16bits. Derrière tu vas faire une GROSSE série de calculs. Le 16 bits perdra des informations alors que le 32bits sera (largement) généreux. Mais comme tu ne peux pas traiter en 20 ou 24 bits... 32 c'est bien.

[frédogoto]

axel oui effectivement c'est ce qu'il a dit, désolé de pas etre débile, mais en creux il y avait quand même une évocation qui dit : ça aurait moin bien marche en 32bit...

[frédogoto]

CCD1024 OUI j'avais compris !!!!!!!!!!!!!!!!!!
et effectivement DSS balance des 32bits c'est évidement pas un hasard
mais sur une brute de régistration, une fois les calcul fait (en 32 bit) puis réechantillioné en 16 bit : comment peux dire que la 16bit va saloper les résultats ???
La c'est une question hein ? pas une rhétorique douteuse...

[Philippe]

64bit ??? est tu absolument certain d'un gain ????

C'était un calcul de déconvolution sur un bout d'image "scientifique" pour comparer différentes méthodes de déconvolution à ma boite (on travaille sur le "denoising" en live sur l'empilement d'images confocales). 1h de calcul sous Pix... sur 500 itérations. Le 64 bits apporte un poil de cul mais pas de quoi se relever la nuit

[frédogoto]

ok "image scientifique", bon a priori on est pas concerné par cette situation extrême ?!

[Philippe]

OUI j'avais compris !!!!!!!!!!!!!!!!!!
et effectivement DSS balance des 32bits c'est évidement pas un hasard
mais sur une brute de régistration, une fois les calcul fait (en 32 bit) puis réechantillioné en 16 bit : comment peux dire que la 16bit va saloper les résultats ???
La c'est une question hein ? pas une rhétorique douteuse...

Tout dépend de comment va se faire la conversion en 16bits. Si c'est simplement "squizzer" les 16 bits de poids faible, tu pers toute l'info des bas niveaux !
Si tu prends le min et le max de tes valeurs en 32bits (par exemple si tu vas de 3000 à 750000) et que tu reconvertis en 0 à 65500, alors tu auras moins perdu.

Pixinsight a une autre approche.
16 bits sont convertis en REELS 32bits entre 0 et 1. 1 est le max quelque soit le nombre de bits.
Tu traites ton image entre 0 et 1 en 32bits ou 64bits natif (tu décides)
Tu convertis alors ton image 0 à 1 en 8, 16, 32, ou 64 bits. Ce qui est plutot bien foutu pour garder une certaine linéarité des données.

[frédogoto]

Tout dépend de comment va se faire la conversion en 16bits. Si c'est simplement "squizzer" les 16 bits de poids faible, tu pers toute l'info des bas niveaux !
Si tu prends le min et le max de tes valeurs en 32bits (par exemple si tu vas de 3000 à 750000) et que tu reconvertis en 0 à 65500, alors tu auras moins perdu.

tres honnêtement même si il y a 1 milliard e truc pourris chez adobe, il savent faire une conversion
ce n'est évidement pas l'option 1 chez adobe, mais je ne crois pas que ce soie la 2 non plus
j'en suis sur même
je pense qu'ils convertissent la gamme entière indépendantment des valeurs qui y sont contenue

[frédogoto]

16 bits sont convertis en REELS 32bits entre 0 et 1. 1 est le max quelque soit le nombre de bits.

la je ne comprend pas : ce n'est pas le cas de tout les softs d'images ???

[Philippe]

ok "image scientifique", bon a priori on est pas concerné par cette situation extrême ?!

Tu sais, souvent, certains process dits scientifiques peuvent se retrouver dans des logiciel dédiés à un public plus large

Un peu comme l'algorithme GREYCstoration (qui a été conçu à Caen) se retrouve maintenant dans des softs comme Pix, Gimp, imageJ, et bien sur matlab...