Pour vérifier, je vais tester L'analyse de ForeverWintr de manière expérimentale.
Le pire type d'image d'entrée pour la compression JPEG (ou tous ) est un bruit RVB uniformément aléatoire, qui est théoriquement incompressible. Permettez-moi donc d'en générer à l'aide de la fonction netpbm des outils :
$ rawtoppm < /dev/urandom 640 480 > rnd.ppm
$ pnmtopng < rnd.ppm > rnd.png
$ du -b rnd.*
923772 rnd.png
921615 rnd.ppm
![Uniformly random RGB noise, lossless PNG format]()
(Bruit RVB uniformément aléatoire, format PNG sans perte, 903 kb)
Note (mars 2017) : Je suis presque sûr que l'image ci-dessus était au format PNG lorsque j'ai rédigé cette réponse et l'ai téléchargée en 2013. (Il y a même un commentaire sur la gestion des couleurs ci-dessous qui implique fortement cela). Malheureusement, il semblerait qu'il ait été silencieusement converti en JPEG à un moment donné, ce qui rend la comparaison visuelle inutile.
J'ai essayé de retélécharger une nouvelle image de test au format PNG, mais apparemment elle atteint une sorte de limite arbitraire de taille de fichier PNG chez imgur et est automatiquement convertie en JPEG. Je ne suis pas sûr qu'il y ait un moyen de contourner ce problème, mais au moins si vous avez accès à une machine Linux, vous pouvez toujours réexécuter les commandes données pour générer vos propres images de test. Quoi qu'il en soit, outre le fait qu'il empêche une comparaison visuelle directe de la qualité de la compression, ce problème n'invalide en rien l'analyse ci-dessous.
OK, le fichier PPM non compressé fait donc 640 × 480 × 3 = 921 600 octets, plus 15 octets pour l'en-tête PPM minimal, comme prévu. En essayant de le compresser sans perte à l'aide du format PNG, on finit par augmenter sa taille de 2157 octets, vraisemblablement occupés par les en-têtes et les métadonnées PNG et peut-être par une légère inefficacité de l'algorithme de compression qui tente de compresser des données incompressibles.
(Oui, c'est 3 octets par pixel, pas 4 ; même le format PPM, qui est à peu près aussi simple qu'un format de fichier graphique peut l'être, n'est pas assez stupide pour stocker un quatrième octet inutile par pixel sur le disque. Il y a peut Il y a un certain avantage à le faire en mémoire pour des raisons d'alignement, en particulier si vous devez également stocker un canal alpha, mais ces raisons ne s'appliquent pas à l'écriture de l'image dans un fichier).
OK, qu'en est-il de la norme JPEG ? Essayons d'abord de minimiser les pertes de compression (qualité = 100, pas de sous-échantillonnage chromatique, DCT en virgule flottante). Malheureusement, la pnmtojpeg manuel n'explique pas clairement comment définir toutes les options pertinentes (en particulier, l'option -sample est listée dans la section "Options for wizards", qui fait simplement référence à un fichier dans la documentation de libjpeg), je vais donc le convertir dans le GIMP à la place. Le fichier résultant ressemble à ceci :
897249 rnd.jpg
![JPEG compressed RGB noise, quality = 100, no chroma subsampling]()
(bruit RVB compressé en JPEG, qualité = 100, pas de sous-échantillonnage chromatique, 876 kb)
Quoi, comment peut-il être plus petit ? Ne viens-je pas de dire que le bruit pur était incompressible ? Le fait est que, même avec une qualité maximale, la compression JPEG normale ne permet pas de réduire la taille de l'image. tout à fait sans perte. En rouvrant l'image dans GIMP et en la comparant à l'original, on peut voir que certains pixels ont vu leur valeur de couleur décalée d'un ou deux pas (sur 256). Il s'agit des pixels pour lesquels l'algorithme de compression JPEG a "triché" et a supprimé un peu ici, un autre là, alors qu'il estimait que le changement ne serait pas perceptible. En effet, à l'œil nu, le résultat est pratiquement impossible à distinguer de l'original, mais ces bits supprimés représentent une diminution mesurable de la taille du fichier, même en tenant compte de l'en-tête et de la surcharge d'encodage.
Il s'agissait donc de la qualité maximale ; qu'en est-il des paramètres plus typiques, comme le pnmtojpeg les valeurs par défaut (qualité = 75, sous-échantillonnage activé) ? Essayons :
$ pnmtojpeg < rnd.ppm > rnd2.jpg
$ du -b rnd2.jpg
185128 rnd2.jpg
![JPEG compressed RGB noise, quality = 75, chroma subsampling]()
(bruit RVB compressé en JPEG, qualité = 75, sous-échantillonnage chromatique, 184 kb)
Wow, de 901 à 184 kb ! C'est une compression assez agressive, cependant, et vous pouvez certainement voir la différence en comparant les images de près. Cela est dû en grande partie au sous-échantillonnage chromatique, qui jette 75% des données de couleur (teinte / saturation). En l'essayant dans le GIMP avec le sous-échantillonnage désactivé, on obtient un fichier de 350 618 octets qui reste (pour l'œil humain, du moins) assez proche de l'original, même lorsqu'on l'agrandit.
Quoi qu'il en soit, le but de tout ceci est de démontrer que, quel que soit le niveau de bruit de vos photos du ciel nocturne, et quelle que soit la qualité que vous choisissez, il n'y a qu'un seul moyen d'obtenir un résultat satisfaisant. pas question un fichier JPEG 640 × 480 peut dépasser largement les 900 kb. (À moins que votre appareil photo ne lui associe un profil de couleur Exif de plusieurs mégaoctets ou quelque chose d'aussi stupide). Et si vous utilisez des paramètres de compression JPEG plus classiques, la taille maximale plausible du fichier descend à environ 200 kb.
