tech Traitement en 32 bits

[litobrit]

Une magnifique image faite par Walcho-67 et mise à dispo de la communauté dans le fil "partage de fichiers prétraités". Les fichiers sont là

Cette image conservée heureusement en 32 bits a fait l'objets de plusieurs essais de traitements. Le signal en périphérie est au raz du plancher, 40 environ sur une échelle de 130000. La dynamique sur une grande partie de l'image est très faible. Tout passage en 16 ou 8 bit détruit définitivement les données des faibles nébulosités.

La seule méthode qui donne de bons résultats est le maintien en 32 bits pour la montée d'histogramme et le traitement du fond.

Avec Pixinsight et en 32 bits, une séparation des 3 canaux RGB, une montée d'histogramme calquée sur le STF standard, un background extractor en auto et en soustraction puis une recomposition de l'image RGB. Ce début de traitement doit être possible sans Pixinsight en important en 32 bits les fits dans Photoshop avec FitsLiberator et en utilisant les mêmes traitements de montée d'hist. et de traitement des gradients des 3 couches séparément.

Passage en TIFF 16 bits sur photoshop puis ajustement local des histos RGB par les méthodes classiques.

Ce maintien en 32 bit pour les gradients et la montée d'histo permet de tirer le maxi du très faible signal autour de la nébuleuse. J'avais fait de la même façon pour ma bulle.

 

J'envisage de monter un petit commerce de traitements d'images. Vous n'y arrivez pas, je suis là.

J'hésite encore pour l'enseigne du magasin, "Au joyeux artefact" ou "TopRSB" ou "APOD or moneyback" . Si vous avez des idées ?

 

 

[Pulsar59]

bonne idée, il faut encourager le commerce de proximité.

 

Sinon pour FITS Liberator et PS, je viens de dire ailleurs que pour moi ca ne fonctionne pas pour un 32 bits. Je me retrouve avec tout sur 255 niveaux après transformation en 16 par FL.

 

Voilà une première commande pour ton épicerie fine

[litobrit]

Sinon pour FITS Liberator et PS, je viens de dire ailleurs que pour moi ca ne fonctionne pas pour un 32 bits. Je me retrouve avec tout sur 255 niveaux après transformation en 16 par FL.

Désolé, je ne connais pas bien FL. Il y a aussi MaximDl qui fait cette transfo.

Sinon, mets sur dropbox ce que tu voudrais en tif 32 bits, je te ferais un prix en tant que premier client

[Edji]

J'ai rien compris à la langue utilisée pour le message texte (Chinois, Hébreu, Klingon ??) Mais la photo est... époustouflante (NB : ça, c'est du Français).

Bravo pour la prise de vue et chapeau très bas pour le traitement.

 

Un béotien admiratif et jaloux.

[Pulsar59]

Désolé, je ne connais pas bien FL. Il y a aussi MaximDl qui fait cette transfo.

Sinon, mets sur dropbox ce que tu voudrais en tif 32 bits, je te ferais un prix en tant que premier client

 

Ben, c'est le 32 bits de Walcho qu'il a mis ici.

Je voudrais le récupérer en vrai 16, TIFF ou fit, peu importe ! car je n'ai pas PI et pas motivé pour l'avoir.

 

Quoique si son fdc est aussi bas que tu l'as dis déjà en 32, alors même si je récupère un "vrai" 16 ca risque de pas le faire quand même.

 

Pour le prix : comme je suis une référence, ca attirera les autres, donc ce sera 0

[gerard33]

Cette image conservée heureusement en 32 bits

mais d'où vient ce 32 bits? quel imageur capture en 32 bits?

[AstroFilDu76]

mais d'où vient ce 32 bits? quel imageur capture en 32 bits?

 

Walcho_67 a utilisé un APN canon comme imageur.

[gerard33]

Walcho_67 a utilisé un APN canon comme imageur.

 

donc 12 bits

crois-tu que le passage en 32 ait créé miraculeusement de l'information?

[lock042]

Je crois pouvoir dire que le fichier posté fait même 64bits et non 32.

Ces 64bits sont obtenus suite à une composition HDR dans Pixinsight.

 

Edit : voici l'entête du fichier Integration-HDR

SIMPLE  =                    T / file does conform to FITS standard             
BITPIX  =                  -64 / number of bits per data pixel                  
NAXIS   =                    3 / number of data axes                            
NAXIS1  =                 3828 / length of data axis 1                          
NAXIS2  =                 2464 / length of data axis 2                          
NAXIS3  =                    3 / length of data axis 3                          
EXTEND  =                    T / FITS dataset may contain extensions            
COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H 
PROGRAM = 'PixInsight 01.08.03.1123' / Software that created this HDU           
COMMENT PixInsight Class Library: PCL 02.00.13.0692                             
COMMENT FITS module version 01.01.02.0288                                       
COLORSPC= 'RGB     '           / PCL: Color space                               
RESOLUTN=                  72. / PCL: Resolution in pixels per resolution unit  
RESOUNIT= 'inch    '           / PCL: Resolution unit                           
ICCPROFL= 'ICCProfile'         / PCL: File includes ICC profile extension       
END

Modifié 5 février 2015 par lock042

[sunshadow]

sa me ferais bien chier de faire traiter mes images,sa me gacherais le plaisir!

[teddelyon]

J'ai pô combien y a de bites mais en tout cas elle est superbe la photo

[gerard33]

il pourrait être sauvegardé en 128 bits (si cela existait), que cela ne changerait rien à son contenu

non?

[lock042]

il pourrait être sauvegardé en 128 bits (si cela existait), que cela ne changerait rien à son contenu

non?

 

Ben dans le cas d'une composition HDR j'ai envie de dire que si. Le but de la composition HDR étant d'augmenter la dynamique de l'image. Dans le cas simple d'une empilement par moyenne, effectivement ... SI on empile par moyenne des images codées en 12 ou 14bits (pour les APN modernes), ca changera quedalle.

Modifié 5 février 2015 par lock042

[gerard33]

SI on empile par moyenne des images codées en 12 ou 14bits (pour les APN modernes), ca changera quedalle.

 

tout à fait d'accord là dessus

[benjamindenantes]

J'avais un peu la même remarque que Gérard...

 

Pourquoi passer en 32 bits un fichier en 12 bits?? (hors hdr)

 

 

sa me ferais bien chier de faire traiter mes images,sa me gacherais le plaisir!

 

Mettre à disposition ses images pour les faire traiter par d'autres sert surtout à progresser en traitement en voyant comment les autres s'en sortent. (a condition qu'ils donnent les petits tuyaux)

Modifié 5 février 2015 par benjamindenantes

[AstroFilDu76]

sa me ferais bien chier de faire traiter mes images,sa me gacherais le plaisir!

 

Personnelement je pense avoir progresser de facon phénomènale !!

[AstroNOTE-Guillaume]

donc 12 bits

crois-tu que le passage en 32 ait créé miraculeusement de l'information?

 

Moi c'est exactement ce que je me disait le signal 12 bit passé en 32 bit ???? a par pour faire des réglages fin du signal déjà existant (du 12 bits) je ne vois pas d'autre intérêt. On ne recréer pas du signal...

Modifié 5 février 2015 par carbune

[litobrit]

Moi c'est exactement ce que je me disait le signal 12 bit passé en 32 bit ???? a par pour faire des réglages fin du signal déjà existant (du 12 bits) je ne vois pas d'autre intérêt. On ne recréer pas du signal...

C'est ce qu'ont du se dire les centaines d'ingénieurs d'Adobe, de Pixinsight et autres logiciels de traitement de signal numérique, pas uniquement d'images.

Tiens, aujourd'hui on va développer à coup de milliers de dollars la technique HDR, on ne sait jamais, un miracle et ca va améliorer les images ou le signal de nos clients.

Nos images astronomiques brutes codées à la sortie de la caméra en 12, 14 ou 16 bits ont une dynamique extrême.

D'un coté les étoiles brillantes souvent en haut de la plage ADU 65000 pour le 16 bit et de l'autre les faibles extensions pour lesquelles sur des centaines de pixels de long la dynamique est très faible et les variations de signal très faibles, quelques paliers d'ADU.

L'élimination des signaux parasites puis la registration et l'intégration par des calculs très sophistiqués se concrétisent par la création d'une nouvelle (pour Guillaume) image unique et certains logiciels élaborés comme Pixinsight permettent de créer cette image en 32 bits (HDR). Pixinsight propose même de faire les calculs et d'enregistrer en 64 bits.

On se demande ce qu'il leur passe par la cabessa à Valence ?

Les logiciels de traitement Pixinsight, Photoshop et autres permettent de lisser ces paliers d'ADU à la seule condition de pouvoir le faire c'est à dire de créer des paliers intermédiaires en modifiant l'échantillonnage de la matrice d'image.

Une fois ces paliers lissés par la montée d'histogramme et les traitements appropriés, la dynamique redevient utilisable en 16 voire 8 bits. Difficile même de faire la différence entre une image finale en 8 et 16 ou 32 bits. C'est au départ que ca se joue.

Une image après intégration ayant une bonne dynamique sur l'ensemble de ses pixels pourra se contenter d'un traitement en 8 bits comme on faisait il n'y a pas si longtemps.

Regardez sur le fil "partage des fichiers" la différence de résultats entre des traitements en 8, 16 ou 32 bits.

Maintenant, vous faites comme vous voulez

Un peu de lecture

[Pulsar59]

Je plussoie complètement ce que vient de dire Litobrit.

 

Il se trouve qu'une de mes activités est la programmation d'algos de traitements et d'analyse d'images (dans mon cas microscopie optique et électronique, et macrophoto, mais ca ne change pas grand-chose au niveau des principes de base) depuis en gros 25 ans.

 

Ces principes de base (calcul matriciel, morphologie mathématique...) sont connus depuis très longtemps (en France, travaux de Jean Serra, Jean-Louis Chermant, Ecole des Mines Paris...). Et en effet ils imposent des calculs intermédiaires qui nécessitent d'augmenter la dynamique.

 

Ne serait-ce que pour faire la moyenne de 2 images : si on veut conserver toute l'info, on est bien obligé de commencer par l'addition --> besoin d'un bit de plus. C'est pour ça que les sorties d'empilement de DSS sont en 32, par exemple.

 

Pour la convolution et les transformées de Fourier et ondelettes, je crois me rappeler que pour traiter de 8 bits il faut obligatoirement allouer du 16 en mémoire...

Et ainsi de suite...

 

Donc pour une brute bien sûr qu'un codage sur 16 bits suffit, mais dès qu'on va la tripoter, on peut (pour certains algos, pas tous) se trouver court en dynamique si on ne passe pas en 32 (HDR ou pas HDR, d'ailleurs).

Modifié 6 février 2015 par Pulsar59

[lock042]

Ces principes de base (calcul matriciel, morphologie mathématique...) sont connus depuis très longtemps (en France, travaux de Jean Serra, Jean-Louis Chermant, Ecole des Mines Paris...). Et en effet ils imposent des calculs intermédiaires qui nécessitent d'augmenter la dynamique.

 

Effectivement, pour les calculs en interne la précision peut ne pas être la même que la précision du résultat.

Je prend l'exemple de Siril que je développe. Siril travaille en 16bits, mais souvent pour les calculs intermédiaire, on travaille avec des doubles à la précision 64bits. Cela n'empeche pas que l'image "finale" de l'opération est en 16bits (bien qu'un jour on envisage de passer en 32bit).

Mais si tu fais une moyenne des pixels :

 

4000 3982 4201 3985 ......

en interne, pour le calcul de la moyenne, tu risques de dépasser bien sur les 2^16 bit (lors de la somme de tous les pixels), mais le résultat de ta moyenne lui ne le dépassera pas. C'est en ça que je voulais dire que ça changerait quedalle pour l’empilement.

Le truc à la rigueur, en me relisant, c'est que tu vas perdre la précision après la virgule.

 

Donc pour une brute bien sûr qu'un codage sur 16 bits suffit, mais dès qu'on va la tripoter, on peut (pour certains algos, pas tous) se trouver court en dynamique si on ne passe pas en 32 (HDR ou pas HDR, d'ailleurs).

Oui, ca je suis bien d'accord.

Modifié 6 février 2015 par lock042

[thierry242]

Pour résumer en quel format faut il sauver une image venant de dss pour l'ouvrir dans

 

iris et/ou dans photoshop ?

 

merci

[Pulsar59]

Pour résumer en quel format faut il sauver une image venant de dss pour l'ouvrir dans

 

iris et/ou dans photoshop ?

 

merci

 

En tiff 16 BITS (faut espérer que le passage 32-->16 ne fait pas perdre l'info dans les basses lumières, cf la M42 de Walcho où c'est ce qui s'est passé pour une raison qui m'échappe encore)

[OrionRider]

DSS travaille en 32 bits au départ d'images 8, 12 ou 14 bits car effectivement la compilation permet d'augmenter la dynamique et d'identifier des nuances qui ne se trouvent pas dans les brutes.

 

Exemple de moyenne d'un pixel pour 7 brutes:

 

12

11

5

15

11

8

9

 

71/7 = 10,142857...

 

Coder cette information avec un nombre important de bits permet de conserver un maximum d'info après la virgule. Or, si le nombre de brutes est suffisant cette information est déterminante.

 

Maintenant, dans la pratique on peut sauver l'image empilée en 16bits, la différence pour la majorité des images est insignifiante et ne justifie pas le temps de calcul et la taille des fichiers.

Modifié 6 février 2015 par OrionRider

[Pulsar59]

 

Maintenant, dans la pratique on peut sauver l'image empilée en 16bits, la différence pour la majorité des images est insignifiante et ne justifie pas le temps de calcul et la taille des fichiers.

 

Dans le cas de cette M42, pour une raison qui m'échappe la sortie d'empilement était à 40/130000, codé sur 32 bits. Ce n'est pas du tout normal et c'est la première fois que je vois ça.

Ceci dit, si là on passe en 16 alors c'est sûr qu'on perd tout le fdc, pour le coup !

[OrionRider]

DSS permet de remettre le 'point noir' à zéro justement pour gagner en dynamique.

 

Perso je n'ai vu aucune différence entre un traitement 32bits ou 16bits. Après, mes images ne sont peut-être pas assez riches en signal.

Par ailleurs, quel écran est capable de réellement afficher autant de nuances?

[lock042]

Par contre, si j'ai téléchargé la bonne image proposée originalement, il s'agit d'une image en 64 bits

Comme le montre mon post plus haut avec l'entête.

[Siegfried_M31]

Le passage en 32 bits permets de mieux jouer avec les haut niveaux la ou à la moindre initiative en 16 bits on crame des zones on préserve une dynamique de l'image en utilisant 32 bits.

Qd aux niveaux bas, justement ils se traitent aussi bien en 15 bits avec Iris puisque on ne risque pas de les cramer et je ne comprends pas la manœuvre des 32 bits pour gérer les bas niveaux. Avec seulement 15 bits sous Iris ou 32000 niveaux les gradient issus d'une maltraitance quel conque resteront suffisamment petit pour ne pas créer de palier de niveaux visible, même si ce sont de pas de 10 en 10.

N'importe quelle compression JPG pour envoyer son image sera plus violente que le travail en 15 bits qui à fait ses preuves.

Cette course au bits reste d'un intérêt très faible du moins en ciel profonds. C'est la qu'on s’intéresse aux signaux de valeurs faibles qui ne nécessitent aucunement d'un codage 32bits.

 

PS, l'image en référence semble un peu plat malgré sa foule de détails car il exploite mal l'échelle de niveaux, les hautes luminances semblent ternes.

[Pulsar59]

DSS permet de remettre le 'point noir' à zéro justement pour gagner en dynamique.

 

Perso je n'ai vu aucune différence entre un traitement 32bits ou 16bits. Après, mes images ne sont peut-être pas assez riches en signal.

Par ailleurs, quel écran est capable de réellement afficher autant de nuances?

 

imagine une image 32 bits avec l'amplitude du fdc, nuages de poussières inclus, comprise entre 40 et 50.

En passant en 16, ton fdc sera compris entre, grosso modo, 0 et 1, soit 2 niveaux discrets. Fdc binaire, quoi.

Super pour faire sortir un nuage de poussières !

C'est le cas de l'image de Walcho. Donc intraitable pour moi en 16 bits.

 

Quant aux écrans : bien sûr que ca sert à rien d'afficher autant de nuances et qu'ils en sont encore incapables, comme l'oeil d'ailleurs. Mais on parle ici du résultat final.

Ceci dit, si on utilise ce prétexte pour traiter en 8 bits du début à la fin, on s'expose à quelques déconvenues

En cours de traitement 16 bits, il nous arrive bien d'étirer la dynamique comme des boeufs pour faire sortir les faibles contrastes, non ?

Modifié 6 février 2015 par Pulsar59

[Pulsar59]

Par contre, si j'ai téléchargé la bonne image proposée originalement, il s'agit d'une image en 64 bits

Comme le montre mon post plus haut avec l'entête.

 

J'aurais du préciser : celles que je voulais traiter, c'était pas la HDR mais les 2 individuelles 180s et 30s qui elles sont bien en 32.

[litobrit]

imagine une image 32 bits avec l'amplitude du fdc, nuages de poussières inclus, comprise entre 40 et 50.

En passant en 16, ton fdc sera compris entre, grosso modo, 0 et 1, soit 2 niveaux discrets. Fdc binaire, quoi.

Super pour faire sortir un nuage de poussières !

C'est le cas de l'image de Walcho. Donc intraitable pour moi en 16 bits.

 

Quant aux écrans : bien sûr que ca sert à rien d'afficher autant de nuances et qu'ils en sont encore incapables, comme l'oeil d'ailleurs. Mais on parle ici du résultat final.

Ceci dit, si on utilise ce prétexte pour traiter en 8 bits du début à la fin, on s'expose à quelques déconvenues

En cours de traitement 16 bits, il nous arrive bien d'étirer la dynamique comme des boeufs pour faire sortir les faibles contrastes, non ?

+1