Juste pour vérifier, laissez-moi tester expérimentalement l'analyse de ForeverWintr .
Le pire type d'image d'entrée pour la compression JPEG (ou n'importe quelle compression, vraiment) est le bruit RVB uniformément aléatoire, qui est théoriquement incompressible. Alors laissez-moi en générer à l'aide des outils netpbm :
$ rawtoppm < /dev/urandom 640 480 > rnd.ppm
$ pnmtopng < rnd.ppm > rnd.png
$ du -b rnd.*
923772 rnd.png
921615 rnd.ppm
(Bruit RVB uniformément aléatoire, format PNG sans perte, 903 ko)
Remarque (mars 2017): Je suis presque sûr que l'image ci-dessus était au format PNG lorsque j'ai écrit cette réponse pour la première fois et que je 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, ce serait semble qu'il a été silencieusement converti en JPEG à un moment donné, ce qui rend la comparaison visuelle ici inutile.
J'ai essayé de télécharger une nouvelle image de test PNG, mais apparemment, elle atteint une sorte de limite de taille de fichier PNG arbitraire à imgur et est automatiquement convertie en JPEG. Je ne sais pas s'il y a un moyen de contourner ce problème, mais au moins si vous avez accès à une boîte Linux, vous pouvez toujours réexécuter les commandes données pour générer vos propres images de test. Dans tous les cas, à part empêcher la comparaison visuelle directe de la qualité de la compression, cela n'invalide en rien l'analyse ci-dessous.
OK, donc le fichier PPM non compressé mesure 640 × 480 × 3 = 921 600 octets, plus 15 octets pour l'en-tête PPM minimal, comme prévu. Essayer de le compresser sans perte en utilisant le format PNG finit par augmenter la taille de 2157 octets, vraisemblablement repris par les en-têtes et les métadonnées PNG et éventuellement une légère inefficacité de l'algorithme de compression essayant 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 peut y en avoir avantage à le faire en mémoire pour des raisons d'alignement, surtout si vous devez également stocker un canal alpha, mais ces raisons ne s'appliquent pas lors de l'écriture de l'image dans un fichier.)
OK, alors qu'en est-il du JPEG? Essayons d'abord de minimiser les pertes de compression (qualité = 100, pas de sous-échantillonnage chromatique, DCT à virgule flottante). Malheureusement, le pnmtojpeg
manuel n'explique pas clairement comment définir toutes les options pertinentes (en particulier, l' -sample
option est répertoriée dans la section "Options pour les assistants", qui fait simplement référence à un fichier dans la documentation de libjpeg), donc je le convertirai en le GIMP à la place. Le fichier résultant ressemble à ceci:
897249 rnd.jpg
(Bruit RVB compressé JPEG, qualité = 100, pas de sous-échantillonnage de chrominance, 876 ko)
Quoi, comment peut-il être plus petit? N'ai-je pas juste dit que le bruit pur était incompressible? Eh bien, même avec une qualité maximale, la compression JPEG normale n'est pas tout à fait sans perte. En rouvrant l'image dans GIMP et en la comparant à l'original, on peut voir que certains pixels ont vu leurs valeurs de couleur décalées d'un ou deux pas (sur 256). Ce sont les pixels où l'algorithme de compression JPEG a "triché" et jeté un peu ici, un autre là-bas, où il estimait que le changement ne serait pas perceptible. En effet, à l'œil humain sans aide, le résultat ne peut pas être distingué de l'original, mais ces bits jetés entraînent une diminution mesurable de la taille du fichier, même après avoir pris en compte l'en-tête et les frais généraux d'encodage.
C'était donc une qualité maximale; qu'en est-il des paramètres plus typiques, comme les pnmtojpeg
valeurs par défaut (qualité = 75, sous-échantillonnage activé)? Essayons:
$ pnmtojpeg < rnd.ppm > rnd2.jpg
$ du -b rnd2.jpg
185128 rnd2.jpg
(Bruit RVB compressé JPEG, qualité = 75, sous-échantillonnage de chrominance, 184 ko)
Wow, de 901 à 184 ko! C'est une compression assez agressive, cependant, et vous pouvez certainement faire la différence lorsque vous comparez les images de près. La majeure partie est due au sous-échantillonnage de la chrominance, qui jette simplement 75% des données de couleur (teinte / saturation). L'essayer dans le GIMP avec le sous-échantillonnage désactivé donne un fichier de 350 618 octets qui ressemble (au moins à l'œil humain) assez proche de l'original même lorsqu'il est agrandi.
Quoi qu'il en soit, le but de tout cela est de démontrer que, peu importe le niveau de bruit de vos photos du ciel nocturne, et quelle que soit la qualité que vous puissiez sélectionner, il n'y a tout simplement aucun moyen qu'un fichier JPEG 640 × 480 puisse être considérablement plus grand que 900 kb. (Eh bien, à moins que votre appareil photo ne lui associe un profil de couleur Exif de plusieurs mégaoctets ou quelque chose de tout aussi stupide.) Et si vous utilisez des paramètres de compression JPEG plus typiques, la taille de fichier maximale plausible descend à environ 200 ko environ. .