Nouveautés à venir

[lock042]

Bonjour, avec la future version de Siril à venir et son passage au full 32bits, les fichiers FITS vont devenir de plus en plus volumineux. Ceci peut s'avérer problématique sur certains ordinateurs aux capacités de stockage faibles, même si le coût des disques dur a quand même bien baissé.

Dans cette optique, un utiisateur de Siril, @faure.fabrice, a apporté sa contribution en proposant la compression des images FITS. Cette compression est présente sous plusieurs formes et je vais essayer d'en faire un petit résumé.

Tout d'abord, dans la version en développement, il est maintenant possible de choisir de travailler en full 16bits, ou full 32bits. Dans le premier cas, tous les algorithmes de compression sont dit "sans perte" : c'est à dire qu'un pixel compressé retrouvera sa valeur exact après décompression, sans arrondi. Pour les 32bits flottants c'est un peu plus compliqué mais des algorithmes sans pertes sont également possibles. Cependant, ils sont moins performant. En effet, en général ce type d'images contiennent bien trop de bruit dans les bits les moins significatif de la valeur du pixel. Or, de par sa nature aléatoire ce bruit est incompressible pour être efficacement compressé sans perte. Toute l'astuce ici consiste à détecter ce bruit et le supprimer pour gagner de la place. Le résultat est redoutable et les fichiers compressé peuvent avoir une taille de 25% de l'originale sans qu'aucune différence ne soit visible.

 

Alors, je vois les puristes crier au scandale, mais je les rassure de suite, cette option est désactivée par défaut. Cependant, certains algorithmes utilisés ici ont été développés par la NASA pour les images des plus grand télescopes (notamment HCOMPRESS). Donc pensez y, si vos images ne viennent pas du Chili, que vous avez un niveau de bruit certain et que la place vient à manquer sur votre disque dur, la compression peut être un allié non négligeable. Et puis il est toujours possible de faire une compression sans perte. Mais pour les images 32bits flottants cela sera moins spectaculaire.

 

Alors bien sûr, un effet collatéral de tout ça sera un temps de traitement sensiblement plus long selon l'algorithme choisis.

 

Voici une petite comparaison (à savoir que les possibilités sont bien plus importantes)  :

 

Bonne journée.

[PIX-astro]

Hello,

Les deux versions 16 et 32bits cohabiteront toujours dans les versions à venir ?

Perso, la version actuelle me satisfait, mais si des options de traitement d'image apparaissent ce serait dommage de les louper en restant 16 bits.

[lock042]

à l’instant, PIX-astro a dit :

Les deux versions 16 et 32bits cohabiteront toujours dans les versions à venir ?

Oui les deux vont cohabiter. On peut imaginer faire le prétraitement en 16bits, puis le stack en 32bits.

 

[faure.fabrice]

Bonjour à tous,

Merci @lock042 pour cette présentation de la feature.

Voici les résultats des premiers benchmarks réalisés sur un set de 200 images DSLR en entrée issues d'un A7s.
On peut voir que sur un fichier 32 bits float en mode RICE et quantization=16 qui correspond à l'image postée , on obtient un taux de compression de 4:1 ce qui est vraiment conséquent.

En mode entier 16bits , on a un taux de compression de 2:1 avec un assez faible overhead CPU ce qui est aussi très intéressant. Et pour le stack final, les I/O étant réduits, on a gagné en temps de stack:

 

Preprocessing 200 DSLR raw (convertraw + preprocess):

compression method	duration	size
no compression 32b	1m22	32208Mb
RICE q 4.0 32b	2m15	6187Mb
RICE q 8.0 32b	2m15	7031Mb
RICE q16.0 32b	2m15	7890Mb
GZIP1 q4.0 32b	3m28	8665Mb
GZIP2 q4.0 32b	3m01	6325Mb
HComp q4.0 s0 32b	6m28	5783Mb
no compression 16b	1m05	18406Mb
RICE 16b	1m39	7845Mb
GZIP1 16b	3m15	9169Mb
GZIP2 16b	2m58	7398Mb
HComp scale 0 16b	8m49	7888Mb
HComp scale 1 16b	7m41	3945Mb

 

Align global 200 img

compression method	duration
no compression 32b	2m11
RICE q4.0 32b	2m42

 

Stack 200img

compression method	duration
no compression 32b	1m06
RICE q4.0 32b	0m50