"Una imagen vale más que mil palabras", dice el viejo dicho. La palabra promedio tiene aproximadamente cuatro caracteres, por lo que una imagen transmite 4kB de información. Pero, ¿cuánta entropía , en lugar de información, puede transmitir una imagen?
Su tarea es generar una imagen, exactamente de 4,000 bytes de tamaño, con la mayor entropía posible. Puede usar cualquier idioma, biblioteca o formato de imagen que elija, y puede enviarlos a la consola o a un archivo siempre que cargue su imagen aquí.
Puntuación
Su puntaje es la relación de compresión (4000 ÷ tamaño comprimido) cuando su imagen se comprime con GNU tar
versión 1.28 y gzip
versión 1.6, utilizando el algoritmo DEFLATE y la configuración predeterminada, específicamente, el comando tar -czvf out.tar.gz image
. La relación de compresión más pequeña gana.
fuente
tar
incluye metadatos, incluido mtime, en los archivos de salida de forma predeterminada. Esto afecta el tamaño final del archivo comprimido: algunas veces se comprimen mejor que otras. Cambiar el comando agzip -n image
haría que el tamaño de salida sea determinista independientemente de mtime (y el nombre del archivo de entrada).gzip -n image
no puede producir un archivo de más de 4023 bytes con una entrada de 4000 bytes. Necesita 10 bytes para el encabezado, 8 para el pie de página, 1 para el encabezado y relleno del bloque DEFLATE, y 4 para el tamaño del bloque DEFLATE; el resto solo se almacena como bytes sin comprimir. La mayoría de los archivos compuestos por bits aleatorios se almacenan sin comprimir, como deberían ser.Respuestas:
0.9514747859 (salida de 4204 bytes)
Nota: la imagen de arriba no es el archivo real que utilicé, pero es la imagen.
Aquí hay un hexdump del archivo: https://gist.github.com/pommicket/cf2982e8ecf09a4de89d3a849526c64b
El archivo está en formato netpbm y se puede generar con este código C:
La semilla aleatoria debe pasarse al programa. Después de probar algunas semillas, obtuve una que produjo un archivo comprimido de 4204 bytes. Como señaló Nnnes,
tar
incluirá metadatos en el archivo, por lo que sus resultados pueden diferir de los míos.netpbm no es compatible en todas partes, pero funciona con imagemagick's
convert
(así que solo debesconvert image.pgm image.png
convertirlo en png).¿Por qué esta imagen / formato?
Un archivo que consta de bytes completamente aleatorios es muy difícil de comprimir (de hecho, cualquier algoritmo de compresión posible funcionará en promedio, no mejor que no comprimir archivos aleatorios). Al contenido del archivo real le
P5 2 1993
siguen 3986 bytes aleatorios, por lo que a gzip le resulta tan difícil comprimirlo.fuente
IHDR
,IDAT
y losIEND
fragmentos, pero la mayoría de los generadores PNG incluirán un par de fragmentos opcionales que probablemente se comprimirán bastante bien, como dijo Grimy, excepto tal vez los CRC que se pueden suponer. Sé bastante al azar.Brainfuck, 4201 bytes comprimidos.
El formato de imagen utilizado es PNG. Estoy bastante seguro de que el desafío terminó porque dejo la secuencia de comandos modificada de 4 instancias durante la noche.
Explicación
¿Entonces, cómo funciona?
Usando un programa Java estoy generando un archivo JPG. Luego, se comprime y se está comprobando su tamaño, lo que me solicita que lo conserve. Ejecuté este script por un tiempo y me generó algunos
tar.gz
archivos con diferentes tamaños. Luego, después de encontrar un nuevo ganador, se regenera el código Brainfuck.Script Bash utilizado:
Captura de pantalla del programa en ejecución:
Podría automatizarse por completo eliminando la lectura y manteniéndola implícitamente, pero me gustaría tener control sobre ella.
El código
fuente
brainfuck
parte necesaria y actualizar tu puntaje a la relación de compresión?