Solo para verificar, déjame probar el análisis de ForeverWintr experimentalmente.
El peor tipo de imagen de entrada para la compresión JPEG (o cualquier compresión, en realidad) es el ruido RGB uniformemente aleatorio, que en teoría es incompresible. Permítanme generar algunos usando las herramientas netpbm :
$ rawtoppm < /dev/urandom 640 480 > rnd.ppm
$ pnmtopng < rnd.ppm > rnd.png
$ du -b rnd.*
923772 rnd.png
921615 rnd.ppm
(Ruido RGB uniformemente aleatorio, formato PNG sin pérdidas, 903 kb)
Nota (marzo de 2017): estoy bastante seguro de que la imagen de arriba estaba en formato PNG cuando escribí esta respuesta por primera vez y la cargué en 2013. (Incluso hay un comentario sobre la gestión del color a continuación que implica esto). Desafortunadamente, sería parece que se ha convertido silenciosamente a JPEG en algún momento, haciendo que la comparación visual aquí sea inútil.
Intenté volver a cargar una nueva imagen de prueba PNG, pero aparentemente alcanza algún tipo de límite arbitrario de tamaño de archivo PNG en imgur y se convierte automáticamente a JPEG. No estoy seguro de si hay alguna forma de evitar este problema, pero al menos si tiene acceso a un cuadro de Linux, siempre puede volver a ejecutar los comandos dados para generar sus propias imágenes de prueba. En cualquier caso, aparte de evitar la comparación visual directa de la calidad de compresión, esto no invalida el análisis a continuación de ninguna manera.
OK, entonces el archivo PPM sin comprimir tiene una longitud de 640 × 480 × 3 = 921,600 bytes, más 15 bytes para el encabezado PPM mínimo, tal como se esperaba. Intentar comprimirlo sin pérdidas usando el formato PNG solo termina aumentando el tamaño en 2157 bytes, presumiblemente asumido por los encabezados y metadatos PNG y posiblemente por una leve ineficiencia en el algoritmo de compresión que intenta comprimir datos incompresibles.
(Sí, eso es 3 bytes por píxel, no 4; incluso el formato PPM, que es tan simple como puede obtener un formato de archivo de gráficos, no es lo suficientemente tonto como para almacenar un cuarto byte por píxel inútil en el disco. Puede haber algunos ventaja de hacerlo en la memoria por razones de alineación, especialmente si también necesita almacenar un canal alfa, pero esas razones no se aplican al escribir la imagen en un archivo).
OK, ¿y qué hay de JPEG? Intentemos minimizar las pérdidas de compresión primero (calidad = 100, sin submuestreo de croma, DCT de punto flotante). Desafortunadamente, el pnmtojpeg
manual no explica claramente cómo configurar todas las opciones relevantes (específicamente, la -sample
opción aparece en la sección "Opciones para asistentes", que solo hace referencia a un archivo en la documentación de libjpeg), así que la convertiré en el GIMP en su lugar. El archivo resultante se ve así:
897249 rnd.jpg
(JPEG comprimido ruido RGB, calidad = 100, sin submuestreo de croma, 876 kb)
¿Qué, cómo puede ser más pequeño? ¿No acabo de decir que el ruido puro era incompresible? Bueno, la cosa es que, incluso con la máxima calidad, compresión normal JPEG no es bastante sin pérdidas. Al volver a abrir la imagen en GIMP y compararla con el original, se puede ver que algunos de los píxeles han cambiado sus valores de color en uno o dos pasos (de 256). Esos son los píxeles donde el algoritmo de compresión JPEG "engañó" y arrojó un poco aquí, otro allí, donde estimó que el cambio no sería notable. De hecho, para el ojo humano sin ayuda, el resultado es bastante indistinguible del original, pero esos bits descartados se suman a una disminución medible en el tamaño del archivo, incluso después de tener en cuenta el encabezado y la sobrecarga de codificación.
Entonces esa fue la máxima calidad; ¿Qué pasa con las configuraciones más típicas, como los pnmtojpeg
valores predeterminados (calidad = 75, submuestreo habilitado)? Vamos a intentarlo:
$ pnmtojpeg < rnd.ppm > rnd2.jpg
$ du -b rnd2.jpg
185128 rnd2.jpg
(JPEG, ruido RGB comprimido, calidad = 75, submuestreo de croma, 184 kb)
¡Guau, desde 901 hasta 184 kb! Sin embargo, esa es una compresión bastante agresiva, y definitivamente puedes notar la diferencia al comparar las imágenes de cerca. La mayor parte se debe al submuestreo de croma, que básicamente solo arroja el 75% de los datos de color (matiz / saturación). Probarlo en el GIMP con submuestreo desactivado da un archivo de 350,618 bytes que todavía se ve (al menos para el ojo humano) bastante cerca del original incluso cuando se amplía.
De todos modos, el objetivo de todo esto es demostrar que, no importa cuán ruidosas sean sus fotos del cielo nocturno, y no importa cuán alta sea la calidad que pueda seleccionar, simplemente no hay forma de que un archivo JPEG de 640 × 480 pueda ser significativamente más grande que 900 kb. (Bueno, a menos que su cámara adjunte un perfil de color Exif de varios megabytes o algo igualmente estúpido, eso es). Y si está usando configuraciones de compresión JPEG más típicas, el tamaño máximo de archivo plausible se reduce a aproximadamente 200 kb más o menos .